Skip to main content

ICT due diligence in de financiële sector

De kranten staan al enkele jaren vol met nieuws omtrent fusies en overnames. Ook in de financiële sector beleeft men spannende tijden rondom overnames. Naast de juridische en financiële kant dient ook de ICT belicht te worden tijdens een fusie of overname. Ten tijde van het schrijven van dit artikel speelde onder meer de overname van ABN AMRO en waren er berichten in het nieuws over de overname van Binck Bank door Alex. Financiële instellingen[In de Wft wordt er gesproken over ‘clearinginstelling, kredietinstelling, verzekeraar of bijkantoor’.] kennen over het algemeen een hoge graad van automatisering, waardoor het belang van ICT due diligence binnen deze sector groot is. Op basis van het due diligence-onderzoek wordt de waarde van de onderneming bepaald. Hierbij is het van belang om ook de waarde van de ICT-omgeving te bepalen. In dit artikel wordt ingegaan op de belangrijkste aandachtspunten voor een ICT due diligence binnen de financiële sector.

Inleiding

Financiële instellingen moeten zich steeds sneller kunnen aanpassen aan de veranderingen in de markt, veranderingen in wet- en regelgeving en veranderingen in technologie. Zo is bijvoorbeeld te zien dat binnen de financiële sector geïnvesteerd wordt in de vervanging en ondersteuning van mainframe-omgevingen voor bijvoorbeeld een .NET-omgeving. SEPA, MiFID, IFRS en Basel II zijn enkele voorbeelden van nieuwe wet- en regelgeving die direct invloed hebben op de ICT-omgeving van financiële instellingen. Meegaan in technologische ontwikkelingen zoals System Oriented Architectures en .NET zijn van belang om de concurrentie voor te kunnen blijven en klanten van nieuwe producten en diensten te kunnen voorzien. Maar meegaan in technologische ontwikkelingen bepaalt ook de waarde van ICT voor de onderneming, de flexibiliteit en robuustheid van de ICT-omgeving.

In dit artikel worden de ICT-aandachtspunten van het due diligence-onderzoek en de rol die de IT-auditor hierin kan spelen, toegelicht.

Belang ICT in due diligence

Financiële instellingen moeten zich er constant op blijven richten, dat (primaire en ondersteunende) processen zo efficiënt mogelijk ingericht zijn en blijven, om zo snel en efficiënt mogelijk transacties te kunnen afhandelen. Naast kosten en opbrengst per transactie is bijvoorbeeld ook het percentage ‘straight through processing’ een maatstaf voor de mate van efficiency in routinematige transactieverwerking. Goede ondersteuning door ICT is dan ook van groot belang voor de continuïteit en efficiency van de bedrijfsprocessen.

De algemene verwachting van de stakeholders bij een fusie of overname is dat synergievoordelen worden gerealiseerd. De verwachte voordelen worden vaak al meegenomen in het bepalen van de (ver)koopprijs, evenals de termijn waarop deze voordelen verzilverd kunnen worden. Op basis van de ICT-aspecten die in het due diligence-rapport naar voren zijn gekomen, kan aan aandeelhouders een realistisch beeld worden geschetst over de te maken kosten en de te behalen synergievoordelen. Derhalve dient al tijdens het due diligence-onderzoek te worden nagedacht over de situatie die na de overname gewenst is. Men kan bijvoorbeeld door het samenvoegen van product- of klantbestanden een completere dekking verkrijgen van de markt. Daar waar systemen komen te vervallen zal dit tot lagere beheerkosten kunnen leiden.

Bij fusie of overname is sprake van verticale of horizontale integratie. Bij een horizontale samenvoeging van bedrijfsprocessen behouden beide organisaties hun primaire processen en dient er naar de koppeling tussen de twee organisaties gekeken te worden. In dit geval kunnen met name ondersteunende activiteiten worden samengevoegd, zoals de helpdesk en het netwerkbeheer. Wanneer verticaal wordt geïntegreerd, kan voordeel worden behaald door delen van de procesketen op elkaar aan te laten sluiten en de onderliggende infrastructuur samen te voegen.

De risico’s van het samenvoegen zijn echter niet altijd op voorhand duidelijk. Het is onduidelijk of beide organisaties de gewenste samenvoeging technisch kunnen realiseren en of ze tot integratie kunnen komen om zo de beoogde kostenvoordelen te behalen. Als het zover komt dat beide organisaties integreren, moet worden vastgesteld welke investeringen dan benodigd zijn.

ICT vormt bij fusies en overnames in de financiële sector dan ook een belangrijk aspect binnen het due diligence-onderzoek. De IT-auditor kan hierbij een belangrijke onafhankelijke rol spelen omdat hij vanuit zijn achtergrond zicht heeft op en kennis heeft van de geautomatiseerde gegevensverwerking. Tevens kan de IT-auditor de aangetroffen systemen, medewerkers en geïmplementeerde (beheer)processen op waarde schatten.

Onderzoeksaanpak

Een due diligence-onderzoek gericht op ICT is binnen banken en verzekeringen belangrijk gezien de cruciale rol van ICT in deze hoog geautomatiseerde omgevingen. Om de rol die de IT-auditor kan spelen in het due diligence-onderzoek toe te lichten, beschrijven wij de onderwerpen die de IT-auditor onderzoekt in een dergelijk onderzoek. Afhankelijk van de omgeving waarin het onderzoek plaatsvindt zal de IT-auditor andere accenten leggen tijdens zijn onderzoek. Bij (pensioen)verzekeraars zal bijvoorbeeld veel aandacht worden besteed aan de robuustheid en actualiteit van de gehanteerde systemen, terwijl bij banken meer aandacht wordt besteed aan integreerbaarheid van systemen en omgevingen.

Aanpak en onderzoeksactiviteiten

Binnen een ICT due diligence-onderzoek verdient een veelheid aan onderwerpen de aandacht (zie figuur 1). Zo dient niet alleen naar de ‘harde’ kant van ICT (informatiesystemen, applicatieportfolio, infrastructuur en tools) gekeken te worden, maar juist ook naar de organisatie daaromheen (beheer, budgetten, beleid en contracten). Met deze onderwerpen tezamen is het mogelijk zich een goed beeld te vormen van de ICT binnen een bedrijf. Om de kopende organisatie van een goed advies te kunnen dienen moet de IT-auditor niet alleen de huidige ICT beoordelen, maar ook een beoordeling van de toekomstvastheid en mogelijkheden van integratie- c.q. ontvlechtingsmogelijkheden in de rapportage meenemen.

C-2008-1-Koets-01

Figuur 1. ICT due diligence-aandachtspunten.

Onderstaand beschrijven wij per onderwerp de belangrijkste aandachtspunten van de IT-auditor.

Organisatie

De opzet van de ICT-organisatie bestaat onder andere uit interne medewerkers, externe medewerkers, functies, handboeken en uitbestede onderdelen. Dit is voor de IT-auditor van belang binnen het due diligence-onderzoek om zich een beeld te vormen van de toegekende taken en toebedeelde verantwoordelijkheden (zowel intern als extern) binnen de ICT-organisatie.

Een overzicht van de aanwezige ICT-locaties (rekencentra, systeemontwikkeling, eventuele stafafdelingen) in alle landen geeft inzicht in de mogelijke complexiteit van het netwerk en communicatiemiddelen. Ook kan met deze informatie worden gekeken of bijvoorbeeld het uitwijkplan hierop juist is aangepast. In de financiële sector is het beschikken over een uitwijkplan en het periodiek uitvoeren van uitwijktests vereist door DNB.

Met behulp van organisatieschema’s van de ICT-afdelingen kan de IT-auditor beoordelen of afdelingen behouden dienen te worden na de overname. Afdelingen die overbodig zijn, kunnen worden afgestoten of kunnen worden samengevoegd met vergelijkbare afdelingen binnen de kopende organisatie. Daarnaast wordt op basis van benchmarkonderzoeken gekeken naar een normale bezetting en verdeling van de personeelsleden in verhouding tot het aantal klanten, het aantal transacties dat de financiële instelling verwerkt en het aantal gebruikers binnen de financiële instelling.

In een bericht over de overname van Binck Bank wordt vermeld dat synergievoordelen al snel een besparing van € 19 miljoen per jaar kunnen opleveren. In dat bericht worden voordelen ‘op het punt van kosten voor het beheer van de systemen en […] van de zelf […] te maken kosten per transactie’ genoemd. Ook wordt de nettoprovisieopbrengst per transactie berekend: € 18,20 bij Alex en € 15,93 bij Binck Bank. Hierbij speelt informatie over het aantal klanten, transacties en winst dus een belangrijke rol.

De IT-auditor brengt in kaart wat het ervarings- en opleidingsniveau van de medewerkers automatisering is. Daarbij speelt de kennis van systemen een belangrijke rol, evenals de mate waarin de systemen worden ingezet. Wanneer de medewerkers slechts van één systeem/platform kennis hebben, zal het moeilijk zijn deze voor andere systemen in de nieuwe organisatie in te zetten. Dit is met name het geval bij banken waar veel legacy-automatisering wordt gebruikt. Bij een overgang naar bijvoorbeeld een .NET-omgeving zal een deel van de medewerkers deze ontwikkeling niet kunnen of willen doormaken. De onderverdeling naar productie, onderhoud en ontwikkeling kan hierbij helpen. De ervaring en het opleidingsniveau van de medewerkers geven verder inzicht in de te verwachten salariskosten. Gecombineerd met organogrammen kan inzicht worden verkregen in overlap met of aanvulling op de medewerkers binnen de kopende organisatie.

Bij extern ingehuurde medewerkers bestaat de kans dat die met de overname niet meegaan, door bijvoorbeeld ontbindende voorwaarden in het contract. Ook is het mogelijk dat zij (gezien hun flexibele arbeidsrelatie) er zelf voor kiezen om niet naar de kopende organisatie te gaan. Deze informatie is van belang om te kunnen inschatten hoeveel medewerkers met welke kennis en ervaring in de organisatie aanwezig zijn na de overname.

De IT-auditor kan zich aan de hand van handboeken, richtlijnen, gebruikte standaarden en ontwikkelmethodieken een goed beeld vormen van de volwassenheid van de ICT-organisatie bij de over te nemen organisatie. (Zie ook ‘Volwassenheid van de ICT-organisatie’ verderop.) Gebrek aan standaarden en documentatie geeft niet alleen aan dat veel ad hoc bedacht wordt, maar heeft ook invloed op beheerprocessen en ontwikkelde applicaties. In de financiële sector is bijvoorbeeld het percentage straight through processing een belangrijk kengetal. Aan de hand van de professionaliteit van de documentatie en richtlijnen kan de IT-auditor zich hier een beeld bij vormen.

Budgetten

Om een beeld te krijgen van de financiële situatie op het moment van onderzoek en de komende jaren, moeten budgetten en werkelijk behaalde financiële resultaten worden bestudeerd. Het is voor de kopende organisatie van belang om te weten welke kosten met de ICT-organisatie gemoeid zijn.

‘De reden dat ABN AMRO overgenomen wilde worden, moet gezocht worden in schaalvoordelen, 65% van de omzet bestaat uit kosten, bij andere banken is dat 55%. ABN AMRO hoopt dat door de overname kosten gereduceerd kunnen worden, de vraag is of de ICT makkelijk kan worden samengevoegd.’

(Bron: zie Literatuur, laatste item.)

Een overzicht met de feitelijke en gebudgetteerde kosten van de afgelopen jaren is hierbij van belang. Verder dient gekeken te worden naar de gebudgetteerde kosten voor de komende jaren en de planning van investeringen en projecten.

Over het algemeen komen kosten en budgetten in de financiële due diligence aan de orde. Echter, niet alleen zijn de geplande kosten van een investering of project van belang, de IT-auditor moet ook een inschatting maken van de achterliggende reden van de investering dan wel het project. Investeringen en projecten kunnen te maken hebben met niet (meer) goed functionerende of verouderde ICT-omgevingen.

Beleid

Informatie over projecten bij de over te nemen organisatie geeft inzicht in enerzijds de mate waarin zij volwassen met haar ICT-organisatie omgaat en anderzijds welke risico’s er zijn en in welke mate deze worden beheerst. Door informatie op te vragen over het informatiebeleid, waarin de stand van zaken en de plannen voor de toekomst worden beschreven, krijgt de IT-auditor een goed beeld van de actuele ontwikkelingen binnen de ICT-organisatie. Een overzicht met een beschrijving van de projecten maakt deel uit van deze ontwikkelingen. Recent uitgevoerde projecten uit de afgelopen jaren geven aan waar zwakke onderdelen in de ICT-organisatie zaten en welke onderdelen nu mogelijk vooroplopen ten opzichte van de marktontwikkelingen. Overzichten van de huidige en komende projecten geven inzicht in de huidige problemen die binnen de ICT-organisatie spelen. Hierbij hoort informatie over aanleiding, doel, omvang, budget, planning, tijdspad, geïdentificeerde risico’s, issue log, aangegane verplichtingen, huidige status, periodieke rapportages, et cetera.

Binnen de financiële sector is het van belang zicht te hebben op de ICT-gerelateerde plannen met betrekking tot grote wijzigingen in wet- en regelgeving die de organisatie treffen. Met name SEPA, Basel II en MiFID hebben de afgelopen jaren druk gelegd op de ICT-organisatie binnen financiële instellingen.

Informatiesystemen en applicatieportfolio

Informatie over informatiesystemen en de applicatieportfolio geeft de IT-auditor inzicht in de wijze waarop primaire en secundaire bedrijfsprocessen worden ondersteund door systemen en medewerkers.

Het is voor de IT-auditor van belang te weten welke bedrijfsprocessen door welke systemen en mensen worden ondersteund. Hierdoor kan worden beoordeeld wat het effect is wanneer enkele bedrijfsprocessen weg zouden vallen in geval van overlap en welke efficiency (kostenbesparing) behaald kan worden. Aanvullend hierop moet de IT-auditor een overzicht ontvangen met de aanwezige systemen. Hierbij is onder meer van belang te beschikken over informatie omtrent de volgende onderwerpen:

  • globale beschrijving van de opzet (functionaliteiten) van de systemen;
  • relaties met andere systemen en eventuele interfaces;
  • de omvang, bijvoorbeeld uitgedrukt in functiepunten of aantal te verwerken transacties;
  • de ouderdom;
  • plannen tot vervanging;
  • het eigenaarschap (eventueel voorzien van een escrow-overeenkomst);
  • standaardpakket of maatwerk;
  • ‘open source’;
  • aantal gebruikers;
  • afhankelijkheid van andere systemen;
  • onderliggende programmeertaal en databasemanagementsysteem;
  • eigenaarschap en gerelateerde (onderhouds)contracten;
  • overzicht beschikbare documentatie;
  • koppelingen met externe systemen zoals dealingroom, SWIFT, Equens, clearing house en externe dataproviders (bijvoorbeeld Reuters en Bloomberg).

Bovengenoemde punten lijken in sommige gevallen wellicht overbodig. Echter, om een compleet beeld van de kwaliteit van de informatie- en transactieverwerkende systemen te krijgen, is het wel noodzakelijk om hiervan kennis te nemen. Diverse banken hebben bijvoorbeeld (technische) problemen met de applicaties die het bankieren door klanten door middel van het internet faciliteren. Een grote Nederlandse bank heeft onlangs € 40 miljoen uitgetrokken om verstoringen in deze techniek te verhelpen. Dit is een investering die bij een due diligence een belangrijke invloed op de prijs heeft.

De IT-auditor heeft bij zijn werkzaamheden eveneens informatie nodig over de systemen van derden. Dit is van belang bij het splitsen van de over te nemen financiële instelling en het samenvoegen met de kopende organisatie. Indien diensten worden overgenomen, waarbij cliënten toegang tot systemen verschaft wordt, moet de IT-auditor weten welke systemen dat zijn en welke verplichtingen daaruit voortvloeien.

Infrastructuur en tools

Door de technische infrastructuur te beoordelen wordt inzicht verkregen in de mogelijke synergie, wanneer onderdelen van beide organisaties elkaar overlappen. Andersom zou het mogelijk kunnen zijn dat het nodig is extra kosten te maken voor investeringen, wanneer veel vervangingen noodzakelijk zijn.

Essentieel in een due diligence-onderzoek bij een financiële instelling is de technische infrastructuur. Er moet worden gekeken naar mogelijke zwakheden, onder andere met het oog op beveiliging en overlap met de aanwezige infrastructuur bij de kopende organisatie. In geval van oude componenten in de infrastructuur moet de kopende organisatie rekening houden met forse investeringen om deze weer actueel te krijgen. Overlap met de aanwezige infrastructuur kan op termijn financiële voordelen opleveren. Financiële instellingen zijn een belangrijke prooi voor hackers. Derhalve zijn de investeringen die gemoeid zijn met het up-to-date brengen en houden van de beveiliging van de technische infrastructuur aanzienlijk. Binnen dit overzicht moet ook rekening worden gehouden met datacommunicatie met andere vestigingen, die zich mogelijk in het buitenland bevinden. Over de componenten in de infrastructuur moet bijvoorbeeld de volgende informatie beschikbaar zijn:

  • ouderdom;
  • eigenaarschap (in eigendom of gehuurd);
  • geplande vervangingen;
  • schaalbaarheid bij toenemend gebruik.

Denkbare componenten zijn servers, werkstations, besturingssystemen, databasemanagementsystemen, firewalls, netwerksoftware, protocollen, switches, modems en bekabeling.

Om de IT-auditor een beeld te geven van de volwassenheid van de beheerorganisatie, wordt gekeken naar de tools die worden ingezet voor:

  • projectmanagement;
  • beheer van de ontwikkel-, test-, acceptatie- en productieomgeving;
  • versiebeheer en change management.
Operations

Incidenten en performanceproblemen geven inzicht in de kwaliteit van de systemen binnen de organisatie en in welke mate deze systemen voldoen aan de verwachtingen en eisen van gebruikers. Op het niveau van de operationele uitvoering dient de IT-auditor inzicht te krijgen in de bezetting en de maximale capaciteit van het rekencentrum per platform. De twee organisaties zullen worden samengevoegd, waardoor het volume van de transacties toe zal nemen. De nieuwe ICT-omgeving zal deze hogere volumes volledig en juist moeten kunnen verwerken. Hiervoor is het van belang inzicht te krijgen in het aantal van de transacties van beide organisaties, aangevuld met de planning van de beschikbare capaciteit van netwerk, rekenkracht en opslag. Zodoende kan worden beoordeeld in welke mate de kritische grenzen zijn bereikt. De wijze waarop incident en performance management wordt ingevuld binnen de organisatie, geeft informatie over de volwassenheid van de beheerorganisatie. De service level rapportages hierover geven inzage in de feitelijke incidenten, problemen en prestaties van de systemen en de organisatie.

Beveiliging

Beveiliging is van groot belang bij financiële instellingen. Dit onderdeel speelt dan ook een belangrijke rol in het due diligence-onderzoek. De IT-auditor moet het algemene beveiligingsbeleid van de organisatie en in het bijzonder dat van de ICT-afdeling opvragen.

Per systeem wordt beoordeeld of de systemen die de financiële processen ondersteunen voldoende beveiligd zijn. Ten aanzien van de gesignaleerde risico’s moet een overzicht van de getroffen maatregelen aanwezig zijn, om in te schatten in welke mate de onderliggende bedrijfsprocessen risico lopen. Hierbij kan worden gedacht aan uitwijkprocedures, back-up en recovery.

Aanvullend hierop geven rapportages van (interne en externe) auditors of toezichthouders een goed beeld van mogelijke onvolkomenheden op het gebied van beveiliging.

Contracten

Lopende contractuele verplichtingen verschaffen inzicht in de te verwachten kosten gedurende de komende jaren en op welke termijn deze mogelijk afgekocht zouden kunnen worden.

Contracten geven de IT-auditor inzage in alle diensten en producten die de organisatie afneemt bij derden en de financiële verplichtingen die daarbij horen. Gezien de kennis die een IT-auditor heeft van ICT is het beoordelen van ICT-gerelateerde contracten een waardevolle aanvulling op de juridische due diligence. Diensten die worden afgenomen, hebben veelal betrekking op de volgende onderwerpen:

  • de inzet van externen;
  • projecten;
  • hardware (onder meer onderhoud);
  • datacommunicatie;
  • software (onder meer onderhoud en licenties);
  • toegang/gebruik van systemen door derden;
  • uitwijkfaciliteiten;
  • escrow (ten behoeve van programmatuur);
  • uitbesteding;
  • mogelijkheden om contracten aan te passen aan de overnemende organisatie.

Het is van belang te kijken welke financiële verplichtingen uit deze contracten voortvloeien en hoelang een contract nog van toepassing is onder geldende voorwaarden (bijvoorbeeld ontvangen korting). De IT-auditor let hierbij op het eigenaarschap van de geleverde diensten, bijvoorbeeld servers, software en externen. Dit is onder andere van belang wanneer de kopende organisatie van plan is de contracten te beëindigen na het samenvoegen van de organisaties. Ook dient er aandacht besteed te worden aan de betrouwbaarheid en de levensvatbaarheid van de leverancier. Mogelijk wordt deze leverancier binnenkort overgenomen, stopt hij met enkele diensten of voldoet hij niet aan de hoge(re) eisen die de kopende organisatie stelt aan zijn diensten.

Wet- en regelgeving

Op diverse plaatsen in wet- en regelgeving wordt over data, gegevensverwerking, bewaren van data en privacy gesproken. Onder andere de Wbp[Wet bescherming persoonsgegevens.], Wft[Besluit van 12 oktober 2006, houdende prudentiële regels voor financiële ondernemingen die werkzaam zijn op de financiële markten (Besluit prudentiële regels Wft).] en MiFID[Markets in Financial Instruments Directive.] stellen eisen op deze terreinen. Voor en na de overname is het al van groot belang hier rekening mee te houden.

  • Op het gebied van privacy dient bij het samenvoegen van klantgegevens rekening te worden gehouden met de Wbp. ‘Deze wet is van toepassing op de geheel of gedeeltelijk geautomatiseerde verwerking van persoonsgegevens’. Wanneer klantgegevens van eigenaar wisselen (zoals bij een overname het geval is), moet de klant hierover worden geïnformeerd. Vanuit technisch oogpunt is het mogelijk en vaak ook wenselijk gegevens binnen de gehele organisatie samen te voegen en aan elkaar te koppelen. Soms moeten klantgegevens echter gescheiden worden bewaard van andere organisatieonderdelen. Ook dient de overnemende organisatie rekening te houden met het doel waarvoor de persoonsgegevens aanvankelijk zijn verzameld door de overgenomen organisatie. De Wbp schrijft voor dat de verwerking van de gegevens ‘niet onverenigbaar’ mag zijn met het doel waarvoor de persoonsgegevens zijn verzameld. Cliënten moeten tevens worden geïnformeerd over de nieuwe ontwikkelingen bij de kopende organisatie betreffende de gegevensverwerking en hebben het recht bezwaar (‘recht van verzet’) hiertegen te maken. Daarnaast worden er een bewaarplicht en -termijn van de gegevens voorgeschreven in de Wbp.
  • De Wft stelt met name eisen aan de maatregelen die de organisatie dient te nemen om informatiesystemen goed te kunnen beheren. Zo dient de organisatie te beschikken over een ‘informatiesysteem dat een effectieve beheersing van de bedrijfsprocessen en de risico’s mogelijk maakt’. Daarnaast moet de organisatie maatregelen treffen ten aanzien van de integriteit, beschikbaarheid, functiescheiding en beveiliging van geautomatiseerde gegevensverwerking. Een financiële instelling is verplicht te beschikken over ‘een onafhankelijke compliancefunctie voor het toezicht op de naleving van wettelijke regels en van interne regels’ die door de organisatie zelf zijn opgesteld.
  • In de MiFID is vastgelegd hoe organisaties dienen om te gaan met de afhandeling van aandelenorders door beleggingsorganisaties, waarbij de transparantie een belangrijk aandachtspunt is. De MiFID heeft als doel ‘de bevordering van een eerlijke, transparante, efficiënte en geïntegreerde financiële markt met behoud van optimale beleggersbescherming’. Er worden expliciete regels gesteld aan bijvoorbeeld de organisatiestructuur, informatiesystemen, rapportages, persoonlijke transacties en uitbesteding.

Volwassenheid van de ICT-organisatie

Een volledig uitgevoerde ICT due diligence biedt voldoende inzicht in de ICT-organisatie om zich een oordeel over de volwassenheid van (delen van) de ICT-organisatie te kunnen vormen. Een veelgebruikt model hiervoor is het Stages of growth-model van Richard L. Nolan. Dit model onderkent de volgende fasen in volwassenheid van een ICT-organisatie:

  1. Het stadium ‘initiation’ wordt gekenmerkt door lage uitgaven aan dataprocessing en beperkte betrokkenheid van gebruikers en management.
  2. Voor het stadium ‘contagion’ is het kenmerkend dat budgetten hoger worden en tegelijkertijd het gebruik van systemen erg snel toeneemt, wat voor een ongecontroleerde omgeving met incidenten zorgt.
  3. Vervolgens wordt bij ‘control’ dataprocessing serieus genomen door het management en er worden controls geformuleerd om systemen te beheersen. Desondanks is communicatie tussen systemen nog foutgevoelig.
  4. In het stadium ‘integration’ krijgt dataprocessing een groter budget toegekend en worden online diensten verlangd door gebruikers. Het management past meer formele werkwijzen toe, zoals projectmanagement, standaardprocedures en controls.
  5. De applicatieportfolio is bij ‘data administration’ geïntegreerd in de organisatie. Dataprocessing wordt nu als dienst aangeboden.
  6. Als laatste kenmerkt het stadium ‘maturity’ zich door de strategische plek die dataprocessing in de organisatie krijgt. De CIO en de CFO hebben een even belangrijke rol toebedeeld gekregen.

Op te vragen informatie

In het voorgaande zijn documenten en informatie genoemd die de IT-auditor nodig heeft bij het opstellen van zijn rapportage. Deze documenten worden tegenwoordig steeds vaker digitaal aangeleverd in een virtual dataroom. De over te nemen organisatie levert eenmalig alle data op die op een centrale, virtuele plek benaderd kunnen worden door financiële, ICT- en juridische experts. Mede omdat de documenten vaak voor diverse experts van interessant zijn (bijvoorbeeld ICT-contracten) werkt dit efficiënter. Deze datarooms en de opgeslagen documenten zijn uitgebreid beveiligd. Uitgifte van gebruikersrechten is over het algemeen in handen van het begeleidend advocatenkantoor.

Uiteraard is het van belang met enkele belangrijke functionarissen, zoals de CIO en de CTO, een gesprek te hebben om zo meer inzicht te krijgen over de ontvangen informatie. Verder kan de IT-auditor tijdens het interview ingaan op nog openstaande vragen.

Op te leveren eindproduct (rapport)

In het rapport worden de feitelijke observaties gescheiden van de bevindingen. Zodoende wordt duidelijk wat enerzijds is geconstateerd en anderzijds welk (mogelijk) effect dat in de ogen van de IT-auditor op de ICT-organisatie heeft.

In figuur 2 is een voorbeeld gegeven van een uitgevoerde analyse van de ontwikkeling van de ICT-kosten ten opzichte van het aantal te verwerken transacties binnen een financiële instelling. Aanvullend hierop kunnen berekeningen worden gemaakt om de kosten per transactie of het percentage ICT-kosten als deel van de totale kosten te verkrijgen.

C-2008-1-Koets-02

Figuur 2. ICT-kosten versus de totale kosten en het aantal transacties.

Onderstaand zijn ter illustratie enkele bevindingen uit IT due diligence-rapportages opgenomen:

  • Het ICT-personeel op de sleutelposities heeft veel kennis van de ICT-omgeving en werkt gemiddeld 20 à 25 jaar bij bedrijf X. Hierdoor is bedrijf X erg afhankelijk van deze medewerkers, wat mede wordt veroorzaakt door de complexiteit van de ICT-infrastructuur en het gebrek aan documentatie.
  • Het project voor het vervangen van de infrastructuur kost € 4,8 miljoen. Dit is de komende vier jaar het belangrijkste project. Een groot deel van deze investering, à € 1,26 miljoen, is nodig omdat netwerkcomponenten de komende jaren aan het einde van hun life cycle zijn.
  • Systeem A is een erg complexe applicatie, die niet volledig gedocumenteerd is. In de nabije toekomst zal een migratie naar een .NET-omgeving overwogen moeten worden.

Aanpak tijdens en belang van de fase na afronding van de fusie

Om tijdig inzicht te krijgen in de mogelijke knelpunten bij integratie dient gedurende het due diligence-onderzoek aandacht te worden besteed aan de mate van integratie die wordt nagestreefd. Indien de organisatie een hoge mate van integratie nastreeft, is een onderzoek naar de mogelijkheden om de ICT-organisatie, -systemen en -projecten te integreren, relevanter dan bij een lagere mate van integratie. Derhalve dient het management van de overnemende organisatie in een vroeg stadium te beslissen over de gewenste en verwachte mate van integratie na de fusie, onder andere in verband met de te behalen mate van efficiency.

Zelfs bij overname van een financiële instelling met vergelijkbare processen kan de integratie een uitdaging worden. Indien verschillende applicaties en infrastructuur worden gebruikt, kan integratie een ingewikkeld traject worden. Op basis van zijn kennis en ervaring kan de IT-auditor ook na de fusie een belangrijke rol in de integratie spelen. Dit kan een beoordelende (quality assurance) rol tijdens het project zijn, maar ook een actieve rol in het projectmanagement of bij uitvoerende werkzaamheden tijdens de integratie. Verder kan met data-analyse de conversie gecontroleerd worden op juistheid en volledigheid.

Samenvatting

In dit artikel hebben wij het belang van een ICT-onderzoek toegelicht en de rol die de IT-auditor binnen een due diligence-onderzoek kan spelen. Tevens is aangegeven welke aandachtspunten de IT-auditor daarbij hanteert.

De ICT due diligence heeft inzicht gegeven in de status (volwassenheid) van de ICT en de ICT-organisatie en in mogelijke knelpunten. Afhankelijk van de integratiedoelstellingen van de organisatie is het van belang al voor de fusie een integratieplan op te stellen zodat na de fusie voortvarend kan worden begonnen met de integratie. In deze fase kan de IT-auditor vanuit zijn ervaring met ICT-organisaties en complexe veranderingstrajecten een belangrijke adviserende of controlerende rol spelen tijdens het integratieproces.

De inwerkingtreding van de Wft: wat verandert voor de IT-auditor?

Met de komst van de Wft is de wetgeving voor de financiële markten doelgerichter, marktgerichter en transparanter geworden. Dit is bereikt door van acht verschillende wetten één wet te maken, voor zoveel mogelijk onderwerpen één algemene regel te maken en in de wet de taken van DNB en AFM te omschrijven en de samenwerking tussen beide toezichthouders te regelen.

Inleiding

De Wet op het financieel toezicht (Wft) is op 1 januari 2007 in werking getreden. Deze wet regelt het toezicht op de financiële sector (met uitzondering van pensioenfondsen) in Nederland. Toezichtwet- en regelgeving heeft een lange geschiedenis. Oorspronkelijk was het toezicht op financiële ondernemingen per sector georganiseerd. Elke sector kende zijn eigen toezichtwet: een wet voor banken, een wet voor verzekeraars, een wet voor beleggingsinstellingen, enzovoort. De bepalingen van de verschillende wetten regelden veelal dezelfde onderwerpen. Voorbeelden zijn een vergunningplicht voor het aanbieden van bepaalde financiële diensten, regels ten aanzien van de bedrijfsvoering en betrouwbaarheidstoetsing van bestuurders. Op de financiële markten vond in toenemende mate een vervlechting plaats van ondernemingen en producten. Binnen de verschillende ondernemingen was steeds meer sprake van sectoroverstijgende activiteiten. Daarom werd in 2002 besloten tot een herziening van het toezicht op de financiële markten van het sectorale model naar een functioneel model. De Wft is het sluitstuk van deze herziening ([AFM06]).

In dit artikel staan de Wft en de impact hiervan op de werkzaamheden van de IT-auditor centraal. In de eerste paragraaf wordt beschreven wat er is veranderd met de komst van de Wft. In de volgende paragraaf wordt dieper ingegaan op raakvlakken van de Wft met de door een IT-auditor gehanteerde toetsingskaders. In de derde paragraaf wordt beschreven wat de gevolgen zijn voor de werkzaamheden van een IT-auditor. Het artikel sluit af met een conclusie.

Wat zijn de gevolgen van de invoering van de Wft?

De Wft vervangt acht toezichtwetten ([DNB08]), waaronder de Wet toezicht kredietwezen 1992 (Wtk), de Wet toezicht beleggingsinstellingen en de Wet financiële dienstverlening. Waar bancaire ondernemingen eerder moesten voldoen aan de Wet toezicht kredietwezen (Wtk) en de richtlijnen voor de uitvoering van toezicht, zoals de Regeling Organisatie en Beheersing (ROB), moeten banken vanaf 1 januari 2007 voldoen aan de wetgeving in de Wft en de daaraan gekoppelde regelgeving.

C-2008-1-Jagt-01

Figuur 1. De weg naar de Wet op het financieel toezicht.

Het doel van de Wft is de regelgeving voor financiële markten doelgerichter en inzichtelijker te maken. Ook zijn de regels waaraan financiële instellingen moeten voldoen eenvoudiger gemaakt ([AFM06]). De Wft bestaat uit zes delen ([AFM06]):

  • Algemeen;
  • Markttoegang financiële ondernemingen;
  • Prudentieel toezicht financiële ondernemingen;
  • Gedragstoezicht financiële ondernemingen;
  • Gedragstoezicht financiële markten; en
  • Toezicht afwikkelsystemen.

Het deel Toezicht afwikkelsystemen zal later aan de wet worden toegevoegd.

De Wft regelt een aantal specifieke vormen van samenwerking tussen de AFM als gedragstoezichthouder en DNB als prudentieel toezichthouder. Hierdoor sluit de Wft – beter dan de oude wetgeving – aan bij de manier waarop er in Nederland toezicht wordt gehouden op financiële markten:

  • De Nederlandsche Bank (DNB) voert het prudentieel toezicht, dat wil zeggen dat DNB de financiële stabiliteit (solvabiliteit en liquiditeit) en de betrouwbaarheid van financiële ondernemingen controleert.
  • De Autoriteit Financiële Markten (AFM) voert het gedragstoezicht, wat inhoudt dat de AFM de marktwerking, de toetreding en het vertrouwen daarin controleert en bevordert.

De taakafbakening tussen DNB en AFM voorkomt niet dat beide toezichthouders actief zijn binnen dezelfde financiële sector. Mede om overlap in de uitoefening van de toezichttaken te voorkómen, is in de Wft zoveel mogelijk geregeld dat steeds één toezichthouder de bevoegdheid heeft om een besluit te nemen ([AFM06]).

Voor het gedragstoezicht zijn vooral de delen Algemeen, Markttoegang financiële ondernemingen, Gedragstoezicht financiële ondernemingen en Gedragstoezicht financiële markten relevant. Het deel Algemeen vormt de basis van het wettelijk kader. Hierin zijn de taken en bevoegdheden van de toezichthouders vastgelegd. In het deel Markttoegang financiële ondernemingen worden toegang tot de financiële markten en de vergunningplichtige activiteiten beschreven. Daarnaast zijn de voorwaarden vastgelegd waaronder een buitenlandse financiële onderneming toegang tot de Nederlandse financiële markten kan krijgen. Het deel Gedragstoezicht financiële ondernemingen bevat de regels waaraan financiële ondernemingen moeten voldoen bij het verlenen van hun diensten, zoals de regels voor het informeren van consumenten. Het deel Gedragstoezicht financiële markten bevat de regels waaraan spelers op de financiële markten zich te houden hebben, zoals de regels inzake marktmisbruik, emissies, openbare biedingen, melding van zeggenschap en kapitaalbelang in uitgevende instellingen ([AFM06]). De toezichthouder voor deze onderdelen is de AFM.

Voor prudentieel toezicht is het deel Prudentieel toezicht financiële ondernemingen relevant. Dit deel bevat de regels voor partijen op de financiële markten om aan hun financiële verplichtingen te voldoen. De toezichthouder voor dit deel is DNB.

De bepalingen zoals neergelegd in de Wft worden uitgewerkt in de onderliggende regelgeving. Deze bestaat uit twaalf besluiten of zogenaamde Algemene Maatregelen van Bestuur (AMvB’s) ([MiFi07]). In figuur 2 is de wet- en regelgeving weergegeven en is te zien hoe de lagere regelgeving zich verhoudt tot de diverse delen van de wet.

C-2008-1-Jagt-02

Figuur 2. Indeling Wet op het financieel toezicht.

Waarop en op wie is de Wft van toepassing?

De Wft geldt voor financiële ondernemingen en voor andere partijen die actief zijn op de financiële markten ([AFM06]). Een integrale wetgeving impliceert een integrale controle voor alle financiële instellingen. Toch wil het samenvoegen van alle regels nog niet zeggen dat de hele wet steeds van toepassing is op een specifieke financiële onderneming. Er wordt bijvoorbeeld in de wettekst onderscheid gemaakt tussen de wetgeving voor beleggingen en de wetgeving voor verzekeringen. Het is dus belangrijk om een goed overzicht te krijgen en te houden van de delen van de wetgeving die van toepassing zijn op de onderneming in kwestie. In de wet wordt aangegeven op welke product- en dienstcombinaties de Wft van toepassing is. Per productsoort gelden bovendien specifieke eisen. Een onderneming die verschillende producten aanbiedt moet dus aan verschillende eisen voldoen. De producten waarop de Wft van toepassing is, zijn ([SCFB06]):

  • verzekeringen leven;
  • verzekeringen schade;
  • consumptief krediet;
  • hypotheken;
  • sparen en betalen (betaalrekeningen, spaarrekeningen);
  • elektronisch geld;
  • beleggen[De Wft is beperkt van toepassing op beleggingen omdat er al een effectenwet is die veel regelt. Onder de Wft valt alleen het uitsluitend adviseren over beleggingen in effecten en het aanbieden van, adviseren over en bemiddelen in beleggingsobjecten.].

De nieuwe wet geldt onder meer voor:

  • aanbieders van financiële producten:
    • verzekeraars,
    • banken;
  • aanbieders van consumentenkrediet;
  • aanbieders van beleggingsobjecten;
  • adviseurs met betrekking tot financiële producten;
  • bemiddelaars inzake financiële producten, inclusief bedrijven die het bemiddelen als nevenactiviteit hebben;
  • herverzekeringsbemiddelaars;
  • (onder)gevolmachtigde agenten.

Wat zijn de raakvlakken van de Wft met het controleraamwerk van een IT-auditor?

In deze paragraaf wordt beschreven welke onderdelen uit de Wft raakvlakken hebben met het vakgebied van een IT-auditor. Alvorens de attentiepunten uit de Wft voor de IT-auditor te behandelen, is het eerst van belang het controleraamwerk van de IT-auditor te beschrijven. Figuur 3 geeft een globaal overzicht van de onderwerpen die onderdeel uit kunnen maken van een IT-audit in het kader van de jaarrekeningcontrole waarbij de nadruk ligt op de betrouwbaarheid van de geautomatiseerde gegevensverwerking.

C-2008-1-Jagt-03_kl

Figuur 3. IT-controleraamwerk.

De Wft heeft invloed op verschillende niveaus van het bovenstaande IT-controleraamwerk. In dit artikel komen per niveau, zoals weergegeven in figuur 3, attentiepunten aan de orde. Deze attentiepunten zijn gerelateerd aan de relevante artikelen uit de Wft en de begeleidende Algemene Maatregelen van Bestuur (AMvB).

De Wft vormt in feite de raamwet waarbij AMvB’s voor concrete invulling zorgen. In dit artikel wordt volstaan met een bondige en adequate beschrijving van hetgeen op hoofdlijnen in de wet of AMvB is vastgelegd. Wel wordt een verwijzing gemaakt naar artikelen en hoofdstukken waaruit het attentiepunt afkomstig is.

De Wft schrijft vooral op het niveau van IT-governance een aantal belangrijke regels voor. In tabel 1 is een overzicht gegeven van de artikelen uit de Wft die raakvlakken hebben met het IT-controleraamwerk van de IT-auditor op het hoogste niveau (IT-governance).

C-2008-1-Jagt-tab01_kl

Tabel 1. Richtlijnen Wft voor IT-governance.

Op de onderliggende niveaus (ITGC, application controls en IT dependent manual controls) schrijft de wet minder specifieke regels voor. In de tabellen 2 en 3 is weergegeven welke artikelen uit de Wft raakvlakken hebben met de overige niveaus uit het IT-controleraamwerk.

C-2008-1-Jagt-tab02_kl

Tabel 2. Richtlijnen Wft voor IT General Controls.

C-2008-1-Jagt-tab03_kl

Tabel 3. Richtlijn Wft voor application controls.

Centraal in de Wft staat een beheerste en integere bedrijfsvoering. Deze vormt tevens het vertrekpunt voor de externe toezichthouder om de naleving op de Wft te toetsen. Om dit te kunnen realiseren is risicomanagement belangrijk. Risicomanagement is dan ook verplicht gesteld in de Wft en is het vertrekpunt voor het te voeren beleid van een organisatie. Instellingen bepalen zelf op welke manier zij hun doelstellingen willen halen, zolang de keuzen maar zijn onderbouwd door middel van een risicoanalyse. Informatietechnologie is in dit keuzeproces een belangrijke ondersteunende factor, maar geen doel op zich. De Wft stimuleert zelfregulering.

DNB heeft ten behoeve van het uitoefenen van toezicht een methodologie opgesteld voor het uitvoeren van een risicoanalyse (FIRM). Deze methodologie wordt door DNB gehanteerd bij het uitvoeren van toezicht op de onder toezicht staande financiële instellingen, onder meer voor het opsporen van hoge inherente risico’s en zwakke mitigerende beheersingsmaatregelen. Daarnaast wordt de methodologie door DNB gebruikt om de nadruk te leggen op die ondernemingen, of activiteiten binnen de organisatie, met een hoog risicoprofiel ([DNB]). De risicoanalyse en de daaruit voortvloeiende beoordelingscriteria kunnen ook door de instellingen gebruikt worden ter ondersteuning bij het uitvoeren van de risicoanalyse. Ook de IT-auditor kan gebruikmaken van deze risicoanalyse.

Uitbesteding is tevens een belangrijk onderwerp voor de IT-auditor. Voorheen was voor financiële instellingen de ROB van toepassing, waarin een tweetal paragrafen is opgenomen waaraan de uitbestedende partij moest voldoen. In het verleden is aan de IT-auditor gevraagd om in het kader van de jaarrekeningcontrole een uitspraak te doen in welke mate de instelling de ROB had nageleefd. De onderdelen van de ROB welke van toepassing zijn voor de IT-auditor betreffen ([Beug01]):

  • paragraaf 2.5 Informatietechnologie (IT);
  • paragraaf 2.6 Uitbesteding van (delen van) bedrijfsprocessen.

Doordat met de komst van de Wft de ROB is komen te vervallen, hebben veel IT-auditors moeite om de artikelen terug te vinden in de Wft. Tabel 4 geeft een overzicht van de artikelen uit de ROB met de verwijzing naar het corresponderende artikel in de Wft.

C-2008-1-Jagt-tab04_kl

Tabel 4. Referentieoverzicht ROB naar Wft.

Een aantal verschillen tussen de ROB en Wft is opmerkelijk. Door het verdwijnen van het verplichte karakter van de ROB lijkt het alsof een aantal specifieke eisen die door DNB aan uitbesteding werden gesteld, is komen te vervallen. De toezichthouder maakte in de ROB bijvoorbeeld geen verschil tussen interne en externe uitbesteding. De serviceorganisatie hoeft volgens DNB geen derde te zijn. In de definitie van DNB zit besloten dat het uitbesteden van een activiteit waarbij vertrouwelijke (kwetsbare) informatie de entiteit verlaat, door DNB wordt gezien als uitbesteding. Het gaat bij uitbesteding van (deel)processen steeds om risico’s die een materiële invloed kunnen hebben op de financiële prestaties, de financiële positie, continuïteit of reputatie van de instelling. Voor deze beoordeling is een onderscheid tussen bancaire en ondersteunende processen als zodanig niet relevant. Tijdens het consultatieproces van de Wft is echter bewerkstelligd dat de Wft alleen van toepassing is op ‘wezenlijke’ (d.w.z. externe) uitbesteding. Dit zou een ‘verlichting’ ten opzichte van de huidige regelgeving zijn, aangezien de ROB externe en interne uitbesteding gelijkstelt qua eisen ([Bakk06]).

Een tweede belangrijk verschil ten opzichte van de ROB is dat minder nadruk wordt gelegd op een door de instelling op te stellen risicoanalyse bij een uitbesteding. In de Wft is geen specifieke eis opgenomen met betrekking tot het uitvoeren van een risicoanalyse in het kader van uitbesteding. Echter, zoals eerder genoemd, zijn in AMvB 5 wel algemene eisen gesteld aan het risicomanagementproces van de organisatie. Tevens zijn in AMvB 5 (Besluit prudentiële regels financiële ondernemingen; Bpr) en AMvB 8 (Besluit gedragstoezicht financiële ondernemingen; Bgfo) specifieke voorschriften over uitbesteding opgenomen. Als de uitvoering van operationele taken door een derde partij wordt overgenomen, moeten maatregelen worden getroffen die tot doel hebben het operationele risico te beperken. Omdat uitbesteding geen afbreuk mag doen aan de kwaliteit van de interne controle en geen belemmering mag vormen voor de werkzaamheden van toezichthouders (zowel AFM als DNB) blijft de onderneming verantwoordelijk voor alle diensten die worden uitbesteed aan derden. De eisen zullen derhalve moeten worden overgenomen in het uitbestedingscontract (service level agreement), bijvoorbeeld tijdige rapportage aan toezichthouders. De financiële instelling zal de uitvoering van de werkzaamheden moeten monitoren en controleren. Om aan deze eisen uit de Wft te voldoen kan uiteraard nog steeds goed gebruik worden gemaakt van de artikelen uit de ROB. De verwachting hiermee is dus dat er geen grote veranderingen zullen optreden. Indien een onderneming besluit over te gaan op uitbesteding van een activiteit zal dit op een beheerste wijze moeten worden uitgevoerd. Om dit proces te toetsen zal ook de (IT-)auditor nog steeds goed gebruik kunnen maken van de artikelen uit de ROB.

De impact van ‘rule based’-toezicht naar ‘principle based’-toezicht voor de IT-auditor

Huidige financiële ondernemingen en markten zijn te complex om ‘alles’ in detailregels te kunnen vastleggen. De invoering van de Wft brengt hier verandering in, doordat het toezicht in toenemende mate verandert van ‘rule based’-toezicht naar ‘principle based’-sturing. Terwijl ‘rule based’-toezicht tot achter de komma voorschrijft welke maatregelen door een organisatie moeten worden getroffen, laat ‘principle based’-toezicht meer vrijheid aan de organisatie zelf (zelfregulering). Inhoudelijk leidt de invoering van de Wft dus niet tot grote wijzigingen. Centraal staat een integere en beheerste bedrijfsvoering. Een organisatie krijgt hiermee meer vrijheid voor de inrichting van haar administratieve organisatie. Dit heeft tot gevolg dat ‘principle based’-toezicht een minder normatief karakter kent. Echter, vanuit het externe toezicht zal wel worden gekeken wat het meest gangbaar is.

De rol van de IT-auditor bevindt zich dus ook in de overgangsfase van ‘rule based’-audit naar ‘principle based’-audit. Van het signaleren van fouten op basis van strakke toetsingskaders naar het signaleren van risico’s ter voorkoming van fouten. Daarbij doet zich een dilemma voor. Het blijkt lastig om risico’s te inventariseren. Toezicht werkt alleen ‘principle based’ als de inbreng van de auditor als een signaal om van te leren wordt opgevat. Van ‘rule based’ overstappen naar ‘principle based’ houdt ook in, dat je verder kijkt dan alleen de regels. De IT-auditor zal uitdrukkelijk de kwaliteit van de IT-processen en de prestaties waar een organisatie voor staat, in de audit moeten betrekken. Omdat de IT-auditor geen vast toetsingskader meer heeft, zal deze zich dus meer richten op het risicomanagementproces. Op welke manier heeft de organisatie het risicomanagementproces ingericht? Hoe kan de organisatie aantoonbaar maken dat de onderneming haar risico’s beheerst?

De gevolgen van deze veranderingen brengen met zich mee dat IT-auditors niet meer wegkomen met standaardvragenlijsten/normenkaders, maar steeds meer beleidsmatig en procedureel naar vraagstukken zullen kijken. De vraagstukken zijn hiermee steeds complexer geworden, omdat het beoordelen van beleid en procedures (vaak) onvoldoende zekerheid geeft. Het uitvoeren van een ‘principle based’-audit zal ertoe moeten leiden dat op basis van een risicoanalyse de IT-auditor in de diepte onderzoek moet uitvoeren naar (de beheersing van) de IT-processen met een ‘hoog risico’-classificatie en conclusies moet trekken op basis van detailbevindingen over wezenlijke problemen en oplossingen.

Conclusie

De conclusie is dat – hoewel een vrij uitgebreide lijst met voorwaarden is opgesteld – de Wft ten opzichte van de huidige regelgeving geen significante ‘verzwaringen’ en veranderingen met zich meebrengt voor de IT-auditor. Dit is natuurlijk ook niet vreemd gezien het feit dat de financiële instellingen altijd al aan het toezicht van DNB en AFM waren onderworpen door regels die in verschillende wetgevingen waren verankerd. Daarom kan in de praktijk nog steeds goed gebruik worden gemaakt van bijvoorbeeld sound practices van het British Standards Institute (BIS), de Regeling Organisatie en Beheersing en het toetsingskader business continuity planning (BCP).

De Wft is ‘principle based’ en dus niet ‘rule based’. Er staan wel regels in maar het gaat bij instellingen om de handhaving van de principes. Principes als integer handelen, de principes die de instelling verwoord heeft in haar corporate values en de principes die ten grondslag liggen aan een solide bedrijfsvoering. Een dergelijke benadering vraagt zowel van de instelling als van de toezichthouder andersoortige inspanningen. Er zijn immers geen gedetailleerde regels waar het allemaal in staat. Het auditkader wordt gevormd door de wetgeving (Wet op het financieel toezicht) en reeds bewezen sound practices.

Literatuur

[AFM06] Autoriteit Financiële Markten, Belangrijkste wijzigingen gedragstoezicht bij invoering Wft, oktober 2006.

[Bakk06] Drs. R.W.A. Bakkers, De rol van de compliancefunctie in het uitbestedingproces, Tijdschrift voor compliance 2006-5.

[Beug01] B. Beugelaar en M. Ooms-Pieper, Checklist IT aspecten Regeling Organisatie en Beheersing (ROB), Versie 1.0, 28 november 2001.

[DNB01] De Nederlandsche Bank, Richtlijnen Organisatie en Beheersing, www.dnb.nl.

[DNB05] De Nederlandsche Bank, Handboek Financiële Instellingen Risicoanalyse Methode, www.dnb.nl.

[DNB08] De Nederlandsche Bank, Wet op het financieel toezicht, www.dnb.nl/dnb/home/toezicht/nieuwe_toezichtwetgeving/wet_op_het_financieel_toezicht.

[MiFi07] Ministerie van Financiën, Wet op het Financieel Toezicht, AMvB’s en ministeriële regelingen, november 2007.

  • Besluit bekostiging financieel toezicht (AMvB 1)
  • Besluit definitiebepalingen (AMvB 2)
  • Besluit boetes Wft (AMvB 3)
  • Besluit markttoegang financiële ondernemingen (AMvB 4)
  • Besluit reikwijdte bepalingen (AMvB 4a)
  • Besluit prudentiële regels Wft (AMvB 5)
  • Besluit bijzondere prudentiële maatregelen, beleggerscompensatie en depositogarantie (AMvB 6)
  • Besluit prudentieel toezicht financiële groepen (AMvB 7)
  • Besluit Gedragstoezicht financiële ondernemingen (AMvB 8)
  • Besluit melding zeggenschap en kapitaalbelang in uitgevende instellingen (AMvB 9)
  • Besluit marktmisbruik Wft (AMvB 10).

[SCFB06] StudieCentrum Financiële Branche, Invoering Wft: grote gevolgen voor financieel adviseurs, 2006 (http://www.scfb.nl/artikel/110.htm).

SEPA: de impact op Europees betalingsverkeer

Voor velen is SEPA nu wellicht nog een onduidelijk begrip, maar SEPA zal de komende tijd de nodige aandacht gaan opeisen. Het is een flinke uitdaging voor banken, maar wel één die belangrijke kansen biedt. SEPA is op 28 januari 2008 in werking getreden. Dit artikel beschrijft de impact van SEPA op het huidige interbancaire binnenlands en buitenlands betalingsverkeer. Tevens gaat het in op de keuzen die een bank gemaakt heeft en welke variabelen van invloed zijn geweest op die keuze. Het artikel sluit af met een beschouwing van de relevantie van SEPA voor de IT-auditor.

Inleiding

Globalisering, consolidatie in de financiële sector en technologische ontwikkeling zijn de voornaamste trends die in het recente verleden – en tevens in de toekomst – tot een verandering van het interbancair betalingsverkeer hebben geleid en zullen leiden. Door de wereldwijde globalisering is het grensoverschrijdend betalingsverkeer de laatste decennia sterk gegroeid. In Europa is dit effect versterkt door de komst van de euro en door de ingebruikname van een Europees settlementsysteem (TARGET). Terwijl begin 1999 slechts één op de acht interbancaire betalingen over de grens werd gestuurd, geldt dit nu voor bijna één op de vier ([Capg06]). Deze ontwikkeling weerspiegelt de toegenomen Europese economische en financiële verwevenheid en is een teken dat het eurogebied steeds meer beschouwd kan worden als één markt.

Als gevolg van bovenstaande ontwikkelingen hebben de Europese Commissie en het Europese Systeem van Centrale Banken de ambitie uitgesproken om de huidige diversiteit van (lokale) betaalinstrumenten binnen Europa te transformeren naar één geïntegreerde markt. Eén van de initiatieven die tot het bereiken van deze ambitie moet leiden, is SEPA. SEPA staat voor Single Euro Payments Area, waarin de klant gebruik kan maken van een gestandaardiseerde set betaalinstrumenten voor overschrijvingen (credit transfer), automatische incasso (direct debit) en debit- en creditcards. Iedere grensoverschrijdende eurobetaling dient met hetzelfde serviceniveau en tegen dezelfde tarieven te worden verwerkt. De banken hebben een belangrijke taak in het realiseren van SEPA. In dit artikel staat het onderwerp SEPA en de impact hiervan op Nederlandse banken centraal. In de eerste paragraaf wordt de bestaande infrastructuur voor betalingsverkeer beschreven. In de volgende paragraaf wordt dieper ingegaan op de inhoud en vereisten van SEPA, waarna de impact banken in de derde paragraaf wordt beschreven. Mogelijke scenario’s voor de toekomstige infrastructuur voor betalingsverkeer komen in de vierde paragraaf aan de orde, waarna in de laatste paragraaf de relevantie van SEPA voor de IT-auditor wordt belicht. Het artikel sluit af met een conclusie.

Hoe is de bestaande infrastructuur voor betalingsverkeer weergegeven?

Door de introductie van SEPA is de bestaande infrastructuur voor het verwerken van betalingsopdrachten aangepast. SEPA schrijft een Europese clearing- en settlementinfrastructuur voor, terwijl de bestaande infrastructuur voor clearing en settlement zich voornamelijk op nationaal niveau heeft ontwikkeld. Om uiteindelijk tot een inschatting te komen van de impact van de invoering van SEPA, worden allereerst de basisprincipes van het huidige functioneren van de betaalmarkt beschreven.

Figuur 1 geeft de principes weer van het bestaande betalingsverkeer binnen de eurozone.

C-2008-1-Houwelingen-1

Figuur 1. Overzicht huidige betalingsverkeer binnen de eurozone. [Klik hier voor grotere afbeelding]

In Nederland was het TOP-systeem een Real Time Gross Settlement (RTGS)-systeem dat zorgde voor de afwikkeling van nationaal interbancair betalingsverkeer. Zoals in Nederland gebruik werd gemaakt van TOP, maakte elke centrale bank (binnen de eurozone) gebruik van een eigen RTGS-systeem. Een basisprincipe voor het buitenlands betalingsverkeer is dat iedere lokale bank een rekening heeft bij de centrale bank van het betreffende land. Doordat de RTGS-systemen van de centrale banken met elkaar kunnen communiceren, kunnen betalingen in de eurozone relatief eenvoudig worden afgehandeld. De RTGS-systemen van de verschillende landen samen worden ook wel TARGET genoemd.

Met TOP/TARGET is een systeem gerealiseerd dat een veilige en betrouwbare basis verzorgt voor grensoverschrijdende betalingen op RTGS-basis. Op deze wijze vond een directe en definitieve afhandeling van betalingen plaats (hard betalingsverkeer), op voorwaarde dat de opdrachtgevende bank voldoende dispositieruimte had bij haar centrale bank. De rekening van de ontvangende bank wordt niet gecrediteerd voordat de rekening van de zendende bank is gedebiteerd dan wel dat de dispositieruimte is geblokkeerd, waardoor bij de ontvangende bank altijd zekerheid bestaat over via TARGET te ontvangen gelden. TARGET vormt hierdoor het meest betrouwbare systeem voor het afhandelen van betalingsverkeer.

Naast TARGET wordt ook een ander systeem gebruikt voor het afhandelen van hoogwaardig betalingsverkeer in euro’s, namelijk EURO1. EURO1 wordt beheerd door de Euro Banking Association (EBA) en is een nettosettlementsysteem voor de afhandeling van overschrijvingen en incasso’s. Het grote verschil tussen EURO1 en TARGET1 is dat door middel van het eerste systeem commerciële bankgelden op dagbasis worden afgewikkeld, terwijl laatstgenoemde de settlement van nationale centralebankgelden op real-time basis verzorgt. De kosten per transactie zijn bij verwerking via EURO1 lager dan via TARGET1, terwijl de lidmaatschapskosten hoger zijn.

De Europese banken hebben hard gewerkt aan de implementatie van een gezamenlijk betaalsysteem voor betalingen tussen financiële instellingen, TARGET2 genoemd. TARGET2 vervangt de huidige infrastructuur door een enkelvoudig technisch platform (Single Shared Platform). Binnen TARGET2 wordt een universele prijsstructuur voor nationale en grensoverschrijdende betalingen gehanteerd. TARGET2 is vanaf 19 november 2007 gefaseerd ingevoerd. Nederland is op 18 februari 2008 op TARGET2 overgegaan. Met de komst van TARGET2 wordt er geen onderscheid meer gemaakt tussen nationaal en grensoverschrijdend betalingsverkeer. De relatie tussen rekeninghouders en centrale banken blijft echter nationaal en wordt niet gecentraliseerd.

De vervanging van het TOP-systeem door het centrale TARGET2-platform heeft tot gevolg dat de systemen van banken die nu aanleveren aan en/of afnemen van TOP, zijn aangepast (inclusief interfaces). Het grote voordeel van TARGET2 is dat er nu voor alle banken een uniforme interface naar het TARGET2-platform is ontstaan. Daardoor kunnen (internationale) netwerkbanken groeien naar één Europees payment center.

Wat is SEPA?

Op 28 januari 2008 is Single Euro Payments Area (SEPA) ingevoerd. Dit moet uiteindelijk leiden tot een geïntegreerde Europese markt voor betalingsverkeer in euro. Bedrijven en consumenten kunnen nu in heel Europa betalingen in euro verrichten en ontvangen, op een even veilige en efficiënte manier als voor 28 januari reeds het geval was met binnenlandse betalingen. SEPA bestaat uit: één munteenheid, één set van betalingsinstrumenten (zoals Europese overschrijvingen, Europese domiciliëringen en kaartbetalingen), efficiënte verwerkingsinfrastructuur voor eurobetalingen, universele technische standaarden, universele bedrijfsvoering, een geharmoniseerde juridische basis, en continue ontwikkeling van nieuwe, klantgerichte diensten ([ECB06]). De bestaande inrichting van betalingsverkeer is gefragmenteerd en werd bepaald door lokale behoefte, gebruiken, standaarden, etc. De standaardisering van de verwerking van betalingsverkeer zou tot efficiency en een verbeterde marktwerking moeten leiden ([CEC05]).

SEPA is niet alleen van toepassing op grensoverschrijdend betalingsverkeer. Binnen SEPA worden alle retailbetalingen in euro’s binnen de eurozone als nationaal gezien. Dit impliceert dat elke eurobetaling van en naar rekeningen binnen één van de landen in de eurozone een SEPA-betaling is ([ECB06]). Iedere bank dient per 28 januari 2008 de SEPA-producten te kunnen verwerken door middel van de nieuwe verwerkingsstandaarden. Vanaf 28 januari 2008 functioneren bestaande producten en SEPA-betaalproducten naast elkaar; de ECB streeft ernaar dat eind 2010 de kritische massa van transacties naar SEPA-producten is gemigreerd ([ECB06]). De komende jaren zal een overgangstermijn zijn waarin Europese producten worden geïntroduceerd en Nederlandse overschrijvingen, betaalkaarten en automatische incasso’s worden uitgefaseerd. Exacte einddata zijn niet bekend; ieder product wordt individueel gemigreerd ([NVB07]). De landen die betrokken zijn bij SEPA, zijn de EU-lidstaten, plus Zwitserland, IJsland, Liechtenstein en Noorwegen.

SEPA bestaat uit twee delen: 1. een Europees wettelijk kader om alle euro- en niet-eurobetalingen gelijk te stellen, en 2. specifieke (technische) standaarden en richtlijnen ten behoeve van de realisatie van pan-Europees betalingsverkeer.

Het wettelijk kader is opgesteld door de Europese Commissie. De Europese Commissie heeft de Payment Services Directive (PSD) gecreëerd die voor de opheffing van de wettelijke barrières moet zorgen. De huidige Europese markt van betalingsverkeer is nationaal ingericht. De PSD dient op 1 november 2009 in nationale wetgeving te zijn verankerd. Eén van de doelstellingen van deze richtlijn is het efficiënt inrichten van betalingsverkeer. Niet-zichtbare kruissubsidies dienen te worden vermeden en kosten van betaalmiddelen dienen zichtbaar te worden gemaakt in de prijs. Hierdoor wordt de gebruiker gestimuleerd te kiezen voor efficiënte betaalmiddelen, waardoor een kostenbesparing kan worden bereikt. Tevens wordt door de richtlijn de regelgeving voor Europese concurrentie geharmoniseerd en wordt informatievoorziening aan de gebruiker vergroot.

De standaarden en richtlijnen zijn door de European Payment Council (EPC) geformuleerd. De EPC, als de vertegenwoordiger van de gehele Europese banksector, zorgt voor een ondersteunend technisch kader bij de realisatie van SEPA. De EPC houdt zich bezig met het ontwikkelen van interbancaire standaarden en afspraken over pan-Europese betaalinstrumenten gericht op SEPA. De EPC heeft een aantal interbancaire standaarden (‘schemes’ of ‘rulebooks’) ontwikkeld ten behoeve van automatische verwerking van alle eurobetalingen ([ECB06]). Een SEPA-scheme biedt een set van regels, best practices en standaarden voor het interbancair verwerken van een SEPA-betaling, zoals dit is overeengekomen tussen de diverse Europese banken. Binnen SEPA worden drie betalingsinstrumenten onderkend: credit transfer (overschrijvingen), direct debit (automatische incasso) en cards (debit- en creditkaartbetalingen). Voor ieder betalingsinstrument is één scheme opgesteld, dat vervolgens door alle banken en aanbieders van infrastructuur wordt gehanteerd ([EPC05a]). In dit scheme worden de voorwaarden gecreëerd voor interoperabiliteit tussen banken en tussenpartijen binnen één transactiestroom.

Wat zijn de gevolgen voor banken?

Voor de Nederlandse bancaire sector heeft SEPA aanzienlijke gevolgen. Nederland behoort op het gebied van betalingsverkeer tot de koplopers van Europa; de nationale betaalproducten zijn betrouwbaar en efficiënt. Ook op het gebied van governance van het betalingsverkeer loopt Nederland voorop; het Nederlandse marktmodel voor het collectieve betalingsverkeer bevordert marktwerking en markttransparantie. Hierdoor is een gelijkwaardig speelveld voor de verschillende partijen in de betaalketen ontstaan ([Curr06]). De voordelen van SEPA voor een land met een efficiënte betaalinfrastructuur zullen daardoor waarschijnlijk pas op langere termijn zichtbaar zijn.

De uiteindelijke gevolgen van SEPA voor een bank worden bepaald door de strategische doelstellingen van de betreffende bank. Welke producten biedt een bank aan haar klanten aan en welke wil de bank in de toekomst aanbieden? Ook de kosten van de verschillende producten en processen dienen in ogenschouw te worden genomen.

In deze paragraaf worden de gevolgen van SEPA voor de Nederlandse banken toegelicht. Een onderscheid zal worden gemaakt tussen strategische en operationele gevolgen.

Strategische impact

De totstandkoming van de markt voor betalingsverkeer binnen SEPA wordt beïnvloed door diverse partijen en mogelijkheden. Door de implementatie van SEPA zal het Europese betalingsverkeer op de huidige Nederlandse betaalpiramide gaan lijken (zie figuur 1). Een verschil hierbij is de aanwezigheid van meerdere Automated Clearing Houses (ACH’s) en de mogelijkheden voor bilaterale verwerking tussen banken. Voor ACH’s biedt SEPA de mogelijkheid om op Europees niveau diensten aan te bieden, waardoor schaalvoordelen kunnen worden behaald. Het is niet te verwachten dat er meerdere lokale ACH’s blijven bestaan. Er zullen naar verwachting enkele grote bulkverwerkende ACH’s ontstaan, naast een aantal nichespelers ([EPC05b]). Indien een ACH namelijk schaalvoordelen kan bereiken door het verwerken van grote volumes betalingsopdrachten, kan deze ACH met lagere tarieven concurreren.

Naast de huidige SEPA-producten bestaat de mogelijkheid tot het leveren van additionele diensten. Deze diensten, die extra functionaliteiten bieden ten opzichte van de huidige SEPA-schemes, zijn vooral gericht op de klanten van banken. E-invoicing, online- en mobile-payments zijn enkele voorbeelden hiervan. De EPC is van mening dat deze diensten niet nationaal georiënteerd mogen zijn, aangezien zij dan in strijd zijn met het doel van SEPA (één uniforme betaalmarkt). Daarom is een aantal criteria gedefinieerd waaraan deze producten dienen te voldoen: niet tegenstrijdig met de SEPA-schemes, volledige transparantie binnen de bankenindustrie, en ontwikkeld op basis van marktbehoefte.

Uit ons onderzoek is gebleken dat grotere banken al in vroeg stadium zijn begonnen met de voorbereiding en implementatie van SEPA. Duidelijk is dat grootbanken de introductie van SEPA als kans zien om hun strategie en operatie op het gebied van payments opnieuw onder de loep te nemen. Gezien de kosten die gepaard gaan met de implementatie van SEPA en het op grote schaal faciliteren van betalingsverkeer, zijn nieuwe samenwerkingsvormen opportuun. Het is de verwachting dat in de markt een consolidatie zal optreden als gevolg van partnerships en in- en outsourcing. Een nauwlettende afweging van diverse factoren zoals winstgevendheid, omvang en businessstrategie is daarbij bepalend voor de meest ideale constructie. Grootbanken zijn daarom voornamelijk gericht op de kansen die SEPA kan bieden en maken daarbij gebruik van scenarioanalyses om te komen tot een keuze van het meest aantrekkelijke alternatief. In de volgende paragraaf wordt dieper ingegaan op de mogelijke samenwerkingsvormen.

Aan de andere kant is gebleken dat kleine banken vooral een afwachtende en conservatieve houding hadden ten aanzien van SEPA en veelal blijven vasthouden aan huidige betaalproducten.

Operationele impact banken

SEPA vormde de aanleiding voor een structurele verandering van de processen en ondersteunende IT-systemen binnen Nederlandse banken. Een belangrijk onderdeel van SEPA is een Europese clearing- en settlementinfrastructuur. Tot op heden had de infrastructuur voor clearing en settlement van retailbetalingen zich op een nationaal niveau ontwikkeld. In SEPA zijn de mogelijkheden voor concurrentie tussen clearing & settlement-partijen vergroot. Deze partijen kunnen concurreren om services met toegevoegde waarde te leveren, tegen verschillende prijsmodellen en serviceniveaus ([EPC05a]).

De bankindustrie heeft de voorkeur uitgesproken voor het ontwikkelen van een Pan Europees Automated Clearing House (PEACH) met eerlijke en open toegang voor alle betrokken partijen. Banken zijn echter vrij om één of meer Clearing and Settlement Mechanisms (CSM’s) te kiezen voor het afhandelen van de SEPA-transacties ([NVB07]). Transacties mogen ook bilateraal worden verwerkt tussen banken onderling. Wel dienen banken bereikbaar te zijn voor het ontvangen van betalingsbestanden van iedere andere bank in de SEPA-zone door middel van PEACH-compliant ACH als directe of indirecte deelnemer ([EBA07]). Voor het versturen van betalingsbestanden zijn zij dus vrij om eigen kanalen en clearing & settlement-partijen te kiezen.

Het gebruik van een ACH is gelimiteerd aan de volgende twee alternatieven:

  • Pan-European ACH compliant ACH: een ACH die in staat is clearing en settlement voor SEPA-betalingen te verrichten binnen het gehele SEPA-gebied.
  • SEPA-scheme compliant ACH: een CSM die in staat is SEPA-betalingen te verwerken binnen een gedefinieerde markt (CSM’s mogen ervoor kiezen om alleen of in combinatie met andere CSM’s een PEACH te vormen) ([EBA07]).

Om als SEPA-compliant te kunnen worden aangemerkt, zijn specifieke criteria gedefinieerd. Het gaat voor dit artikel te ver om op deze criteria in te gaan. Wel is het van belang dat banken hun interfaces moeten aanpassen om berichtenverkeer met een CSM mogelijk te maken.

Het is de verwachting dat een netwerk van infrastructuren zal ontstaan, waarbinnen het mogelijk is voor individuele aanbieders van infrastructurele diensten om volledige bereikbaarheid te kunnen waarborgen. Eerlijke en open toegang tot iedere willekeurige infrastructuur moet zijn gegarandeerd, waarbinnen alle deelnemers afgeschermd zijn van de risico’s die kunnen ontstaan door deelname van andere partijen ([EBA07]).

Er is op dit moment één systeem dat voldoet aan de technische eisen en doelstellingen van PEACH. Dit is het STEP2-systeem van de Euro Banking Association (EBA). De EBA is een samenwerkingsverband van Europese banken en Europese vestigingen van niet-Europese kredietinstellingen. Binnen Nederland hebben ABN AMRO, ING, Rabobank en DNB een lidmaatschap bij EBA; DNB is hierbij user member. Echter, banken kunnen zich ook aansluiten bij een alternatief netwerk van CSM’s en op deze wijze volledige dekking bereiken.

Nationale betaalproducten kunnen vanaf 28 januari een concurrerende Europese variant naast zich treffen. Daarnaast zullen een aantal Nederlandse producten verdwijnen. De SEPA-producten (overschrijving, incasso, betaalpas) dekken 92 procent van alle niet-chartale betalingen van Nederlandse rekeninghouders af ([NVB07]). Dit impliceert dat banken in de komende jaren zowel Nederlandse als Europese betaalproducten en -diensten blijven aanbieden aan hun klanten. Dit kan tot additionele kosten en investeringen leiden. Voor de Europese betaalproducten zijn wijzigingen in de huidige systemen en processen vereist. Belangrijke wijzigingen zijn:

  • Internationale overschrijvingen dienen met dezelfde snelheid te worden verwerkt als nationale overschrijvingen. Om dit te kunnen bereiken is een Europese standaard afgesproken voor het uitwisselen van berichtenverkeer tussen banken onderling. De nieuwe standaard is SEPA XML, oftewel XML ISO 20022.
  • Tevens zijn de huidige (Nederlandse) rekeningnummers vervangen door IBAN-nummers. IBAN staat voor International Bank Account Number en dient als identifier voor alle rekeningnummers binnen Europa. Het binnenlandse BBAN is afgeschaft.
  • Ook de BIC (Bank Identifier Code) wordt verplicht op overschrijvingen en incasso’s vermeld, zowel bij nationale als internationale betalingen. Banken dienden dus tijdig een inventarisatie te hebben gemaakt van de benodigde IBAN’s en BIC’s om te voorkomen dat betalingen niet (tijdig) worden uitgevoerd. Ook de technologie is aangepast. IBAN’s kunnen in lengte variëren; de Nederlandse IBAN heeft achttien tekens, dit is echter niet in andere landen het geval. Systemen dienden te worden ingesteld op deze variabele lengte. Ook controleslagen ter verificatie van het rekeningnummer zijn ingebouwd. Daarnaast zijn door de EPC criteria gesteld voor IBAN/BIC-databases, waardoor banken conversies kunnen maken van de nationale routingstandaarden naar de BIC’s.
  • Voor cliënt-bankverkeer en bank-cliëntverkeer is nog geen definitieve standaard afgesproken, de XML-standaard is aanbevolen. Binnen de huidige Nederlandse standaarden kunnen IBAN en BIC niet worden gebruikt; daarom dienen deze vervangen te worden. Er is echter nog geen overeenstemming bereikt op Europees niveau over de definitieve invulling en criteria. De huidige Nederlandse standaard (CtoB/BtoC) levert diverse managementinformatie op over geweigerde en ingetrokken incasso’s en overschrijvingen, gestorneerde incasso’s, verwerkte acceptgiro’s en namen en adressen van begunstigden. Er is binnen de EPC nog geen standaard ontwikkeld voor deze rapportagefunctionaliteit ([NVB07]).
  • De invoering van Europese incasso’s zal in 2009 plaatsvinden. Allereerst moet de wetgeving omtrent automatische incasso’s definitief worden gemaakt. Juridische aspecten dienen nog te worden uitgewerkt, evenals de mogelijkheden van het migreren van bestaande contracten naar SEPA-incasso. Ook veiligheid en geschillenafhandeling zijn nog openstaande punten ([NVB07]).
  • Voor cards zijn er nog geen definitieve data bekend; wel is vastgesteld dat de infrastructuur voor cardbetalingen naar de EMV-standaard wordt gemigreerd. Echter, voor cards is nog geen scheme opgesteld, alleen een framework. Dit dient nog verder te worden uitgewerkt ([NVB07]).
  • De infrastructuur voor cardbetalingen dient te worden aangepast naar de Europese standaard. Hierdoor moeten alle kaarten een Europees bereik krijgen. Passen en terminals worden daarom aangepast. Een voorbeeld hiervan is de nieuwe card met chiptechnologie, in plaats van de huidige magneetstrip.
  • De Nederlandse acceptgiro zal verdwijnen en geleidelijk worden vervangen door bestaande of nieuwe SEPA-producten.

De volledige (technische) uitwerking van de SEPA-producten is uitgeschreven in de schemes, de implementatierichtlijnen en het SEPA-datamodel. Hierin staan onder andere de procesgang, de dataformats en de maximale verwerkingstijdlijnen voor betalingen.

Een aandachtspunt bij bovengenoemde standaarden is het feit dat de EPC zich tot dusver alleen gericht heeft op standaarden voor het interbancaire betalingsverkeer. Voor het cliënt-bankverkeer en bank-cliëntverkeer zijn nog geen uniforme standaarden vastgesteld. De EPC is van mening dat dit berichtenverkeer behoort tot het concurrentiedomein van banken. Een minimumniveau van standaardisatie is echter vereist om een soepele acceptatie van SEPA-producten door eindgebruikers mogelijk te maken.

Een ander aandachtspunt is beveiliging van betalingen, vooral op het gebied van internetbankieren, creditcardbetalingen via internet en e-payments. Tot op heden is geen specifieke regelgeving omtrent beveiliging opgesteld. De EPC is van mening dat ook dit tot de verantwoordelijkheid van de individuele banken behoort. Gezien het belang van de financiële en reputatierisico’s die voortvloeien uit deze vormen van betalingen, rijst de behoefte aan nadere regelgeving op Europees niveau ([EBA07]).

Aanpak en scenario’s

De eerste stap in het complianceproces was een inventarisatie van de omvang van het huidige betalingsverkeer, waarbij aandacht is besteed aan het aantal transacties (binnen Nederland en binnen de eurozone), de spreiding van deze transacties (per land en per ontvangende bank) en de kosten en opbrengsten per betaalproduct (zowel nationaal als binnen de eurozone). Na het in kaart brengen van de huidige betalingsstructuur hebben banken hun ambities bepaald voor het ‘SEPA-tijdperk’. Op basis van haar kerncompetenties en strategische doelstellingen heeft een bank een keuze gemaakt tussen een aantal scenario’s. De verschillende mogelijkheden zijn weergegeven in figuur 2.

Banken zijn vrij om één of meer Clearing and Settlement Mechanisms te kiezen voor het afhandelen van de SEPA-transacties. Factoren die deze keuzen kunnen beïnvloeden, zijn het transactievolume, de prijs, de kwaliteit en de functionaliteit van een CSM ([NVB07]).

C-2008-1-Houwelingen-2

Figuur 2. Scenario’s grensoverschrijdend betalingsverkeer SEPA.

Zoals in figuur 2 te zien is, zijn er verschillende mogelijkheden voor een bank om grensoverschrijdende transacties te verwerken.

Veel landen binnen de eurozone hebben ieder een eigen Automated Clearing House. Het staat banken vrij om een ACH te kiezen in één van de deelnemende landen. Indien de buitenlandse betalingen van een bank vooral naar één specifiek land worden overgemaakt, is het gebruikmaken van de diensten van een ACH in dat land een goede optie. Er kunnen met deze ACH specifieke afspraken worden gemaakt omtrent tarifering en het format voor het aanleveren van de berichten. Betalingsopdrachten kunnen in dit geval ook via TARGET2 worden verstuurd. Afhandeling via TARGET2 heeft de grootste zekerheid, maar is relatief duur: 0,80 euro per transactie. Voor banken die veel buitenlandse betalingen versturen is TARGET2 dan ook een dure optie. In Nederland is Equens de enige CSM. Veel banken laten hun SEPA-betalingsverkeer via Equens lopen. Equens kan dit betalingsverkeer via een andere CSM of via het STEP2-netwerk van EBA laten verlopen. Voor het huidige betalingsverkeer maken de banken al gebruik van de dienstverlening van Equens. Het voordeel voor kleinere banken is hierbij dat er relatief weinig wijzigingen hoeven te worden aangebracht in systemen en interfaces. Uit ons onderzoek blijkt dat veel banken de voorkeur hebben gegeven aan dit scenario.

Een andere mogelijkheid voor een bank om eurobetalingen naar een andere Europese bank te versturen is direct via het STEP2-systeem van EBA. Er zijn echter verschillende criteria opgesteld waar een directe deelnemer aan moet voldoen. De eerste voorwaarde is dat de bank een (hoofd)kantoor moet hebben in één van de landen van de Europese Unie, daarnaast gelden er voorwaarden met betrekking tot de omvang en gezondheid van de bank (balanstotaal, liquide middelen, credit rating). Niet alle banken voldoen aan deze criteria, waardoor de keuze voor directe deelname niet voor alle banken een optie is. Daarnaast zijn er relatief hoge lidmaatschapskosten verbonden aan deelname aan EBA, de kosten per transactie zijn daarentegen relatief laag. Tevens dienden de bestaande betalingssystemen te worden aangepast aan de vereisten van EBA. Dit vergde aanvullende investeringen. Het voordeel dat deelname aan EBA biedt, zijn de lagere kosten per transactie en volledige reachability. Vooral voor banken met veel grensoverschrijdende betalingen is EBA een goede optie; door de lage transactiekosten kunnen schaalvoordelen worden behaald.

Indien een bank niet voldoet aan de criteria voor directe deelnemer aan het EBA STEP2-systeem, bestaat de mogelijkheid om indirecte deelnemer te worden. Hierbij kiest de bank een agent-bank voor het ontvangen van eurobetalingen vanuit andere landen. Dit zogenoemde entry point dient een directe deelnemer te zijn en moet zich in hetzelfde land bevinden ([EBA04]). Indien een bank een relatief laag volume buitenlandse betalingen heeft, is het voor haar voordeliger om indirecte deelnemer te worden. Wel dient de bank met de agent-bank afspraken te maken omtrent aanlevering van betalingsopdrachten (berichtenformat, systeemtechnische vereisten) en de tarieven hiervoor.

Indien een bank eigen vestigingen in meerdere landen in de eurozone heeft, kan deze bank de buitenlandse betalingsopdrachten ook naar een eigen vestiging in dat betreffende land versturen. Deze vestiging verwerkt deze opdrachten vervolgens via het door die bank gekozen scenario. Dit is een goede optie voor een bank die zelf weinig betalingsopdrachten verstuurt. Als deze bank de opdrachten verstuurt naar een vestiging met veel betalingsopdrachten, kunnen daar kostenvoordelen worden behaald.

Zoals uit de beschreven scenario’s blijkt, zijn er diverse opties mogelijk voor banken om SEPA-betalingen te versturen en te ontvangen. Echter, niet voor iedere bank is elk scenario even geschikt. Dit is afhankelijk van verschillende factoren, zoals weergegeven in figuur 3.

C-2008-1-Houwelingen-3

Figuur 3. Factoren bepalend voor het SEPA-scenario.

De keuze voor een bepaald scenario is afhankelijk van de omvang van het huidige buitenlandse eurobetalingsverkeer. Kleine banken zullen hun strategie aanpassen en zich richten op hun kerncompetenties. De overige dienstverlening (waaronder verwerken van SEPA-betalingen) kan worden uitbesteed aan gespecialiseerde aanbieders, zoals een grootbank of clearing house.

Grootbanken zijn in staat de volledige betalingscyclus voor alle SEPA-producten aan te bieden. Voor grootbanken is het verwerken van betalingen een onderdeel van de primaire dienstverlening. Hierdoor is het strategisch belang dermate groot dat zij dit proces niet kunnen uitbesteden. Het is voor deze banken cruciaal om een zo groot mogelijk aantal transacties te verwerken, zodat zij op basis hiervan kostenvoordelen kunnen behalen. Om dit te realiseren is insourcen een relevante optie.

Het belangrijkste onderscheid kan worden gemaakt in banken met veel of weinig betalingsopdrachten. Voor banken met veel betalingsopdrachten is het scenario EBA – directe deelnemer interessant; door de grote hoeveelheden betalingsopdrachten kunnen kostenvoordelen behaald worden en kunnen de lidmaatschapskosten worden terugverdiend. Ook kunnen deze banken ervoor kiezen om betalingsopdrachten voor kleinere banken te gaan verwerken en zo gaan fungeren als entry point. Hierdoor kan de bank haar diensten uitbreiden en haar strategische positie versterken.

Voor banken met weinig betalingsopdrachten wegen de kosten van dit scenario niet op tegen de opbrengsten. Dit kan het geval zijn voor een kleinere bank die zich vooral richt op beheer van effectenportefeuilles en waarbij het aanbieden van betalingsproducten vooral aanvullende dienstverlening is (commodity) en niet de corebusiness. Voor deze banken zijn de alternatieven Equens of een Europese ACH een betere optie.

Wat is de relevantie voor de IT-auditor?

Vanuit maatschappelijk belang is het cruciaal dat de kwaliteitsaspecten integriteit, vertrouwelijkheid en beschikbaarheid zijn gewaarborgd binnen het betalingsverkeer. Daarnaast steunt het betalingsverkeer in grote mate op IT-systemen. Onder invloed van een aantal trends en nieuwe ontwikkelingen, waaronder SEPA, voelt het management zich steeds meer genoodzaakt een IT-auditor in te schakelen om kritisch naar de betaal- en afwikkelingsinfrastructuur te kijken. IT-auditors zullen kaders scheppen of randvoorwaarden stellen om te bevorderen dat betaal- en afwikkelsystemen die van belang zijn voor het ongestoord functioneren van de financiële structuur, voldoen aan de kwaliteitsaspecten integriteit, vertrouwelijkheid en beschikbaarheid. SEPA vormt aanleiding voor een structurele verandering van de processen en ondersteunende IT-systemen binnen Nederlandse banken. Daarbij is het van belang om de genoemde kwaliteitsaspecten niet uit het oog te verliezen. Het object van onderzoek (en van de IT-auditor) zijn de IT-systemen en betalingsprocessen benodigd voor de afwikkeling van betalingsopdrachten van de Nederlandse banken binnen de eurozone.

Een kritiekpunt vanuit het eurosysteem op de huidige status van de voorbereiding op SEPA, is dat er relatief weinig aandacht is gegeven aan de beveiliging rondom betalingsverkeer, vooral op het gebied van internetbankieren en betalingen op internet door middel van creditcards. De EPC heeft zich tot nu toe vooral gericht op beveiliging tussen banken onderling en niet op end-to-end beveiliging van een betaaltransactie. Gezien het financieel en reputatierisico dat een bank loopt bij een eventueel beveiligingsincident, is het van groot belang voldoende aandacht te besteden aan de beveiliging rondom de volledige keten van betalingsverkeer ([EBA07]).

Door de komst van SEPA hebben banken keuzen gemaakt voor het verwerken van betalingen (in-/outsourcen van betaaldiensten). Hierdoor kunnen nieuwe afhankelijkheden ontstaan. Een rol hierin spelen de (multi)nationale providers van clearing- en settlementdiensten. De ontwikkeling van nieuwe applicaties, interfaces of platformen voor de verwerking van Europese retailbetalingen schept de behoefte aan een beoordeling over de vertrouwelijkheid, beschikbaarheid en integriteit van een dergelijk netwerk. Hier kan de IT-auditor een rol spelen.

Conclusie

Het uiteindelijke beeld van het betalingsverkeer binnen de eurozone kan nu nog niet worden weergegeven. Dit zal pas na een langere periode blijken. De markt van betalingsverkeer kan in de komende jaren behoorlijk gaan veranderen. Banken kunnen diensten van ACH’s gaan overnemen, of ACH’s kunnen fuseren dan wel zich specialiseren.

Ook de omvang van de voordelen van SEPA is op dit moment nog onbekend. Enkele beoogde effecten van SEPA zijn: snellere verwerking van eurobetalingen, een standaardformat voor betalingsopdrachten en reducering van het aantal benodigde bankrekeningen. Deze effecten moeten tot kostenvoordelen voor zowel banken als klanten van banken leiden. Tevens biedt SEPA mogelijkheden tot ontwikkeling van één pan-Europees shared service center voor het verwerken van betalingen. De mate waarin deze beoogde voordelen tot realisatie zullen worden gebracht, is afhankelijk van de uiteindelijke vorming van de betaalmarkt en de mate van acceptatie van SEPA-producten.

Pas na 2010 zal een totaalbeeld van de impact van SEPA kunnen worden gegeven. Dan zal worden gestart met het uitfaseren van nationale producten en zullen de onderlinge verhoudingen tussen de verschillende spelers in de markt van betalingsverkeer duidelijk zijn.

Literatuur

[Capg06] Capgemini and ABN Amro, World Payments report 2006.

[CEC05] Commission of European Communities, Directive of the European Parliament and of the Council on payment services in the internal market, Brussel, 1 December 2005.

[Curr06] Currence, De nationale betaalproducten en SEPA, samenvatting inleiding Ada van der Veer, MKB-congres 19 mei 2006.

[EBA04] EBA Clearing, STEP 2 – Pan-European Bulk Payment Processing System. Functional Overview, Final 3v0 of 24 November 2004.

[EBA07] EBA, Banks preparing for SEPA, versie 2.2, 25 mei 2007.

[ECB06] ECB, The Single Euro Payments Area (SEPA: an integrated retail payments market), 2006.

[EPC05a] EPC, Framework for the evolution of the clearing and settlement of payments in SEPA – including the principles for SEPA ‘scheme’ compliance and re-statement of the PEACH model, version 0.9, 8 November 2005.

[EPC05b] EPC, Impact Paper towards ‘PEACH’. Enclosure to letter No 0143.

[NVB07] NVB, DNB en Currence, De overgang op SEPA, juni 2007.

SOx en ORM: twee verschillende werelden?

In veel banken zijn SOx en Basel II vanuit een eigen raamwerk geïmplementeerd, terwijl beide, elk vanuit een eigen invalshoek, het management verantwoordelijk stellen voor procesbeheersing. Dit artikel geeft aan in hoeverre de activiteiten die benodigd zijn voor SOx en operationeel risicomanagement (ORM) (voortkomend uit de ‘sound practices’ voor ORM van de Bank for International Settlements [BIS03]) elkaar overlappen en reikt mogelijkheden aan om deze activiteiten te integreren.

Inleiding

Een belangrijke bevinding uit een onderzoek van KPMG LLP naar de ontwikkelingen in ‘SOx-compliancy’ in 2007 ([KPMG07]) was dat het integreren van ‘enterprise risk management’ met de risicoassessmentactiviteiten voor SOx als één van de top vijf strategische issues wordt aangemerkt. Een integratie van SOx met het ORM-framework zou hieraan kunnen bijdragen. Zowel de SOx-regelgeving als het Basel II-Akkoord bevat eisen voor risicomanagement van banken. De scope van zowel ORM (als onderdeel van Basel II) als SOx betreft in principe een gehele bank en bovendien zijn de activiteiten van beide gericht op procesbeheersing.

In de praktijk zien wij dat er bij de implementatie van ORM beperkt gekeken wordt naar de mate waarin Basel II-initiatieven kunnen aansluiten bij de reeds geïmplementeerde SOx-elementen.

Dit artikel geeft een overzicht van de mate waarin SOx en ORM elkaar overlappen. Hiertoe is gekeken naar business planning en scoping, governance, het controlsraamwerk en de mogelijke (ondersteunende) IT-tooling. Het doel van het artikel is aan te geven waar efficiencyvoordelen kunnen worden behaald door inspanningen voor beide regelgevingen te combineren.

ORM-kader

Operationeel risico is één van de risicocategorieën die in het Basel II-Akkoord ([BIS06]) van de Bank for International Settlements (BIS) wordt onderkend. In Nederland is het Basel II-Akkoord van kracht sinds januari 2007 en is dit verankerd in de Wft (Wet financieel toezicht). Afhankelijk van de aanpak wat betreft operationeel risicomanagement geeft het Basel II-Akkoord meer of minder stringente kwalitatieve en kwantitatieve eisen en richtlijnen voor ORM. De voornaamste kwalitatieve eisen zijn beschreven in de ‘Sound practices for operational risk management’ ([BIS03]). Een raamwerk dat aan deze ‘sound practices’ en de overige Basel II-eisen invulling geeft, is weergegeven in figuur 1.

C-2008-1-Degens-1

Figuur 1. ORM-raamwerk.

De driehoek in het ORM-raamwerk geeft aan welke bouwstenen aanwezig moeten zijn om ORM in een organisatie in te bedden:

  • risicostrategie: de strategie die de basis is voor alle andere componenten en dient aan te geven wat wel en niet als risico wordt geaccepteerd;
  • organisatiestructuur: de rollen en verantwoordelijkheden;
  • rapportage: de gewenste managementinformatie en benodigde externe rapportage;
  • definities en structuren: de taxonomie en structuur voor de elementen van ORM;
  • loss data: (het proces voor het verzamelen en analyseren van) data van operationele verliezen;
  • risicoanalyse: een kwalitatieve analyse van de bestaande risico’s binnen de organisatie (met behulp van zogenoemde risico (en control) selfassessments);
  • key risk indicators: ‘early warning’-signalen die een verhoogde kans op het optreden van een verlies signaleren;
  • mitigeren: maatregelen om bestaande, ongewenste risico’s te mitigeren;
  • kapitaalberekening: berekening van het benodigde kapitaal om operationele risico’s te kunnen opvangen;
  • informatietechnologie: IT-systemen die ORM-activiteiten ondersteunen.

De cyclus rond deze elementen geeft aan dat ORM geen statisch, maar een continu proces is. Het inbedden van deze cyclus in de bedrijfsprocessen is een belangrijke maatstaf voor het slagen van ORM in een organisatie.

SOx-kader

De Sarbanes Oxley Act (SOx) is in 2004 in werking getreden en is van toepassing op alle aan de New York Stock Exchange genoteerde bedrijven. Sinds 2006 dienen ook niet-US-bedrijven aan de vereisten voortkomende uit deze Act te voldoen ([SOx07]).

SOx heeft een groot aantal consequenties voor bedrijven, waarvan de belangrijkste zijn vastgelegd in secties 302 en 404. Sectie 302 schrijft voor dat management verantwoordelijk is voor het vaststellen en onderhouden van ‘internal control’. Het ontwerp van een dergelijk ‘internal control framework’ dient een redelijke mate van zekerheid te verschaffen omtrent de betrouwbaarheid van de externe financiële verslaggeving.

In sectie 404 is vastgelegd dat de CEO en CFO een verklaring dienen af te geven waarin het topmanagement verklaart verantwoordelijk te zijn voor het creëren en vaststellen van een adequaat framework van internal controls. In deze verklaring dient tevens een beschrijving van dit framework te zijn opgenomen. Indien één of meer ‘material weaknesses’ in dit raamwerk zijn gedetecteerd, dan mag het topmanagement niet verklaren dat de internal controls effectief zijn.

Tevens dient een verklaring van de externe accountant te worden opgenomen in het jaarverslag omtrent de effectiviteit van het internal control framework.

Business planning en scope

Operationeel risicomanagement is erop gericht het risico op operationele verliezen als gevolg van inadequaat of foutief menselijk handelen, van tekortkomingen in interne processen of systemen of van externe gebeurtenissen te verkleinen tot het niveau dat de bank (en de toezichthouder) als acceptabel beschouwt. Verliezen worden gegenereerd door incidenten. Deze incidenten zijn door de BIS en DNB in zeven categorieën ingedeeld (zie tabel 1).

C-2008-1-Degens-t1

Tabel 1. Categorieën incidenten. [Klik hier voor grotere afbeelding]

Incidenten die leiden tot deze operationele verliezen zijn onder andere interne en externe fraude. SOx is primair gericht op het voorkomen van deze fraude en ‘safeguarding of assets’. Door het implementeren van sterke internal controls dient fraude te worden gedetecteerd en voorkomen, om zo materiële ‘misstatements’ in de financiële verslaggeving te voorkomen. Standard No. 5 ([PCAO07]), die de voormalige Auditing Standard No. 2 sinds mei 2007 vervangt, legt bovendien extra nadruk op frauderisico en ‘anti-fraud controls’. De overige incidentencategorieën zijn niet van specifiek belang vanuit SOx-oogpunt, mits deze verliezen correct financieel worden verantwoord. SOx beperkt zich immers tot de beheersing van processen, vanuit het oogpunt van correcte financiële verslaggeving. Dit betekent dat de processen, risico’s en controls die betrekking hebben op de juistheid, tijdigheid en volledigheid van de financiële rapportage, binnen de SOx-scope vallen. Om de precieze scope te bepalen wordt gebruikgemaakt van het materialiteitsprincipe. Alleen de processen van die organisatieonderdelen die een materiële bijdrage leveren aan de geconsolideerde cijfers van de bank, vallen hierbinnen. Het zijn immers ook deze processen die bij falende internal control kunnen leiden tot een ‘material misstatement’. Omdat het niet voldoen aan SOx kan leiden tot additionele kosten (verliezen) en reputatieschade (een ‘niet financieel (ORM) verlies’), vallen SOx en de hiermee samenhangende controls binnen de scope van ORM.

Ook ORM heeft betrekking op alle processen en onderdelen van een organisatie. In elk proces kunnen immers als gevolg van fouten in systemen, processen, menselijk handelen of als gevolg van externe omstandigheden, verliezen optreden.[Vanuit Basel II vindt er ook scoping plaats. Hierdoor kunnen processen van organisatieonderdelen die niet binnen de scope van Basel II vallen, ook buiten de scope van ORM vallen. De toezichthouder kan om argumenten vragen waarmee wordt aangetoond dat het ‘outscopen’ van deze activiteiten geen onjuiste weergave van het risicoprofiel van de organisatie tot gevolg heeft.] De focus van ORM wordt in eerste instantie bepaald door de risicostrategie van het management. In tegenstelling tot SOx, waarin wordt voorgeschreven dat geen material misstatements mogen voorkomen, mag er vanuit Basel II een bepaalde mate van operational risk (OR) bestaan. Een organisatie hoeft en kan niet honderd procent in control zijn zolang het (operationele) risicoprofiel in overeenstemming is met de ‘risk appetite’ en ambitie van de bank en er voldoende kapitaal wordt aangehouden om de verwachte en onverwachte operationele verliezen op te kunnen vangen. Deze link tussen operationeel risico en kapitaal is een significant verschil tussen de SOx- en Basel II-vereisten; ORM, als één van de risicogebieden binnen het Basel II-Akkoord, bepaalt mede de hoogte van het kapitaalsbeslag vanuit solvabiliteitsoogpunt. Naast kwalitatieve eisen die vergeleken kunnen worden met de SOx-vereisten, worden er daarom ook kwantitatieve eisen aan ORM gesteld. In de meest geavanceerde benadering voor ORM bestaat er een directe link tussen het (operationele) risicoprofiel van een bank en de hoogte van het aan te houden kapitaal voor ORM. Deze link tussen risicoprofiel en kapitaal is een ‘incentive’ voor het management om een optimale balans te vinden tussen ‘risk’ en ‘reward’ en zo ‘return on capital’ te maximaliseren. In de praktijk vindt hiertoe allocatie van OR-kapitaal plaats naar organisatieonderdelen. Voor SOx wordt alleen de impact van niet-werkende controls gekwantificeerd om zo te kunnen bepalen in hoeverre er sprake is van een material misstatement. In tabel 2 wordt een overzicht van de scope en doelstellingen van ORM en SOx gegeven.

C-2008-1-Degens-t2

Tabel 2. Scope en doelstellingen ORM en SOx. [Klik hier voor grotere afbeelding]

Governance

SOx stelt het bestuur van een bedrijf (CEO en CFO) hoofdelijk aansprakelijk voor het inrichten van een internal control framework en het afleggen van een verklaring omtrent de werking van dit framework. Indien deze verklaring onjuist blijkt te zijn en er materiële misstatements in de jaarrekening voorkomen, dan zijn geldelijke boetes en een maximale gevangenisstraf van twintig jaar de consequentie.

In de ‘sound practices’ voor ORM ([BIS03]) wordt ook het bestuur van een bank verantwoordelijk gesteld voor de implementatie van een ORM-raamwerk. Er is geen sprake van een hoofdelijke aansprakelijkheid, noch dient dit vastgelegd te worden in een verklaring. Net zoals bij SOx is de lijnorganisatie verantwoordelijk voor een juiste implementatie van ORM. Lijnmanagement is verantwoordelijk voor de identificatie van operationele risico’s en de implementatie van adequate maatregelen om deze te mitigeren in lijn met de ‘risk appetite’ van de bank. Daarnaast wordt in de ‘sound practices’ voorgeschreven dat ‘Internal Audit’ een rol dient te spelen in de inhoudelijke toetsing van het ORM-raamwerk. Een verdeling van verantwoordelijkheden zoals die in de praktijk wordt toegepast, is belichaamd in het zogenaamde ‘three lines of defence’-model, zoals weergegeven in figuur 2.

C-2008-1-Degens-2

Figuur 2. Three lines of defence.

Voor ORM en SOx dienen taken en verantwoordelijkheden te worden belegd op het niveau waar de risico’s bestaan en de ‘controls’ worden uitgevoerd.

In de praktijk wordt het management in zijn activiteiten ondersteund door afdelingen die gespecialiseerd zijn in ORM of SOx. Operational risk managers ondersteunen het management in de identificatie, monitoring en evaluatie van operationele risico’s. Daarnaast zien wij dat Internal Audit het management vaak ondersteunt bij de test- en documentatieactiviteiten voor SOx. Bij verschillende banken is dit echter ook bij de ORM-functie belegd.

Toezicht

Het toezicht op SOx-compliancy wordt uitgevoerd door de externe auditor. Deze diende onder PCAOB Auditing Standard No. 2 twee SOx-verklaringen af te geven; één betreffende management assessment en een verklaring gebaseerd op eigen testwerk. Met de introductie van Auditing Standard No. 5 in mei 2007 is de eerste vereiste verdwenen; de auditor dient alleen een eigen verklaring af te geven. De PCAOB voert toezicht uit op de wijze waarop de externe accountant de testwerkzaamheden verricht en tot een oordeel is gekomen.

De externe auditor zal bij ORM focussen op de juistheid van de kapitaalberekeningen en hiertoe de eventueel gebruikte modellen valideren. In hoeverre er voldoende adequate maatregelen getroffen zijn om de operationele risico’s te mitigeren, is voor de externe auditor niet van belang, zolang de geleden operationele verliezen juist tot uitdrukking komen in de jaarrekening. De input hiervoor komt voort uit het geïmplementeerde ORM-raamwerk, maar dit raamwerk zelf is in principe geen onderdeel van de externe audit. Het toezicht op de implementatie van een ORM-raamwerk wordt in Nederland gevoerd door DNB. In tabel 3 worden de verschillende verantwoordelijkheden binnen ORM en SOx samengevat weergegeven.

C-2008-1-Degens-t3

Tabel 3. Verantwoordelijkheden ORM en SOx. [Klik hier voor grotere afbeelding]

Controlsraamwerk

De verklaring die het management aflegt voor SOx dient ondersteund te worden door de resultaten van testwerk, waarmee is aangetoond dat de benodigde controls effectief zijn. Dit testwerk plus de daarbij behorende documentatie van de resultaten is niet expliciet voorgeschreven voor ORM; door gebruik te maken van risk (and control) selfassessments, het gebruik van key risk indicators en een loss database verkrijgt het management inzicht in het bestaande risicoprofiel en kan zo identificeren of actie is gewenst.

Documentatie van deze activiteiten is gewenst om interne en externe belanghebbenden op de hoogte te kunnen stellen van de kwaliteit van ORM, maar er bestaat een grote mate van subjectiviteit, die bij SOx niet bestaat.

SOx beveelt het COSO-framework (opgesteld door het Committee of Sponsoring Organisations of the Treadway Commission) aan als geschikt internal control framework. Controls kunnen worden ingedeeld conform de vijf onderdelen van dit raamwerk: monitoring, information & communication, risk assessment, control activities en control environment. Het COSO-raamwerk heeft weinig verankering in de ORM-wereld. Operationele risico’s en controls worden in het algemeen niet conform COSO geclassificeerd. De ORM-controls worden ingedeeld op basis van de oorzaak (processen, mensen, systemen of externe omstandigheden) van het onderliggende risico en de gebeurtenis (zie tabel 1) die zij (proberen te) mitigeren (in figuur 3 zijn de componenten van een operationeel risico weergegeven).

C-2008-1-Degens-3

Figuur 3. De definitie van operationele risico’s.

In 2005 is een nieuwe versie van het COSO-raamwerk uitgegeven, het ‘Enterprise Risk Management Framework’ (zie figuur 4) ([COSO05]). Dit raamwerk heeft meerdere lagen, waarbij meer aandacht wordt besteed aan risk assessment en de afstemming tussen de doelen van een organisatie en het daarbij behorende risicoprofiel. Deze aanpak en de aandacht voor de effectiviteit en efficiency van de bedrijfsvoering sluiten goed aan bij de opzet en doelstellingen van ORM. Het raamwerk koppelt de (risk management) strategie van een organisatie met de bestaande risico’s en controls van de bank en neemt tevens externe factoren (events) mee in de bepaling van deze risico’s.

C-2008-1-Degens-4

Figuur 4. Enterprise Risk Management Framework.

Het Basel II-Akkoord stelt geen eisen aan de wijze waarop risico’s en controls dienen te worden gedocumenteerd. Indien er gebruik wordt gemaakt van een loss database, wordt er wel per operationeel verlies een classificatie naar ‘business line’ en ‘event category’ (zie tabel 1) verwacht.

Ook vanuit SOx is het van belang om op een adequate wijze te documenteren. Denk hierbij aan het documenteren van de processen/procedures en daarbinnen de ‘key controls’ en risico’s, de vastlegging van het uitgevoerde testwerk, het vastleggen van informatie over de wijze waarop transacties worden geïnitieerd, goedgekeurd, vastgelegd, verwerkt en gerapporteerd, etc. Om hieraan te voldoen is het aan te bevelen controls volgens een vaste indeling te documenteren. Deze indeling zou ook binnen ORM kunnen worden toegepast als richtlijn voor de ‘controls-documentatie’ (zie tabel 4) om zo de kwaliteit van de risicodocumentatie te verbeteren.

C-2008-1-Degens-t4

Tabel 4. Indeling controlsdocumentatie.

Uit de documentatie moet zowel de opzet en het bestaan (Test Of Design) blijken, als de effectieve werking van een control (Test of Operating Effectiveness). Binnen Basel II wordt dit onderscheid niet gemaakt. Aangezien van het management verwacht wordt dat het de bestaande risico’s mitigeert, zal de focus liggen op het bestaan en de werking van controls.

IT-controls

Veel banken hanteren naast het eerdergenoemde COSO-raamwerk het Cobit-framework (Control Objectives for IT) om specifieke invulling te geven aan de IT-controls binnen de organisatie ([ITGI06]). Dit raamwerk geeft zowel invulling aan de SOx-vereisten als aan de ORM-wensen. ORM-vereisten kunnen rechtstreeks uit SLA’s worden afgeleid. De SLA zou immers het resultaat moeten zijn van een kosten-batenanalyse waarbij de kosten van additionele zekerheid zijn afgewogen tegen de (directe of indirecte) opbrengsten van hogere service levels.

SOx hecht groot belang aan de IT general controls. In een geautomatiseerde omgeving kan immers niet automatisch op application controls worden gesteund, wanneer de IT general controls niet effectief zijn. Deze specifieke aandacht voor IT general controls bestaat niet binnen ORM. Dit betekent echter niet dat er niet eenzelfde afhankelijkheid bestaat van IT general controls en er daarom ook binnen ORM voldoende aandacht aan moet worden besteed.

Een verschil tussen ORM en SOx is dat de beschikbaarheid van systemen bij ORM meer aandacht krijgt dan onder SOx. Vanuit het oogpunt van de juistheid van de financiële verslaglegging is het key dat de gegevens juist, tijdig en volledig worden aangeleverd, maar ten aanzien van de manier waarop – handmatig of geautomatiseerd –, is er geen directe eis. Vanuit efficiency- en effectiviteitsoogpunt zal ORM veel belang hechten aan de beschikbaarheid van systemen.

Voor wat betreft application controls geldt dat hier in beide gevallen aandacht aan wordt besteed, vanwege de mogelijkheid van fouten in deze controls. SOx zal zich hierbij focussen op de application controls die de financiële verslaggeving beïnvloeden en ORM op de controls die de prestaties van de bank mede bepalen. De controls vanuit SOx-oogpunt zullen ook binnen ORM belangrijk worden geacht, aangezien het voorkomen van sancties van de toezichthouder ook onder de ORM-doelstellingen valt.

C-2008-1-Degens-t5

Tabel 5. Raamwerk controls. [Klik hier voor grotere afbeelding]

IT-tooling

Het gebruik van bedrijfsbrede informatiesystemen ten behoeve van de (eenmalige) vastlegging van risico’s en ‘controls’ op verschillende niveaus binnen een bank, ondersteunt in het (zichtbaar) voldoen aan ORM- en SOx-vereisten.

Vanwege de documentatievereiste voor SOx, is het verstandig een zo efficiënt mogelijke wijze van vastlegging te hanteren, waarmee niet alleen de ‘controls’ worden vastgelegd, maar waarmee tevens evaluatie en rapportage van de effectiviteit van de ‘controls’ wordt ondersteund ([Brou03]). Veel organisaties gebruiken een specifieke applicatie voor het vastleggen van hun internecontroleraamwerk, hun testactiviteiten, en de uitkomsten daarvan. Voorbeelden hiervan zijn BWise, Risk Navigator en SAP MIC. Tegelijkertijd zien we dat bedrijven Excel gebruiken voor hun rapportages en de ondersteunende ‘evidence’ hardcopy opslaan. Ditzelfde geldt voor ORM.

Ondanks dat er systemen in de markt bestaan voor de ondersteuning van zowel SOx- als ORM-activiteiten, zijn in de praktijk meestal twee aparte applicaties (en werkwijzen) geïmplementeerd. Tabel 6 geeft weer welke activiteiten door een applicatie kunnen worden ondersteund en in hoeverre de functionaliteit van toepassing is op SOx- of ORM-activiteiten of op beide.

C-2008-1-Degens-t6

Tabel 6. Overlap functionaliteiten. [Klik hier voor grotere afbeelding]

Hoe de overlap te benutten?

Uit het voorgaande blijkt dat, ondanks het feit dat de ‘incentives’ voor SOx en ORM compleet verschillend zijn, de ORM- en SOx-activiteiten en -verantwoordelijkheden voldoende gelijkenis vertonen om te kunnen profiteren van de overlap. Vanwege de beperktere scope van SOx, ten opzichte van ORM, heeft het onze voorkeur om de SOx-activiteiten zo veel mogelijk binnen de ORM-activiteiten te verankeren. Het bepalen, documenteren en testen van SOx-controls kan een plaats krijgen binnen de activiteiten die ORM uitvoert om operationele risico’s te identificeren, analyseren, monitoren en mitigeren. Hierbij dient gegarandeerd te worden dat er geen concessies worden gedaan aan de SOx-vereisten ten aanzien van documentatie en testwerk en dient een ‘risk appetite’ van (nagenoeg) nul te worden gehanteerd voor de SOx-gerelateerde risico’s en controls. Door duidelijk aan te geven welke risico’s en controls voor SOx van belang zijn, hoeven deze niet nogmaals vanuit ORM-oogpunt onder de loep te worden genomen en wordt voorkomen dat de stringente(re) SOx-vereisten op ORM-risico’s en controls worden toegepast. Een IT-tool kan ondersteuning bieden bij het integreren van de activiteiten door eenmalige vastlegging en het duidelijk vastleggen van de doelstelling van gedocumenteerde risico’s en controls (SOx en/of ORM).

Literatuur

[BIS03] Bank of International Settlements, Sound practices for the management and supervision of operational risk, February 2003.

[BIS06] Bank of International Settlements, International Convergence of Capital Measurement and Capital Standards, A Revised Framework Comprehensive Version, June 2006.

[Brou03] P.P.M.G.G. Brouwers RE RA en A.M. Meuldijk, SOx404-implementatie in de praktijk: het proces van ‘trust me’ naar ‘prove me’, Compact 2003/3.

[COSO05] COSO, Enterprise Risk Management Framework, 2005, www.erm.coso.org.

[ITGI06] IT Governance Institute, IT Control Objectives for Sarbanes Oxley, September 2006.

[KPMG07] KPMG, SOx Trends and Results of KPMG SOx Survey, 2007.

[PCAO07] PCAOB, Auditing Standard No. 5, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements and related independence rule and conforming amendments, 2007.

[SOx07] Sarbanes-Oxley. Available from URL: http://www.sarbanes-oxley.com.

SAP-compliance en business improvement

De huidige uitdaging voor veel organisaties is naast het praktisch en efficiënt toepassen van ‘Governance, Risk and Compliance’ ook het verhogen van de efficiëntie en effectiviteit van de bedrijfsprocessen. Is dit mogelijk? Zijn de onderwerpen risico’s en compliance niet strijdig met procesverbetering? In dit artikel wordt ingegaan op de vraag hoe een geïntegreerde visie op het gebied van Governance, Risk and Compliance en ondersteunende tooling kan leiden tot continue zekerheid, lagere compliancekosten en procesverbetering.

C-2008-0-Jonker-0

Een introductie van Ronald Jonker

Inleiding

Het verwezenlijken van de toekomstige doelstellingen ‘focus op verwerken van interne én externe informatie’, ‘exploitatie van informatie leidt tot creëren van business’ en ‘onmisbaarheid van bottom-up informatiestromen’ waren de uitkomsten van het onderzoek van KPMG in de zomer van 2007. Kort samengevat wordt het goed omgaan met informatie steeds crucialer voor het succes van organisaties. Deze ontwikkeling wordt enerzijds gedreven door steeds hogere eisen op het gebied van compliance en het voldoen aan wet- en regelgeving. Anderzijds proberen organisaties op basis van veel investeringen in informatiesystemen processen steeds efficiënter en effectiever te maken. Beide onderwerpen, compliance en procesverbetering, lijken niet hand in hand te gaan. Hoe kan immers compliance leiden tot procesverbetering? In dit artikel wordt ingegaan op de relatie tussen compliance en procesverbetering en hoe een goede beheersing van beide onderwerpen kan leiden tot een beter presterende organisatie.

Allereerst wordt het onderwerp Governance, Risk and Compliance (GRC) nader toegelicht inclusief de verschillende volwassenheidsfasen die organisaties doorlopen. Vervolgens wordt toegelicht welke relatie bestaat tussen GRC en procesverbetering, waarbij tevens concrete voorbeelden worden gegeven hoe GRC-tools hierbij kunnen ondersteunen. Ten slotte wordt aangegeven welke soorten GRC-tools momenteel in de markt bestaan, op welke niveaus deze tools ingezet kunnen worden en hoe deze tools kunnen bijdragen aan een beter bedrijfsresultaat.

Tijdens het KPMG IT Advisory Seminar ‘Trends in IT – Information Governance’ op 1 november 2007 heeft in de workshop ‘SAP compliance & business improvement’ een open discussie plaatsgevonden met organisaties die bezig zijn met deze onderwerpen. In dit artikel wordt tevens ingegaan op de resultaten van deze discussie.

Governance, Risk and Compliance

De aandacht voor risicobeheersing en het voldoen aan wet- en regelgeving is de afgelopen jaren flink toegenomen. Veel geïndustrialiseerde landen hebben als gevolg van financiële deconfitures wetten en regels in het leven geroepen die transparantie, de onafhankelijkheid van de auditor en financieel toezicht op bedrijven en instellingen versterken. De bekendste voorbeelden daarvan in Nederland zijn de code-Tabaksblat en de Amerikaanse Sarbanes-Oxley wet.

Bedrijven die dienen te voldoen aan deze wetten, zien zich voor de vraag gesteld hoe zij het vertrouwen van de aandeelhouders en toezichthouders kunnen vergroten door het instellen van een effectief stelsel van interne controle zonder dat dit ten koste gaat van de operationele slagkracht. Of beter nog, waarbij dit stelsel de bedrijfsvoering positief beïnvloedt.

Vooruitstrevende bedrijven en instellingen benaderen het invoeren van interne controle en het afleggen van verantwoording over de effectiviteit daarvan niet als een op zichzelf staand eenmalig project. Zij zien het verband tussen verschillende Governance, Risk and Compliance (GRC)-activiteiten binnen hun organisatie. Onder GRC wordt hierbij verstaan (zie ook figuur 1):

  • Governance: het geheel van beleid, procedures en maatregelen om een organisatie te kunnen laten functioneren in overeenstemming met haar strategische doelstellingen.
  • Risk management: het geheel van procedures en maatregelen dat zich richt op het systematisch identificeren van risico’s, het nemen van mitigerende maatregelen en het rapporteren over het functioneren van risk management aan de leiding.
  • Compliance: het voldoen aan wet- en regelgeving, dan wel: het geheel van maatregelen en procedures dat er zorg voor draagt dat een organisatie voldoet aan wet- en regelgeving en daarover verantwoording aflegt.

Organisaties met een geïntegreerde GRC-benadering weten de GRC-activiteiten te combineren in een samenhangend geheel van op elkaar afgestemde processen, waarmee zij doublures en inefficiënties weten uit te bannen. Het is duidelijk dat deze organisaties weten te profiteren van de geïntegreerde kracht van GRC en hun Total Cost of Compliance weten te verlagen, wat ze een concurrentievoordeel oplevert ten opzichte van hun ‘peers’.

C-2008-0-Jonker-1

Figuur 1. GRC uitgewerkt (bron: [SAP07]).

Integratie van GRC-activiteiten kan echter niet zonder geautomatiseerde ondersteuning. Zoals later in dit artikel wordt behandeld, zijn er voor de verschillende niveaus van GRC-activiteiten ook verschillende typen GRC-systemen beschikbaar. Het is interessant te zien dat diverse softwareleveranciers nu meer en meer toepassingen op de markt brengen die de verschillende niveaus van GRC-activiteiten ondersteunen. In het bijzonder geldt dit voor SAP, die onlangs haar visie rond GRC ontvouwde en in 2008 verwacht een complete suite van toepassingen voor haar cliënten beschikbaar te hebben ([SAP07]).

Bij het integreren van de GRC-activiteiten doorlopen organisaties in de praktijk vaak vier volwassenheidsniveaus (zie ook figuur 2):

  1. Fragmented: compliance is project-centric; compliance (bijvoorbeeld SOX) wordt in eerste instantie als een centraal project gerund. Dit vereist veel centrale projectcoördinatie om iedereen aangesloten te houden en uniform te laten werken.
  2. Implemented: compliance is program-centric, waarbij een overkoepelend en gestructureerd programma dedicated personen aanwijst om de complianceactiviteiten te coördineren en communiceren.
  3. Embedded: compliance is proces-centric, waarbij compliance in de processen wordt ingebouwd. Compliance wordt ‘business as usual’. Verantwoordelijkheid voor compliance komt bij de business en process owners te liggen.
  4. Enhanced: compliance is culture-centric en framework integrated. Compliance is verder ingebed in de organisatie, waarbij compliance niet een doel op zich is. Meerdere regelgevingen worden geïntegreerd en met de nieuwe werkwijze afgedekt. Daarnaast zal de transparantie ook kunnen leiden tot business process improvement.

C-2008-0-Jonker-2

Figuur 2. GRC-volwassenheidsniveaus.

Organisaties die deelnamen aan de workshop op 1 november gaven aan gemiddeld op het niveau ‘implemented’ te zitten. Tevens werd aangegeven dat het realiseren van de volgende stap van groot belang is om de efficiëntie- en effectiviteitsvoordelen volledig te benutten. Hierbij werden de volgende stappen onderkend:

  1. Opzetten integrale GRC-strategie en GRC-roadmap. Begonnen wordt met het identificeren van alle GRC-vereisten binnen de organisatie en het uitwerken daarvan in een strategie en roadmap.
  2. Controlstransformatie naar IT. Er is de afgelopen jaren veel geïnvesteerd in IT- en SAP-systemen. Compliance dient daar ook gebruik van te maken om een juiste balans te bereiken tussen preventieve IT controls en de vaak detectieve handmatige controles.
  3. Embedding van controls in de organisatie. Uiteindelijk dient compliance ‘business as usual’ te worden. Controls worden vaak al binnen de processen uitgevoerd, maar dienen verder transparant te worden gemaakt en er moet over worden gerapporteerd.
  4. Integreren van verschillende compliance frameworks. Veel verplichtingen voor wet- en regelgeving worden binnen organisaties gezien als ‘koninkrijkjes’ (bijvoorbeeld SOX, FDA, Basel II, ISO, etc.). Organisaties die dit kunnen doorbreken en het eenmalig testen van controls voor meerdere wet- en regelgevingen laten gebruiken, hebben de mogelijkheid om het complianceproces verder efficiënt te maken.

Hoewel werd aangegeven dat GRC inmiddels op de agenda van het management staat, wordt een hogere prioriteit toegekend aan procesverbeteringsinitiatieven. Deze initiatieven staan vaak los van de activiteiten op het gebied van GRC. In de volgende paragraaf wordt aangegeven dat er wel degelijk een relatie bestaat tussen GRC en procesverbetering.

GRC en procesverbetering

Verbetering van procesefficiëntie en -effectiviteit is voor bijna elke organisatie één van de strategische speerpunten. Maar waar begin je? Welke processen presteren momenteel niet goed en welke verbeteracties dienen te worden ingezet? Bovendien worden processen steeds complexer en worden er steeds hogere eisen gesteld aan kwaliteit en betrouwbaarheid enerzijds vanuit de klant en anderzijds vanuit wet- en regelgeving.

De basis voor het verbeteren van efficiëntie, effectiviteit en betrouwbaarheid van processen ligt bij het verkrijgen van inzicht in het huidige proces en de ‘root-causes’ van problemen. Zonder dit inzicht is het niet mogelijk goede verbeteracties te definiëren en te implementeren. Wat veroorzaakt immers de lange doorlooptijd van het verkooptraject of waarom zijn de kosten per inkooporder zo hoog? Waarom is de klanttevredenheid zo laag voor een bepaalde productcategorie?

Om een goed inzicht te krijgen in de processen, is het noodzakelijk dat een organisatie de volgende twee randvoorwaarden heeft ingevuld:

  • definiëren van de belangrijkste prestatie-indicatoren, en
  • geautomatiseerd analyseren van deze prestatie-indicatoren.

Deze randvoorwaarden worden in de volgende subparagrafen behandeld.

Definiëren prestatie-indicatoren

Hoewel veel organisaties inmiddels zogenaamde KPI’s (Key Performance Indicators) hebben opgezet om op strategisch en tactisch niveau de prestaties van de organisatie in de gaten te houden, hebben nog weinig organisaties dezelfde indicatoren op processtapniveau opgezet. Vaak wordt geconstateerd dat processen niet optimaal presteren, maar kan nog onvoldoende concreet worden aangetoond waar dit door wordt veroorzaakt. Door het definiëren van prestatie-indicatoren op processtapniveau kan dit worden voorkomen. Deze indicatoren worden PPI’s (Process Performance Indicators) genoemd. Gedefinieerde PPI’s kunnen namelijk concreet aantonen waar potentiële verbeteringen kunnen worden gerealiseerd.

Om deze stelling verder toe te lichten, wordt als voorbeeld de processtap facturatie binnen het inkoopproces gepakt. Om de performance van deze processtap te bepalen, zouden de volgende PPI’s kunnen worden opgesteld:

  • Percentage inkoopfacturen zonder inkooporder

    Binnenkomende facturen waarvoor een inkooporder en een bericht van goederenontvangst in het systeem aanwezig zijn, kunnen bij geen verschil vaak zonder aanvullende inspanningen worden betaald. Facturen waarvoor geen inkooporder in het systeem aanwezig is, dienen handmatig te worden gecontroleerd en te worden betaald. In dit geval dient de medewerker van de crediteurenadministratie handmatig te verifiëren of de gegevens op de factuur kloppen. Bovendien dient de betaling van deze facturen vaak door meerdere personen handmatig te worden goedgekeurd. Voor het verwerken van deze facturen is zowel de doorlooptijd als benodigde inspanning vele malen hoger dan bij facturen waarvoor reeds een inkooporder en een bericht van goederenontvangst aanwezig zijn.
  • Percentage inkoopfacturen dat geblokkeerd raakt

    Indien veel binnenkomende facturen geblokkeerd raken doordat volgens het systeem de gefactureerde gegevens niet kloppen (zoals prijs en hoeveelheid), dient de medewerker van de crediteurenadministratie handmatig te onderzoeken wat het probleem is. Waarom raakt de factuur geblokkeerd? Wellicht klopt de prijs niet. Of zijn de goederen nog niet ontvangen. Het kan namelijk zijn dat gefactureerde goederen weliswaar zijn ontvangen, maar dat de goederenontvangst nog niet in het systeem was geboekt door de magazijnmedewerker. In ieder geval veroorzaken geblokkeerde inkoopfacturen veel handmatig werk en kunnen zij bovendien leiden tot verlate betalingen aan leveranciers waardoor eventuele kortingen kunnen worden misgelopen.
  • Aantal ontvangen creditnota’s

    Een groot aantal ontvangen creditnota’s leidt tot hoge administratieve verwerkingskosten. Er moeten immers correctieboekingen worden gemaakt en de betreffende verantwoordelijke personen dienen te worden ingelicht. Bovendien zijn de kosten initieel niet juist geregistreerd, waardoor managementrapportages verkeerde informatie kunnen geven (of kostprijzen van eindproducten verkeerd worden berekend).

Dit zijn enkele voorbeelden van PPI’s, die in detail inzicht kunnen geven in de performance van een processtap. Het definiëren van PPI’s geeft dan ook een goede basis voor procesverbetering.

C-2008-0-Jonker-f

Discussie tijdens de SAP compliance & business improvement workshop

Geautomatiseerd analyseren van prestatie-indicatoren

Zoals reeds is toegelicht, ligt de basis voor het verbeteren van efficiëntie, effectiviteit en betrouwbaarheid van processen bij het verkrijgen van inzicht in de performance van processen. Eenmaal gedefinieerde PPI’s zijn waardeloos als niet kan worden gemeten wat de werkelijke situatie is. Bovendien is het wenselijk om de PPI’s continu in de gaten te kunnen blijven houden om steeds op de hoogte te zijn van de performance van een proces.

GRC-tools zijn in staat dit soort PPI’s continu te meten. Zonder GRC-tools dient een organisatie zelf data-extracties uit systemen te gaan opzetten in vaak dure Business Intelligence-oplossingen. Dit kan, met name door de grote hoeveelheid PPI’s, een kostbare oplossing worden en niet opwegen tegen de verwachte voordelen. GRC-tools daarentegen zijn vooral opgezet om analyses te maken op processtapniveau en werken vaak met dezelfde data die nodig zijn om de PPI’s te meten. Rapporteren in dashboards is hierbij aan te bevelen, waardoor eventuele aandachtspunten direct kunnen worden herkend en worden opgevolgd.

Om te kunnen rapporteren in dashboards dienen de gedefinieerde PPI’s in verband te worden gebracht met kwaliteitscriteria en een verwachte norm. De kwaliteitscriteria kunnen worden onderverdeeld in twee gebieden:

  1. Proces: kwaliteitscriteria die samenhangen met de manier waarop de organisatie het proces heeft ingericht. Hieronder vallen drie criteria:
    • procesbetrouwbaarheid: de mate waarin de gegevensverwerking binnen het proces juist, volledig en geoorloofd plaatsvindt;
    • procesefficiëntie: de mate waarin het proces het gewenste prestatieniveau bereikt tegen een zo laag mogelijk kostenniveau (doelmatigheid);
    • proceseffectiviteit: de mate waarin het proces bijdraagt aan de organisatiedoelstellingen en de mate waarin het proces zo snel mogelijk wordt doorlopen.
  2. Systeem: kwaliteitscriteria die samenhangen met de manier waarop de organisatie het systeem heeft ingericht. Hieronder vallen ook drie criteria:
    • autorisaties: de mate waarin de toegekende rechten in het systeem aansluiten met het organisatiemodel en de gewenste functiescheidingen;
    • systeeminstellingen: de mate waarin de geprogrammeerde systeeminstellingen een adequate werking van het proces ondersteunen;
    • gebruik van functionaliteit: de mate waarin de organisatie gebruik heeft gemaakt van de beschikbare functionaliteit die wordt aangeboden door het systeem.

Gedefinieerde PPI’s kunnen worden toegekend aan meerdere kwaliteitscriteria. Zo kan de PPI ‘percentage inkoopfacturen dat geblokkeerd raakt’ worden toegekend aan de criteria procesefficiëntie en proceseffectiviteit. Een hoog percentage geblokkeerde inkoopfacturen veroorzaakt namelijk hoge kosten (veel aanvullende manuren vanwege het moeten uitzoeken en opvolgen van de geblokkeerde facturen) en een vertraging van de processnelheid.

Nadat de gedefinieerde PPI’s zijn toegekend aan één of meer kwaliteitscriteria dient de gewenste norm te worden gedefinieerd. Er zullen namelijk altijd facturen binnenkomen die blokkeren doordat de gefactureerde prijs of hoeveelheid niet klopt. Een teveel aan geblokkeerde facturen veroorzaakt echter een inefficiëntie in het proces. Een organisatie dient te definiëren welk niveau van geblokkeerde facturen acceptabel is. Hierbij moet een goede analyse worden gemaakt van wat de mogelijke baten zijn afgezet tegen de te verwachten implementatie-inspanning om het percentage verder terug te dringen. Een magazijnmedewerker die namelijk de ontvangen goederen alleen op het einde van de week in het systeem boekt, is wellicht eenvoudig te trainen om elke ontvangst nog op dezelfde dag te boeken waardoor veel manuren kunnen worden gewonnen op de financiële administratie. Facturen echter die geblokkeerd raken doordat de leverancier een verkeerde prijs heeft gehanteerd, zijn niet altijd te voorkomen.

In figuur 3 is een voorbeeld opgenomen van de output van een SAP-tool waarbij enkele mogelijke verbetergebieden zijn gescand voor de processtap facturatie binnen het inkoopproces.

C-2008-0-Jonker-3

Figuur 3. Voorbeeld output GRC-tool. [Klik hier voor grotere afbeelding]

Uit de workshop van 1 november kwam naar voren dat organisaties interesse hebben en de toegevoegde waarde hiervan inzien of zelfs momenteel bezig zijn om GRC-tools verder uit te breiden met PPI’s voor procesverbetering. Deze organisaties zijn daarna in staat continu de performance van hun processen te verbeteren, doordat de GRC-tools hen in staat stellen om concreet gesignaleerde aandachtsgebieden direct op te volgen.

GRC-tools: een praktisch overzicht

In de vorige paragraaf is gesproken over het gebruik van GRC-tools voor de ondersteuning bij het verder verbeteren van processen door gebruik van informatie rechtstreeks uit de SAP-systemen (fact-finding). Echter, niet alleen op het SAP-niveau waar de dagelijkse werkzaamheden worden uitgevoerd kunnen GRC-tools ondersteunen en daarmee de effectiviteit en efficiëntie verbeteren. Een GRC-raamwerk moet gedragen worden door de gehele organisatie en heeft daarom invloed op verschillende niveaus van een organisatie. GRC-tools sluiten zich daarbij aan en de GRC-tools die beschikbaar zijn hebben dan ook ieder een focus op één of meer van deze organisatieniveaus (zie figuur 4) ([Brou06]).

C-2008-0-Jonker-4

Figuur 4. Typen GRC-tools binnen de organisatieniveaus.

De kenmerken en mogelijkheden die GRC-tools kunnen bieden op de verschillende niveaus zijn hieronder beschreven.

Strategic risk management (niveau 1)

Op een strategisch niveau wordt risicomanagement toegepast door het management van de organisatie. Risicomanagement en -analyse wordt door GRC-tools ondersteund om strategische risico’s (financiële, veiligheid, operationele, regelgeving, milieu, etc.) te analyseren, bijvoorbeeld door gebruik te maken van de traditionele ballenplaat (zie figuur 5). Daarnaast ondersteunen deze GRC-tools ook het bijhouden van de actielijsten die voortvloeien uit de (strategische) risicoanalyses.

C-2008-0-Jonker-5

Figuur 5. Voorbeeld overzicht van strategische risico’s.

Tactical risk management (niveau 2)

Nadat de (strategische) risicoanalyses zijn uitgevoerd, dienen de proceseigenaren en managers deze risico’s te beheersen door het opstellen van beleid en het treffen van voldoende controles en werkende maatregelen. Teneinde dit te kunnen doen worden procesrisicoanalyses uitgevoerd om een zo compleet mogelijk beeld van alle risico’s in een proces te creëren. Hierin staan procesbeschrijvingen centraal waarin duidelijk de verantwoordelijkheden en controlemaatregelen beschreven worden. Vaak wordt dit verduidelijkt door gebruik te maken van processchema’s (zie figuur 6). Op basis van een risicoanalyse op strategisch niveau en procesinzicht op tactisch niveau kan een organisatie een goede mix bepalen van de benodigde controlemaatregelen. Deze mix aan controlemaatregelen beperkt uiteindelijk het risico van een bepaalde proces(stap).

C-2008-0-Jonker-6

Figuur 6. Voorbeeld processchema.

Om een goede mix van benodigde controlemaatregelen te bepalen in SAP-processen, kan gebruik worden gemaakt van het CARP-model, waarbij de afkorting CARP wordt gevormd door de eerste letter van de vier typen maatregelen:

  • Customising controls

    Hiertoe behoren de maatregelen gerelateerd aan de configuratie en stamdata van een informatiesysteem. Voorbeelden hiervan zijn de three-way-match instellingen, verplichte velden, tolerantiegrenzen en automatische boekingen. Deze bieden een goede preventieve controle maar moeten wel op de juiste manier zijn ingericht om te werken. Deze controls zijn instellingen die opgeslagen zijn in het systeem en dus kan het bestaan (het aan of uit staan van een dergelijke instelling) worden vastgesteld.
  • Authorisation controls

    Dit zijn maatregelen die gerelateerd zijn aan de logische toegangsbeveiliging in SAP. Bijvoorbeeld het beperken van het aantal personen aan wie het is toegestaan om een kritieke financiële transactie (bijvoorbeeld: betalingsrun) uit te voeren, maar ook het beperken van het aantal personen dat een functiescheidingsconflict veroorzaakt (bijvoorbeeld het wijzigen van bankrekeningnummers van leveranciers en het uitvoeren van de betalingsrun). Gegevens gerelateerd aan de inrichting van de logische toegangsbeveiliging van SAP zijn verankerd in de autorisatiestructuur (profielen/rollen) van SAP. Deze gegevens kunnen worden gebruikt voor het maken van analyses ter beoordeling van de inrichting van logische toegangsbeveiliging (naast wie heeft toegang tot een bepaalde transactie, ook wie heeft in een bepaalde periode de toegang tot transacties verschaft).
  • Reporting controls

    Als onderdeel van de beheersing van een proces door middel van controlemaatregelen, werken gebruikers met controle- en uitzonderingsrapportages die door het systeem worden gegenereerd. Voorbeelden hiervan zijn het periodiek bekijken van veranderingen in bankgegevens – zoals rekeningnummers – van leveranciers, het tijdig opvolgen van de openstaande facturenwerkvoorraad of facturen verstuurd maar nog niet verwerkt in het grootboek. De gebruiker interpreteert het rapport en kan indien nodig de uitzonderingen rapporteren en opvolgen.
  • Procedural of manual controls

    Dit zijn alle maatregelen die een handmatig karakter hebben en een vangnet vormen indien niet de juiste maatregelen binnen customising, authorisation of reporting controls gekozen kunnen worden. Daarnaast zullen ook bij een geautomatiseerde controle nog enkele handmatige vervolgacties uitgevoerd dienen te worden indien er uitzonderingen zijn.

Operational risk management (niveau 3 en 4)

De procesbeschrijvingen die op een tactisch niveau worden gemaakt om risico’s te onderkennen, ingegeven door een risicoanalyse op strategisch niveau, hebben een dagelijkse uitwerking op het operationele niveau. Op dit niveau worden de controles en maatregelen feitelijk uitgevoerd en onderhouden. GRC-tools op dit niveau ondersteunen bij de documentatie van controles, de registratie van de uitvoer daarvan en de registratie van de opvolging van uitzonderingen. Dit wordt veelal gedaan om verantwoording af te kunnen leggen. De controles worden uitgevoerd en de resultaten daarvan worden ingegeven in een dergelijke GRC-tool. Hierdoor kunnen opvolgingsacties worden getraceerd en kan snel een indruk worden verkregen van de status van een controle, ook wel monitoren genoemd.

C-2008-0-Jonker-7

Figuur 7. Voorbeeld controlstatus-rapportage.

Om te kunnen beoordelen of een proces beheerst wordt, dient te worden gekeken naar de werking van de gedefinieerde controlemaatregelen, ervan uitgaande dat de opgezette controlemaatregelen (opzet en bestaan) in een organisatie afdoende zijn om de risico’s af te dekken. Het vaststellen en documenteren van de werking van controlemaatregelen kan met geautomatiseerde fact-finding worden gestaafd. Met inzet van GRC-tooling kan door middel van data-mining[Met data-mining wordt bedoeld het vergaren van informatie uit een informatiebron (meestal een database) en deze informatie gebruiken voor het creëren van meta-informatie (informatie over informatie).] technieken deze fact-finding of bewijsvoering worden gegenereerd. Tevens kan GRC-tooling op dit niveau worden gebruikt om inzicht te krijgen in de performance van processen en concreet aan te tonen waar mogelijke procesverbetering kan worden doorgevoerd.

Het gebruik van GRC-tools kan dus ondersteunen op verschillende niveaus binnen een organisatie. GRC-tools op het strategisch en tactisch niveau zijn niet altijd noodzakelijk. Echter, hoe lager het niveau des te dichter op de operatie (en derhalve grotere benodigde inzet van mensen) waarbij het uitvoeren van controlemaatregelen daadwerkelijk veel tijd in beslag kan nemen, en daardoor des te hogere kosten en dus een grotere rol voor GRC-tooling om deze kosten te reduceren. Daarnaast kunnen gegevens over de effectieve werking van individuele controles (op het operationele niveau) geaggregeerd worden en daarmee een indicatie geven van de totale effectieve beheersing van een proces (tactisch niveau).

Ook de organisaties die waren vertegenwoordigd in de workshop op 1 november gebruiken momenteel GRC-tools op diverse niveaus voor het definiëren van risico’s, het beschrijven van processen, het monitoren van key controls en het ondersteunen bij procesverbetering. GRC-tooling werd hierbij als absolute noodzaak gezien om tot een effectieve en efficiënte invulling van GRC te komen. Hierbij werd tevens aangegeven dat het hebben van een integrale visie op het gebied van GRC-tooling van groot belang is om GRC en procesoptimalisatie in de toekomst daadwerkelijk in te bedden in de organisatie.

Conclusie

Het in de inleiding aangehaalde KPMG-onderzoek laat zien dat organisaties informatie willen gebruiken om verder succesvol te zijn. Deze informatie dient wel betrouwbaar te zijn. Het op een effectieve en efficiënte manier inrichten van Governance, Risk and Compliance is hiervoor noodzakelijk. Het gepresenteerde GRC-groeimodel geeft over een aantal fasen weer hoe organisaties de transparantie van compliance uiteindelijk kunnen gebruiken om procesverbeteringen te identificeren en door te voeren. Het gebruik van GRC-tooling wordt gezien als noodzakelijke ondersteuning om tot een optimaal volwassenheidsniveau te komen.

Tijdens de workshop ‘SAP compliance & business improvement’ op 1 november werd het hebben van een integrale visie op GRC en tooling gezien als eerste stap om de hoge compliance effort van de afgelopen jaren daadwerkelijk om te zetten in sustainable added value.

Literatuur

[Brou06] Drs. P.P.M.G.G. Brouwers RE RA, drs. M.A.P. op het Veld RE en drs. A. Lissone, Tool based monitoring en auditing van ERP-systemen, van hebbeding naar noodzaak, Compact 2006/2.

[SAP07] SAP, SAP Solutions for Governance, Risk and Compliance, 2007, http://www.sap.com/grc/

Het ICT-netwerk. Waar ligt de grens?

In dit artikel schetsen de auteurs vanuit historisch perspectief een zorgbarende ontwikkeling. Het blijkt steeds lastiger te worden om de grens van het ICT-netwerk van een organisatie te bepalen, laat staan om die afdoende te beschermen. Moeten we blijven volharden om de grens van het ICT-netwerk van een organisatie te beschermen of is dat een verloren strijd? Moeten we terug naar de basis: het beschermen van gegevens onafhankelijk van plaats en tijd zodanig dat we ons over de grens van het ICT-netwerk geen zorgen meer hoeven te maken? Volgens de auteurs is een fundamentele verandering in de benadering van informatiebeveiliging gewenst. Zij schetsen in welke richting die benadering kan worden gezocht.

Inleiding

Dat informatiebeveiliging van vitaal belang voor het functioneren van organisaties is behoeft heden ten dage geen betoog. Er wordt op grote schaal gewerkt aan het beschermen van de informatie van een organisatie tegen toegang door onbevoegden. Een belangrijk element daarin is het beveiligen van de ‘buitengrens’ van het ICT-netwerk van de organisatie. Wie mag toegang krijgen tot het netwerk, de applicaties en de gegevens? Het blijkt echter steeds lastiger te worden om die buitengrens te bepalen, laat staan om die afdoende te beschermen.

De grens van het ICT-netwerk van een organisatie wordt in schema’s vaak aangegeven door het tekenen van een cirkel die het interne netwerk voorstelt (de zogenaamde netwerkperimeter). Daaraan zit een firewall vast (vaak weergegeven in de vorm van een stevige muur) die de kwetsbare interne systemen dient te beschermen tegen de buitenwereld (vaak weergegeven in de vorm van een wolkje). Zie figuur 1. Op zulke tekeningen lijkt het ICT-netwerk een onneembare vesting die de kwetsbare systemen voldoende bescherming biedt. Over de jaren heen is dit helaas steeds vaker een droom geworden die niet meer overeenkomt met de werkelijkheid.

In dit artikel willen de auteurs laten zien hoe we tot de huidige situatie zijn gekomen en zodoende tonen welke ontwikkeling we aan het doormaken zijn. Vanuit dit historisch perspectief wordt aangegeven hoe een volgend stadium eruit kan zien. De auteurs beogen niet om een pasklaar antwoord aan te reiken. Veeleer is het doel van dit artikel om u van de ontwikkeling bewust te maken en aan het denken te zetten.

C-2007-2-Zanten-01

Figuur 1. Eenvoudige weergave netwerkperimeter.

Vijf stadia in de ontwikkeling

Onderstaande vijf subparagrafen schetsen de ontwikkeling van het begin van het computertijdperk (1) via terminalverbindingen (2) naar lokale netwerken (3) en de moderne tijd bestaande uit een complex geheel van verbindingen (4). De laatste subparagraaf schetst de beweging die op dit moment wordt doorgemaakt: een onoverzichtelijk samenstel van verbindingen via een toenemend aantal verschillende communicatiekanalen (5).

Om de ontwikkeling eenvoudig en herkenbaar te beschrijven zijn de situaties simpeler weergegeven dan ze in werkelijkheid moeten zijn. Maar door juist alleen de aandacht te vestigen op het netwerk vanuit het fysieke perspectief wordt de achterliggende problematiek – het bepalen van de grens van het ICT-netwerk – duidelijker.

Tijdperk 1 – De centrale computerzaal

C-2007-2-Zanten-02

Figuur 2. De centrale computerzaal.

C-2007-2-Zanten-t1

Tabel 1. Kenmerken centrale computerzaal.

In het begin van het computertijdperk was het zeer eenvoudig de grens van het ICT-netwerk te bepalen: er was slechts één ruimte waarin de computer zelf met alle randapparatuur was geplaatst. De grens van het ICT-netwerk was in die tijd gelijk aan de buitenmuur van de computerzaal. Om toegang te verkrijgen tot de centrale computer diende men eerst toegang te verkrijgen tot de ruimte waarin het apparaat was geplaatst. Door deze afscherming en het ontbreken van verbindingen met systemen buiten de computerruimte was het in dit tijdperk eenvoudig de grens van het ICT-netwerk te controleren. We konden volstaan met een controle op de fysieke beveiliging.

C-2007-2-Zanten-03

Figuur 3. Centrale computer zonder verbindingen.

Tijdperk 2 – Terminals aangesloten op centrale computer

C-2007-2-Zanten-04

Figuur 4. Terminals aangesloten op centrale computer.

C-2007-2-Zanten-t2

Tabel 2. Kenmerken terminals.

Het gebruik van de centrale computer nam sterk toe. Hierdoor ontstond al vrij snel de wens om vanaf meerdere plekken in het gebouw toegang te kunnen krijgen tot deze voorzieningen zonder eerst fysiek toegang te moeten verkrijgen tot de ruimte waarin de centrale computer was geplaatst. Om hieraan invulling te geven verschenen er terminals (ten behoeve van de communicatie met de centrale computer) die buiten de centrale computerzaal werden geplaatst. Tussen deze terminals en de centrale computer lopen vaste verbindingen (kabels).

In dit stadium bestond informatiebeveiliging uit een combinatie van het (fysiek) beveiligen van de toegang tot de centrale computerzaal en de bekabeling. Maar ook ontstond de noodzaak om de gebruiker van een terminal te identificeren. Gebruikersnamen en wachtwoorden voor het verkrijgen van toegang tot de (centrale) verwerkingscapaciteit deden hun intrede.

C-2007-2-Zanten-05

Figuur 5. Directe verbinding tussen centrale computer en terminal (buiten de kamer).

Tijdperk 3 – Lokale netwerken

C-2007-2-Zanten-06

Figuur 6. Patchkast: verbindingen met netwerken op meerdere locaties.

C-2007-2-Zanten-t3

Tabel 3. Kenmerken lokale netwerken.

De technologische vooruitgang maakte het vervolgens mogelijk ook andere soorten apparaten dan terminals te koppelen aan de verbindingen met de centrale computer. Ook verscheen de personal computer op het toneel, die een eigen verwerkingsfaciliteit bood. In dit stadium werd de centrale computer ook steeds minder centraal door het ontstaan van ‘eilandjes’ van computervoorzieningen. Ook nam het aantal verbindingen aanzienlijk toe.

De beveiligingsmaatregelen waren echter nog voor een groot deel fysiek. Hardware en bekabeling vormden nog steeds het belangrijkste aandachtspunt. Echter, langzamerhand werden we ons bewust van het feit dat gebruikers op hun ‘eigen’ computer ook gegevens konden verwerken. De toegang tot die verwerkingscapaciteit had een sterkere afscherming nodig. De pc’s en individuele applicaties kregen eigen afscherming in de vorm van gebruikersnamen en wachtwoorden.

C-2007-2-Zanten-07

Figuur 7. Netwerken op meerdere locaties.

Tijdperk 4 – Huidig tijdperk

C-2007-2-Zanten-08

Figuur 8. Toegang tot het netwerk onafhankelijk van tijd en/of plaats.

C-2007-2-Zanten-t4

Tabel 4. Kenmerken huidig tijdperk.

Kenmerkend voor dit stadium is het grote aantal verbindingen tussen een grote verscheidenheid aan apparaten. Gebruikers kunnen bijvoorbeeld vanaf een willekeurige plek en op een willekeurig tijdstip verbindingen opzetten met de door hen gewenste informatiesystemen. Toegang tot het ICT-netwerk van de organisatie vanaf computers die niet meer eigendom zijn van de eigen organisatie (zoals privécomputers of computers in publieke internetcafés) wordt wenselijk. In het kader van werken op een willekeurige plek en een willekeurig tijdstip wordt in deze fase steeds vaker gebruikgemaakt van krachtige mobiele apparatuur, zoals PDA’s, Tablet pc’s en smartphones, die worden gekoppeld aan bedrijfsnetwerken. Dergelijke apparatuur voorziet veelal in een veelheid aan verbindingsmogelijkheden zoals Wi-Fi, Bluetooth, infrarood, UMTS/GPRS, USB-aansluitingen en ingebouwde slots voor geheugenkaarten (zoals die bijvoorbeeld ook fototoestellen worden gebruikt).

Vanwege dit grote aantal verbindingskanalen en ‘randapparatuur’ is het beveiligen van de buitengrens van het netwerk uiterst complex zo niet ondoenlijk geworden. Bedrijven beginnen zich te realiseren dat ze de grens van het ICT-netwerk niet meer adequaat kunnen bepalen, laat staan beschermen. De ontwikkeling van nieuwe technologieën en verbindingsmogelijkheden blijft ondertussen onverminderd doorgaan.

C-2007-2-Zanten-09

Figuur 9. Veelvoud aan bekende en/of onbekende verbindingen.

Tijdperk 5 – Nabije toekomst

Het is op basis van ontwikkelingen die op dit moment plaatsvinden te verwachten dat in de nabije toekomst het ICT-netwerk van een organisatie uit een steeds groter aantal bekende (en onbekende), permanente en tijdelijke verbindingen bestaat. Daarbij komt dat het aantal punten in het netwerk waarop een gebruiker toegang kan krijgen tot de achterliggende systemen sterk toeneemt. Opzet en ondeskundigheid van gebruikers kunnen er bovendien toe leiden dat ook ongewenste toegangspunten ontstaan. Denk daarbij aan wireless- en Bluetooth-verbindingen. De organisatie krijgt zo steeds minder grip op die verbinding doordat het in toenemende mate de gebruiker is die bepaalt met welke apparatuur en via welk communicatiekanaal een verbinding tot stand wordt gebracht.

Organisaties overwegen daarnaast meer en meer om het internet, zoals dat nu al vaak wordt ingezet voor verbindingen tussen kantoorlocaties (denk daarbij aan VPN- en MPLS-oplossingen), ook te gebruiken als netwerkvoorziening binnen kantoorlocaties. Hierdoor is het eigenlijk niet meer nodig (noch mogelijk) de beschikking te hebben over een ‘eigen’ netwerk. Zie figuur 10.

We zien dan ook dat organisaties in toenemende mate ertoe overgaan de authenticatiemaatregelen te versterken (bijvoorbeeld door inzet van two-factor authenticatie) en scherper toe te zien op de autorisaties die gebruikers zijn toegekend. De focus verschuift van het beveiligen van het netwerk naar het beveiligen van de communicatie zelf.

C-2007-2-Zanten-10

Figuur 10. Geen eigen netwerk meer.

C-2007-2-Zanten-t5

Tabel 5. Kenmerken nabije toekomst.

De werkelijkheid is nog complexer

Om een adequate beveiliging van de informatievoorziening te waarborgen dient men een diversiteit van beveiligingsmaatregelen te implementeren in de lagen die gezamenlijk de informatievoorziening vormen (bijvoorbeeld op het niveau van applicatie, besturingssysteem en ICT-netwerk). In het kader van dit artikel is de focus gelegd op de ICT-netwerklaag. Voor mogelijke maatregelen in de applicatie- en besturingssysteemlagen wordt verwezen naar overige relevante literatuur.

Om een adequate beveiliging van de ICT-netwerklaag te waarborgen dient men te voorkomen dat ongeautoriseerde personen (of apparaten) toegang verkrijgen tot het ICT-netwerk. Een belangrijk aspect daarbij is de grens van het ICT-netwerk die bepaalt waar het eigenaarschap (of de controle) van het ICT-netwerk overgaat van partij A naar partij B. De organisatie zal op die grens moeten nagaan of de communicatie met de systemen in het netwerk al dan niet moet worden toegestaan. Zonder het bepalen van die grens is het waarschijnlijk dat diverse netwerkverbindingen en/of ICT-componenten niet worden meegenomen in de beveiliging van de informatievoorziening en zodoende de beveiliging van het geheel in gevaar brengen. De beveiliging is immers net zo sterk als de zwakste schakel in het geheel van beveiligingsmaatregelen.

Het bepalen van de grens van het ICT-netwerk wordt echter steeds complexer. Een voorbeeld hiervan zijn zakelijke laptops die steeds vaker vanaf de fabriek al zijn voorzien van Wi-Fi- en Bluetooth-functionaliteit. Aangezien gebruikers van de ICT-voorzieningen van een organisatie ook privé vaak over de nodige computerervaring beschikken, zullen de gemakken van dergelijke voorzieningen gebruikers er al snel toe verleiden om die voorzieningen te benutten.

Maar als het bepalen van die grens van het ICT-netwerk steeds lastiger zo niet onmogelijk wordt? Hoe zit het dan met de beveiliging van de informatievoorziening? Kunnen we wel doorgaan met het proberen de grens van het ICT-netwerk van de organisatie te bewaken? Of is het een verloren wedstrijd omdat we keer op keer worden ingehaald door nieuwe technologieën die nieuwe (onbekende) verbindingsmogelijkheden en manieren van werken mogelijk maken?

In de beschrijving van de historische ontwikkeling hebben we gezien dat er in de loop der jaren steeds meer ‘gaten’ zijn gemaakt in de muur rondom het kasteel. De fysieke beveiliging, de dikke muur zelf, is al lang niet meer voldoende om het geheel van de informatievoorziening te beveiligen. De analogie met stedenbouw en de focus op fysieke beveiliging van het ICT-netwerk hebben ons geholpen een beeld te krijgen van de historische ontwikkeling. De werkelijkheid is uiteraard complexer doordat men daar te maken krijgt met een combinatie van fysieke, logische en virtuele aspecten. Aspecten die allemaal bijdragen aan het steeds lastiger (of zelfs niet) kunnen bepalen van de grens van het ICT-netwerk. Een paar voorbeelden:

  • Het ICT-landschap bevat tegenwoordig in toenemende mate (virtuele) componenten die niet langer aan een individuele toepassing, gebruiker of de eigen organisatie zijn toe te schrijven, zoals virtuele netwerken (VPN), virtuele harddisks (iSCSI) en bijvoorbeeld virtuele netwerkinterfaces.
  • In toenemende mate wordt privécomputerapparatuur gekoppeld aan het ICT-netwerk van de organisatie. Sommige organisaties streven er vanuit kostenbesparing ook naar om de inzet van dergelijke privécomputers te bevorderen. Denk aan het vervangen van een laptop ‘van de zaak’ door het toegang geven vanaf de pc thuis. Andere voorbeelden zijn mp3-spelers zoals ipod’s, moderne gsm’s, smartphones, externe harddisks en geheugenkaarten. De beveiliging van die nieuwe componenten is door de organisatie zelf niet meer te doen. De gebruiker krijgt een groeiende eigen verantwoordelijkheid. Helaas zien we dit terug in de vorm van berichten in de media over het openbaar worden van vertrouwelijke informatie door verlies of diefstal van handzame gegevensdragers zoals USB-sticks.

Kunnen we doorgaan met de huidige benadering van ‘grensbewaking’ of is het tijd voor een fundamentele verandering in de benadering van informatiebeveiliging?

Mogelijke oplossingsrichtingen

In de volgende subparagrafen zijn drie mogelijke oplossingsrichtingen beschreven.

De eerste oplossingsrichting betreft een situatie die we al kennen vanuit historisch perspectief, namelijk het verleggen van de grens van het ICT-netwerk. Bij wijzigingen, nieuwe technologieën en/of toepassingen proberen we de grens van het ICT-netwerk opnieuw adequaat te bepalen om die grens vervolgens adequaat te beveiligen.

De tweede oplossingsrichting beschrijft een situatie waarin we alleen de kern van de informatievoorziening beschermen door goed te kijken naar de binnenkomende en uitgaande verbindingen. Wat daarbuiten plaatsvindt, heeft niet onze aandacht. De bedoeling is de omgeving eenvoudiger te maken zodat de grens van het ICT-netwerk beter bepaald kan worden. In de analogie met de stedenbouw is dit scenario vergelijkbaar met het zich terugtrekken in het kasteel waarbij het verkeer over de slotgrachtbrug nauwkeurig wordt bewaakt.

De derde oplossingsrichting is erop gebaseerd dat een fundamentele verandering in de benadering van informatiebeveiliging nodig is, namelijk het beveiligen van de informatie zelf in plaats van het beveiligen van de infrastructuur die voor de verwerking van die informatie wordt gebruikt.

Oplossingsrichting 1 – Vergroten van de grens van het ICT-netwerk

Deze oplossingsrichting bouwt voort op de historische ontwikkeling. Immers, de afgelopen jaren hebben we continu geprobeerd de grens van het ICT-netwerk adequaat te bepalen en te beveiligen. In heel veel gevallen is het gelukkig mogelijk gebleken de grens van het ICT-netwerk succesvol opnieuw te bepalen en te beveiligen. Echter, zoals toegelicht bij de tijdperken 4 en 5, wordt het tegenwoordig door de hoeveelheid bekende en/of onbekende verbindingen steeds lastiger om die grens te bepalen en adequaat te beveiligen.

Naarmate de grens van het ICT-netwerk complexer wordt leidt dit dan ook tot diverse uitdagingen:

  • Bij deze oplossingsrichting loopt men telkens weer het risico te worden ingehaald door technologische veranderingen. Nieuwe hardware, software en bijbehorende toepassingen zorgen vaak voor een veelvoud aan nieuwe potentiële ‘gaten’ in de grens van het ICT-netwerk.
  • De kosten van het controleren van de grens rijzen de pan uit. Immers, als we die controle goed willen inrichten zullen we alle, maar dan ook alle mogelijke toegangspaden tot het ICT-netwerk regelmatig aan controle moeten onderwerpen. Gelet op de grote diversiteit en vluchtigheid van die toegangspaden blijkt dat in de praktijk een omvangrijk geheel van werkzaamheden die een steeds grotere mate van deskundigheid vereisen.
  • In toenemende mate zullen organisaties moeten aantonen ‘in control’ te zijn. Zijn alle transacties door daartoe bevoegden uitgevoerd? Daarbij is het uiteraard van primair belang dat zeker is dat alleen bevoegden toegang tot de ICT-infrastructuur hebben. Door het complexe ICT-landschap bestaande uit bekende maar ook onbekende (ad hoc) verbindingen heeft men veelal geen compleet zicht op het ICT-landschap en de toegangspaden zodat het gevoel groeit dat men niet ‘in control’ is.

C-2007-2-Zanten-t6

Tabel 6. Quick wins en uitdagingen oplossingsrichting 1.

Oplossingsrichting 2 – Terugtrekken in het kasteel

Oplossingsrichting 2 laat, in tegenstelling tot oplossingsrichting 1, het beveiligen van een groot gedeelte van de grens van het ICT-netwerk achterwege. In dit scenario is het uitgangspunt dat we het grote geheel niet meer kunnen beschermen. Daarom probeert men een betere controle over de grens van het ICT-netwerk te verkrijgen door die grens te leggen bij de kernsystemen en vervolgens alleen de binnenkomende en uitgaande verbindingen naar en van die kernsystemen goed te controleren. In analogie met de stedenbouw is deze oplossingsrichting goed vergelijkbaar met een situatie waarbij de bewoners van een stad zich terugtrekken in het kasteel met slotgracht. De enige verbinding naar buiten (de ophaalbrug) wordt nauwlettend gecontroleerd.

Een uitdaging bij deze oplossingsrichting is dat deze oplossingsrichting mogelijk beperkt houdbaar is. Nieuwe kernsystemen, nieuwe toepassingen en nieuwe transportmiddelen die ‘over de slotgrachtbrug’ willen, dreigen voortdurend te leiden tot nieuwe gaten in de beveiliging. Hierdoor is het te verwachten dat oplossingsrichting 2 lastig te beheersen is.

C-2007-2-Zanten-t7

Tabel 7. Quick wins en uitdagingen oplossingsrichting 2.

Oplossingsrichting 3 – Onafhankelijk beschermen van informatie

Oplossingsrichting 3 vraagt een fundamentele verandering in de benadering van de informatiebeveiliging, namelijk het onafhankelijk van plaats en tijd beschermen van informatie.

In tegenstelling tot de andere oplossingsrichtingen richten we ons bij deze oplossingsrichting niet meer op het beveiligen van het ICT-netwerk of op de grens ervan. De focus ligt in deze oplossingsrichting op het beschermen van datgene waar het uiteindelijk allemaal om gaat: de informatie zelf. Adequate permanente bescherming van informatie is volledig onafhankelijk van het transportmiddel, de verwerking en de opslag.

Dreigingen die plaatsvinden op de grens van het ICT-netwerk (zoals gegevens die weglekken via bijvoorbeeld geheugensticks of Wi-Fi-verbindingen) zijn in deze oplossingsrichting onbelangrijk geworden. Immers, de informatie zelf is altijd beveiligd en kan dus ook bijvoorbeeld probleemloos op een onbeveiligde geheugenstick worden geplaatst. Door de onafhankelijke permanente bescherming van de informatie vormen ook nieuwe communicatiekanalen geen risico voor de bescherming van de informatie.

Men zou kunnen stellen dat de grens van het ICT-netwerk nu uiterst controleerbaar is gereduceerd tot de pakketjes met informatie zelf. Klein en behapbaar.

Voor het waarborgen van adequate bescherming van de stukjes informatie dienen we ook in oplossingsrichting 3 zeker te zijn van de juiste identiteit en autorisatie van diegene die de informatie probeert te gebruiken. Hierdoor vergt oplossingsrichting 3 sterk ingericht identity en access management dat zich richt op de informatie zelf en niet op de infrastructuur of op applicaties. De vertrouwelijkheid en integriteit van de stukjes informatie kan bijvoorbeeld worden gewaarborgd door het toepassen van sterke versleutelings- en hashing-algoritmen.

Echter, ook het beschermen van de informatie zelf kent in deze situatie nog vele uitdagingen:

  • De permanente onafhankelijke bescherming van data sluit niet goed aan bij de denkwijze die de afgelopen jaren is gehanteerd. Hierdoor is het te verwachten dat er veel aanpassingen nodig zijn in zowel hardware (firmware van apparaten die intern gegevens verwerken zoals netwerkcomponenten) als software (besturingssystemen, middleware en applicaties). Vooral de aanpassingen die nodig zijn om data continu te beschermen en te kunnen verwerken in veilige toestand zullen diverse uitdagingen opleveren. Mogelijke risico’s zijn het aftappen van geheugen, injecteren van programmacode of bijvoorbeeld het offline analyseren van zogenaamde swap en hibernate bestanden.
  • De beschermde data zullen op bepaalde momenten ontcijferd moeten worden voor verdere verwerking (door computer of mens). Zelfs als men erin slaagt een beveiligingssysteem te ontwerpen waarbij geen ongeautoriseerde toegang tot de gegevens kan worden verkregen tijdens de verwerking, is er altijd nog het moment dat de gegevens op het scherm worden getoond (of geprint). Door het maken van bijvoorbeeld een foto van die weergave van de informatie kan de informatiebeveiliging alsnog worden gebroken.
  • Het onafhankelijk beschermen van elke bit data zal voor een toename zorgen van het aantal benodigde beveiligde bits per bit informatie. Deze toename zal hierdoor ook effect hebben op de verwerking, het transport en bijvoorbeeld de opslag van informatie.
  • De kracht van oplossingsrichting 3, data overal beveiligd beschikbaar, is tevens een uitdaging. Door internationale verschillen in wetgeving en bijvoorbeeld opgelegde sancties is het waarschijnlijk dat men problemen krijgt bij de versleuteling van data. Afspraken over sleutellengte en gehanteerd versleutelprincipe kunnen een politiek onhaalbaar proces worden. Het inbouwen van zwakkere varianten (weak export cipher) is geen optie daar aanvallers deze varianten dan eenvoudig gebruiken om de beveiliging van het gehele systeem te reduceren tot de zwakste variant.

C-2007-2-Zanten-t8

Tabel 8. Quick win en uitdagingen oplossingsrichting 3.

Afsluiting

Vanuit historisch perspectief hebben we een zorgbarende ontwikkeling laten zien. Het blijkt steeds lastiger te worden om de grens van het ICT-netwerk van een organisatie te bepalen. Binnen de huidige benaderingswijze van informatiebeveiliging zal men die grens echter juist exact moeten bepalen omdat de beveiliging zich op die grens concentreert. Zonder het bepalen van de juiste grens is het alleszins aannemelijk dat diverse netwerkverbindingen en toegangspaden niet worden onderkend en derhalve niet in de beveiliging worden betrokken. Daarmee wordt de beveiliging van de gehele ICT-infrastructuur van de organisatie in gevaar gebracht.

De beschreven oplossingsrichtingen kennen alledrie hun eigen uitdagingen. Maar mede door het feit dat de markt tegenwoordig wordt gedreven door steeds verdergaande ketenintegratie, waarbij netwerken en informatiesystemen van organisaties aan elkaar worden gekoppeld ten behoeve van de directe verwerking van geleverde en/of afgenomen diensten (straight through processing), roepen de auteurs u en de gemeenschap op mee te denken over oplossingsrichting 3, de onafhankelijke permanente beveiliging van informatie.

Als we de komende jaren erin slagen oplossingen te vinden voor de interessante uitdagingen van oplossingsrichting 3, dan hoeven we ons geen zorgen meer te maken over het niet kunnen bepalen van de grens van het ICT-netwerk. Men zou kunnen stellen dat de grens van het ICT-netwerk dan uiterst controleerbaar is gereduceerd tot de kleinst mogelijke grens, namelijk de pakketjes met informatie zelf.

Borging en onderhoud van continuïteitsmaatregelen

Het regelen van bedrijfscontinuïteit houdt niet op bij de afronding van een bedrijfscontinuïteitsplan (BCP). Er moet ook een managementproces worden ingericht, waarmee wordt geborgd dat het BCP en alle technische en organisatorische voorzieningen worden onderhouden en ook periodiek worden getest. Zonder onderhoud verliest een BCP snel zijn waarde. Juist dit onderhoud blijkt in de praktijk voor veel organisaties een knelpunt te zijn. In dit artikel wordt een aantal factoren benoemd die helpen bij het inrichten van een managementproces voor continuïteit (BCM) waarbij daadwerkelijk onderhoud wordt uitgevoerd.

Inleiding

Het treffen van maatregelen voor het borgen van de continuïteit van bedrijfsprocessen is altijd van belang geweest. Vroeg of laat ontstaat binnen elke organisatie wel een aanleiding om op dit gebied een en ander te gaan regelen. De aanleiding kan bijvoorbeeld zijn: het bezoek van een toezichthouder, een klacht van een klant, een incident binnen het bedrijf of een gebeurtenis in de omgeving. Voorbeelden van zulke gebeurtenissen zijn de overstroming in New Orleans en (dreigende) aanslagen zoals in de Verenigde Staten, Spanje en het Verenigd Koninkrijk.

De echte beweegredenen om de continuïteit te waarborgen verschillen van organisatie tot organisatie, maar desgevraagd worden in de praktijk van KPMG één of meer van de volgende argumenten genoemd:

  • het voldoen aan wet- en regelgeving, het ‘afschudden’ van toezichthouders;
  • het voldoen aan verwachtingen van en afspraken met afnemers;
  • bescherming van de cashflow (‘als de schoorsteen niet rookt, dan wordt er niets verdiend’);
  • bescherming van de reputatie door het voorkomen van negatieve publiciteit;
  • bescherming van de belangen van aandeelhouders (aandelenkoers);
  • maatschappelijke verantwoordelijkheid;
  • bescherming van de belangen van medewerkers;
  • het voorkomen van schadeclaims;
  • het voorkomen van vertraging bij de ontwikkeling en introductie van nieuwe producten;
  • en ten slotte wordt steeds vaker onderkend dat continuïteitsmanagement zelfs kan worden ingezet voor het behalen van concurrentievoordeel, in het bijzonder door de leverbetrouwbaarheid van concurrenten te overtreffen.

Als naar aanleiding van een interne of externe gebeurtenis een organisatie daadwerkelijk een project voor het borgen van de bedrijfscontinuïteit initieert, is het van belang dat opdrachtgever en projectgroep verder kijken dan de doelstelling om een bedrijfscontinuïteitsplan (BCP) op te leveren. Een BCP is samen met geïmplementeerde technische voorzieningen vaak wel één van de meest tastbare resultaten van een dergelijk project, maar het is eigenlijk pas geslaagd als ook het bijbehorende managementproces – business continuity management (BCM) – duurzaam is ingericht (een voorbeeld van zo’n proces is weergegeven in figuur 1). BCM zorgt ervoor dat de opgeleverde voorzieningen ook daadwerkelijk worden onderhouden en getest. De praktijk wijst echter uit dat structureel onderhoud van de procedures en voorzieningen bij veel organisaties een aandachtspunt is. Organisatorische en technische veranderingen volgen elkaar in een dusdanig hoog tempo op, dat een BCP snel kan verouderen. Ter illustratie, velen herkennen ongetwijfeld de situatie dat een collega na een periode van afwezigheid over tal van ontwikkelingen en nieuwe werkwijzen moet worden bijgepraat.

C-2007-2-Petegem-1

Figuur 1. Het BCM-proces volgens de KPMG BCM Methodologie.

Dat het bovengenoemde aandachtspunt precies de grote uitdaging van veel organisaties is, blijkt uit een onderzoek dat KPMG in 2006 heeft uitgevoerd ([KPMG06]). Van de deelnemende organisaties:

  • gaf 36% van de organisaties met een BCP toe dat dit BCP een jaar of langer niet was geactualiseerd;
  • gaf 40% aan dat niet met het BCP wordt geoefend.

De conclusie die hieruit werd getrokken, luidde dan ook dat continuïteit op papier vaak wel is geregeld, maar dat het meestal niet zeker is of continuïteitsvoorzieningen in de praktijk ook goed werken.

In dit artikel wordt ingegaan op de uitdaging om een managementproces voor continuïteit in te richten. Aan de orde komt een aantal succesfactoren voor een situatie waarin continuïteitsvoorzieningen daadwerkelijk worden onderhouden en getest.

De koppeling van BCM met bedrijfsactiviteiten en/of IT-beheeractiviteiten

Managers zien informatiebeveiliging nog te vaak als een opzichzelfstaand fenomeen en niet als een integraal onderdeel van de bedrijfsvoering ([Over05]). Hierdoor is informatiebeveiliging onvoldoende geïntegreerd in de werkprocessen. Deze integratie is helaas over het algemeen ook onvoldoende voor BCM-processen. Om dit te voorkomen is het van belang dat het hoger management de verantwoordelijkheid neemt voor BCM en dat de IT-manager en de IT-organisatie volgend zijn ([Debe04]).

Wat is het gevolg als het hoger management onvoldoende zijn verantwoordelijkheid neemt voor BCM? Organisaties ervaren in dat geval pas bij het simuleren of optreden van calamiteiten dat BCP’s niet volledig en/of juist zijn. BCP’s, een resultaat van BCM, zijn de plannen die in werking treden in het geval van een calamiteit. Doordat het oefenen met BCP’s vaak niet plaatsvindt ([KPMG06]), is het hoger management zich vaak niet eens bewust van onvolledigheid en/of onjuistheid van BCP’s. Hierdoor bestaat het risico van ongewenste (langdurige) uitval van bedrijfsprocessen in geval van het optreden van calamiteiten. Dit probleem is op te vangen door het invoeren van twee maatregelen, namelijk het periodiek uitvoeren van BCP-tests en het inrichten van een onderhoudsproces voor alle onderdelen van een BCP.

Om periodiek kwalitatief goede tests te kunnen uitvoeren is het van belang dat in de periode tussen het plaatsvinden van de tests onderhoud op BCP’s plaatsvindt als onderdeel van de reguliere bedrijfsprocessen. Met deze benadering realiseert de organisatie een beleid dat zowel reactief als proactief is. Het onderhoud moet onder andere gericht zijn op het continu vastleggen en onderhouden van de afhankelijkheden die bestaan tussen en binnen de ketens van (IT-)componenten die samen een bedrijfsproces of IT-dienst vormen (zie kader 1 voor een uitleg over ketenafhankelijkheden).

Kader 1. Ketenafhankelijkheden.

Een organisatie kan niet zonder bedrijfsprocessen. Om deze bedrijfsprocessen te laten functioneren is een aantal middelen nodig, waaronder applicaties, mensen, procedures, grond- en hulpstoffen, etc. Deze middelen zijn op hun beurt weer afhankelijk van een aantal andere middelen. Applicaties bijvoorbeeld zijn voor hun functioneren weer afhankelijk van onder meer het netwerk, servers en andere applicaties.

Een voorbeeld: het bedrijfsproces inkoop heeft voor zijn dagelijkse werkzaamheden SAP nodig. SAP is beschikbaar via een cliënt die afhankelijk is van de beschikbaarheid van onder andere een applicatieserver en databaseserver van de organisatie. De applicatie- en databaseserver kunnen afhankelijk zijn van een licentie. Om de inkooporders te versturen vanuit SAP naar de leveranciers is tevens een externe koppeling, voor het uitwisselen van inkoopbestanden, met de leverancier noodzakelijk. Dit voorbeeld illustreert een aantal kritische componenten die van elkaar afhankelijk zijn en die samen als keten noodzakelijk zijn voor een inkoopproces.

Waarom is het belangrijk dat deze afhankelijkheden duidelijk in kaart worden gebracht en gehouden? De prioriteit van de directie van een bedrijf wordt meestal bepaald op het niveau van bedrijfsprocessen. Op directieniveau wordt vastgesteld wat de kritieke bedrijfsprocessen zijn. Deze processen dienen in geval van een calamiteit binnen een vastgestelde tijd weer in productie te zijn. Om dit effectief te kunnen uitvoeren is het van belang dat inzichtelijk is van welke componenten de bedrijfsprocessen afhankelijk zijn. Op basis daarvan kan het bedrijf investeren in de juiste BCM-oplossingen die leiden tot BCP’s die het bedrijf periodiek test.

Tabel 1 toont een mogelijke indeling van de componenten die van belang kunnen zijn voor een bedrijfsproces. Tussen deze componenten bestaan afhankelijkheden. Voorbeelden hiervan zijn applicaties die onderling afhankelijk zijn, zoals een klantensysteem of een relatiebeheersysteem dat klantgegevens verstrekt aan andere applicaties. Diezelfde applicaties kunnen op hun beurt bijvoorbeeld afhankelijk zijn van gegevensverzamelingen of koppelingen (interfaces) met derden.

C-2007-2-Petegem-t1

Tabel 1. Voorbeeld van een afhankelijkhedenschema.

Een organisatie met een tiental applicaties zal niet heel veel moeite hebben met het opstellen van een afhankelijkhedenschema. Veel middelgrote en grote organisaties hebben een applicatielandschap met meer dan honderd applicaties en een veelvoud aan afhankelijkheden (relaties) met bijvoorbeeld andere applicaties, databases, servers, (externe) koppelingen, organisatieonderdelen en bedrijfsprocessen. Deze afhankelijkheden kunnen tevens bestaan tussen en binnen ketens van bedrijfsprocessen.

Hoe gaan organisaties hier over het algemeen mee om? Soms beschikken organisaties over een schema waarin de initiële situatie van afhankelijkheden is vastgelegd. In de praktijk is de ervaring dat dergelijke schema’s niet onderhouden worden en afhankelijk van de organisatie al na een half jaar of eerder verouderd zijn. De oorzaak is maar al te vaak dat niemand verantwoordelijk is of de verantwoordelijkheid neemt voor het vastleggen en onderhouden van deze afhankelijkheden. Een deel van de oplossing kan zijn om het onderhoud duidelijk te beleggen in de organisatie. Daarmee is een oplossing echter nog niet geïmplementeerd. Het risico bestaat namelijk nog steeds dat de BCP’s niet tijdig zijn aangepast doordat wijzigingen in bijvoorbeeld de organisatie, de bedrijfsprocessen of het applicatielandschap niet tijdig zijn gemeld.

Kader 2. Business Continuity Plan.

Een Business Continuity Plan (BCP) beschrijft onder andere ([BSI03]):

  • de scope van het BCP;
  • doelstellingen van het BCP, zoals hersteltijden en toegestane hoeveelheid dataverlies in uren of dagen;
  • eigenaar van het BCP;
  • noodzakelijke organisatiestructuur – inclusief taken, bevoegdheden en verantwoordelijkheden – in het geval van een calamiteit. Voorbeelden zijn het crisisteam en de uitwijkteams;
  • uitwijkprocessen, zoals het melden van een calamiteit, het creëren van een oplossing voor een calamiteit en het herstellen van de gevolgen van de calamiteit.

Een bekend ITIL-proces waarmee organisaties dit kunnen ondervangen, is configuration management. Dit proces is niet een opzichzelfstaand proces maar moet gekoppeld zijn aan change management en release management (definities in kader 3), zodanig dat tijdens het uitvoeren van een wijziging die wijziging direct wordt verwerkt in een CMDB. Het configuration-managementproces moet daarbij zodanig zijn ingericht dat van alle componenten die van belang zijn voor de continuïteit van de organisatie, de relaties zijn vastgelegd.

Kader 3. Toelichting beheerprocessen ([ITSM04]).

Configuration Management Database (CMDB): de administratie van de configuratie-items, namelijk ieder productiemiddel waarvan het bestaan en de versie geregistreerd worden inclusief de daaruit resulterende diensten.

Change management: het gecontroleerd begeleiden van wijzigingsverzoeken zodanig dat storingen als gevolg van wijzigingen uitgevoerd op configuratie-items beperkt blijven.

Release management: proces voor het waarborgen van de kwaliteit van de productieomgeving door gebruik te maken van formele procedures en controles bij het implementeren van nieuwe versies.

Voor de effectiviteit van een dergelijk proces is het van groot belang dat taken, bevoegdheden en verantwoordelijkheden, zoals beschreven in het vervolg van dit artikel, zijn vastgelegd en dat personeel hierop wordt afgerekend. Een voorbeeld: een uitgevoerde wijziging mag worden afgesloten als ‘voltooid’, nadat de change manager heeft vastgesteld dat:

  • de wijziging succesvol is uitgevoerd;
  • de wijziging is vastgelegd, inclusief een evaluatie van de wijziging (lessons learned e.d.);
  • het resultaat van de wijziging is verwerkt in de CMDB;
  • het resultaat van de wijziging is verwerkt in de BCP’s.

Een dergelijke wijziging kan bijvoorbeeld een release van een nieuwe applicatie zijn, een wijziging in de organisatie met gevolgen voor de samenstelling van crisisteams of een wijziging in de infrastructuur.

De change manager is ervoor verantwoordelijk dat uiteindelijk alle changes kunnen worden afgesloten. Hiervoor heeft hij de bevoegdheid om bijvoorbeeld de configuration manager erop aan te spreken dat het verwerken van de changes in de CMDB en de BCP’s ook daadwerkelijk plaatsvindt.

Om zekerheid te verkrijgen over de werking van het configuration-managementproces is het van belang dat organisaties periodiek steekproefsgewijs de inhoud van de CMDB verifiëren.

Het inrichten van het configuration-managementproces kan een organisatie, naast een effectiever BCM-proces, velerlei voordelen opleveren, zoals:

  • efficiënter incident en problem management, doordat de helpdesk en de tweedelijnsorganisatie sneller inzicht hebben in de configuratie;
  • efficiënter change management, indien afhankelijkheden tussen componenten in de CMDB inzichtelijk zijn;
  • effectiever licentiemanagement.

De inbedding van BCM in de organisatie

Voor een effectief BCM-proces is het van belang dat de verantwoordelijkheden voor continuïteit op de juiste plaats zijn belegd. Belangrijker nog is echter dat deze verantwoordelijkheden ook daadwerkelijk worden genomen. Het komt in de praktijk vaak voor dat business continuity of informatiebeveiligingsfunctionarissen eigenhandig een business continuity beleid opstellen waarin de verantwoordelijkheden geheel of grotendeels ‘volgens het boekje’ worden beschreven:

  • De directie is eindverantwoordelijk voor BCM, bekrachtigt het BCM-beleid, accordeert de continuïteitsstrategie en stelt een passend budget ter beschikking.
  • De proceseigenaren uit de business zijn verantwoordelijk voor de continuïteit van hun eigen proces. Zij leveren input voor business-impactanalyses en risicoanalyses die onder hun verantwoordelijkheid worden uitgevoerd en stellen de continuïteitseisen vast, waaronder de maximale uitvalsduur en het maximale gegevensverlies. Deze proceseigenaren zijn tevens verantwoordelijk voor het actueel houden van hun eigen business continuity plan (of hun deel van het bedrijfsbrede business continuity plan).
  • De IT-afdeling is verantwoordelijk voor het inrichten en onderhouden van de continuïteitsmaatregelen ten aanzien van de IT-voorzieningen. De IT-afdeling conformeert zich hierbij aan de eisen van de proceseigenaren uit de business.
  • De business continuity functionaris (vaak business continuity manager, business continuity officer of business continuity coördinator genoemd) is verantwoordelijk voor het gevraagd en ongevraagd inhoudelijk adviseren van proceseigenaren en directie over BCM. Verder coördineert hij/zij activiteiten uit het BCM-proces, organiseert hij/zij afstemming op dit gebied tussen bedrijfsonderdelen en ontwikkelt hij/zij templates en tools voor BCM-activiteiten en documentatie. Deze rol wordt vaak vervuld door een (informatie)beveiligingsfunctionaris.
  • De interne en/of externe auditor is verantwoordelijk voor onafhankelijke beoordeling van en rapportage over de opzet, het bestaan en de werking van BCM-maatregelen. De auditor rapporteert aan de eindverantwoordelijke, zijnde de directie of Raad van Bestuur.

Helaas krijgt het bovengenoemde beleidsdocument van de directie om diverse redenen niet altijd de aandacht en/of bekrachtiging die het verdient. Daarnaast komt het niet zelden voor dat de lezerskring van het BCM-beleid niet veel verder strekt dan de auditors en/of de consultants die worden ingehuurd om een BCP op te stellen. Hoe kunnen we ervoor zorgen dat de verantwoordelijkheden ten aanzien van BCM echt worden genomen? Hieronder volgen drie succesfactoren:

  • Ten eerste is essentieel dat de eindverantwoordelijke (directie of Raad van Bestuur) het belang van BCM expliciet erkent. Hierdoor wordt automatisch op alle niveaus over het onderwerp gesproken. Deze gesprekken genereren weer de nodige awareness bij het lijnmanagement, waaruit vervolgens actie voortkomt.

    Bij dit punt moet worden opgemerkt dat erkenning van het belang van BCM door het topmanagement niet eenvoudig kan worden afgedwongen. Dit vereist een zorgvuldig proces waarbij timing, het hebben van de juiste argumenten, het kiezen van de juiste vorm en overtuigingskracht sleutelfactoren zijn.
  • Ten tweede kan het opnemen van de BCM-prestatie in een balanced scorecard of ander soort dashboard, en uiteindelijk in de beoordeling van een proceseigenaar bevorderlijk werken. Het mag kinderachtig lijken, maar in de praktijk blijkt dat zaken aandacht krijgen als ze direct van invloed zijn op een beoordeling.
  • Ten derde moeten medewerkers kunnen ‘scoren’ met het onderwerp BCM. Indien bijvoorbeeld een uitwijktest succesvol is verlopen, mag dit niet ongemerkt aan de rest van de organisatie voorbijgaan. Er moet dus de nodige interne en eventueel ook externe publiciteit aan worden gegeven, waarbij de betrokken afdelingen en/of medewerkers bij naam worden genoemd.

Outsourcing van BCM-activiteiten

Bijna alle activiteiten op het gebied van continuïteit kunnen aan een externe partij worden uitbesteed. In drukke perioden is de verleiding groot om zoveel mogelijk van deze taken uit te besteden. De stelregel waarop men zich daarbij doorgaans baseert is dat alleen de zaken waarmee een bedrijf zich echt van de concurrentie onderscheidt binnenshuis moeten worden uitgevoerd, zodat het concurrentievoordeel beschermd blijft. Omdat de meeste bedrijven zich niet in de eerste plaats van concurrenten willen onderscheiden op het vlak van continuïteit, bestaat het risico dat te veel wordt uitbesteed. Vanuit de praktijk kunnen de volgende vuistregels ten aanzien van het al dan niet uitbesteden van continuïteitsgerelateerde activiteiten worden gegeven.

Niet uitbesteden:

  • Het is niet verstandig om business continuity management-taken of regiefuncties uit te besteden, tenzij dit op zeer tijdelijke basis is. De verantwoordelijkheid voor het beheer van continuïteit hoort thuis bij het lijnmanagement. Uitbesteding hiervan kan de betrokkenheid van het lijnmanagement bij BCM negatief beïnvloeden. Bovendien geeft een lijnmanager hiermee ongewild het signaal af dat dit een minder belangrijk en/of interessant aspect van de bedrijfsvoering is.
  • Permanente ondersteuning bij coördinatie en/of praktische uitvoering van het BCM-beleid op detacheringsbasis. Het verdient voorkeur de kennis die hiervoor benodigd is in huis te hebben en te houden. Zelf de coördinatie voeren betekent vaak ook een betere integratie in de overige bedrijfsprocessen.
  • Het inhoudelijke onderhoud van BCP’s. Eigen medewerkers zijn over het algemeen beter op de hoogte van de veranderingen in organisatie en infrastructuur dan externe medewerkers. De interne medewerkers zullen in een crisissituatie met het BCP moeten werken. Tevens bevordert het periodiek en proactief bezig zijn met onderhoud de kennis van en betrokkenheid bij het BCP.

Wél uitbesteden:

  • Het oplossen van specialistische vraagstukken die zich zelden manifesteren;
  • het leveren van templates voor business-impactanalyses, risicoanalyses, BCP’s;
  • het faciliteren van het onderhoud van BCP’s;
  • het leveren van software voor het opstellen en/of onderhouden van BCP’s;
  • tijdelijke ondersteuning bij coördinatie en/of praktische uitvoering van het BCM-beleid op detacheringsbasis;
  • het verzorgen van cursussen of workshops op het gebied van continuïteit, mits deze kennis niet binnen de eigen organisatie beschikbaar is;
  • het uitvoeren van onafhankelijke audits;
  • het leveren van onafhankelijke adviesdiensten.

Samenvatting

Business continuity management is meer dan het opstellen van een bedrijfscontinuïteitsplan (BCP). Organisaties moeten ook een managementproces voor continuïteit inrichten. Hiermee wordt continu onderhoud van de documentatie en voorzieningen geborgd. In dit artikel is een aantal factoren genoemd die helpen bij het inrichten van een managementproces voor continuïteit (BCM) waarbij daadwerkelijk onderhoud wordt uitgevoerd. Ten eerste is van belang dat de BCM-processen worden geïntegreerd in de bedrijfsactiviteiten en (IT-)beheeractiviteiten. Enerzijds om zorg te dragen dat organisaties afhankelijkheden tussen en binnen de ketens zodanig vastleggen dat kritieke bedrijfsprocessen altijd hersteld kunnen worden. Anderzijds om BCP’s zodanig te onderhouden dat zij in geval van calamiteiten altijd effectief ingezet kunnen worden.

Ten tweede moet BCM goed in de organisatie worden ingebed. Dit is niet alleen een kwestie van het formeel in een beleid vaststellen van verantwoordelijkheden. De eindverantwoordelijke (directie of Raad van Bestuur) moet het BCM-beleid ook expliciet erkennen en liefst zelf actief uitdragen, zodat het belang ervan op alle niveaus in de organisatie wordt ingezien. Verder kan het opnemen van BCM-aspecten in de individuele beoordeling van lijnmanagers de prioriteitstelling beïnvloeden en daarmee de daadwerkelijke realisatie van BCM-doelstellingen bevorderen.

Ten derde werkt het goed en stimulerend als binnen de organisatie ruime aandacht wordt besteed aan successen op dit gebied, en de betrokkenen voor hun prestaties worden beloond.

Ten slotte moet een organisatie zorgvuldige keuzen maken met betrekking tot het al dan niet uitbesteden van BCM-gerelateerde activiteiten. Factoren die hierbij een rol spelen zijn het behoud en beheer van relevante kennis, het behouden van betrokkenheid bij het BCM-proces en de procedures in het BCP.

Literatuur

[BSI03] British Standards Institution, PAS 56:2003, Guide to Business Continuity Management, 2003.

[Debe04] Drs. S. Debets MBA MSIT en dr. D. Leegwater, Continuïteitseisen veranderen verantwoordelijkheid IT-manager, Automatisering Gids maart 2006.

[KPMG06] Onderzoek Informatiebeveiliging; Zes belangrijke signalen uit de praktijk, KPMG Information Risk Management, 2006.

[Over05] Dr. ir. P.L. Overbeek RE, prof. dr. E.E.O. Roos Lindgreen RE en dr. M.E.M. Spruit, Informatiebeveiliging onder controle?, Compact 2005/1.

[ITSM04] IT Service Management, een introductie, V4.0, januari 2004. ISBN 90-806713-2-0.

Waarom lukt het niet (zuinig) te beveiligen?

Dit artikel is een vervolg op het artikel ‘Zuinig beveiligen’ ([Korn03]), dat reeds eerder in Compact is verschenen. In het voorgaande artikel is aangegeven op welke wijze organisaties zuinig de beveiliging kunnen realiseren. In het thans voorliggende artikel wordt ingegaan op de oorzaken waardoor (zuinig) beveiligen bij menige organisatie toch (nog) niet is gelukt.

Inleiding

Organisaties hebben in de praktijk ten minste enige mate van IT-beveiliging gerealiseerd. Daarmee is in vele gevallen echter nog geen effectieve beveiliging tot stand gebracht, omdat vaak nog beveiligingslekken aanwezig zijn die vanaf extern of intern kunnen worden doorbroken.

In het voorgaande artikel over zuinig beveiligen ([Korn03]) zijn adviezen gegeven om essentiële beveiligingsmaatregelen te treffen, opdat met beperkte middelen toch een effectieve beveiliging kan worden gerealiseerd:

  • Fase 1 – Inrichten versterkte preventieve beveiligingsmaatregelen
    • opstellen van informatiebeveiligingsbeleid en inrichten van de beveiligingsorganisatie;
    • selecteren van (hoog)gevoelige informatie en IT-middelen;
    • instrueren van gebruikers over informatiebeveiliging;
    • formaliseren van kritieke beheerprocessen;
    • versterken van de beveiliging van de IT-infrastructuur.
  • Fase 2 – Versterken monitoring van beveiliging
    • kanaliseren van verantwoordingsinformatie betreffende de gerealiseerde kwaliteit van informatiebeveiliging;
    • testen van de effectiviteit van de getroffen maatregelen.

Het blijkt voor organisaties moeilijk de eerstgenoemde fase te doorlopen en daarmee een effectieve beveiliging te realiseren, terwijl hiermee in de praktijk nog niet eens het volwassenheidsniveau van aantoonbare beheersing (zie figuur 1) betreffende IT-beveiliging wordt gerealiseerd. En juist dat niveau van volwassenheid van de IT-beveiliging is nodig in bijvoorbeeld SOX- ([USSE03]) en Tabaksblat-gerelateerde ([Cocg03]) omgevingen, evenals in de financiële sector ([DNB01]).

C-2007-2-Kornelisse-1

Figuur 1. Volwassenheidsniveaus van IT-beveiliging.

Het blijkt moeizaam het niveau van aantoonbare beheersing van de IT-beveiliging te halen, laat staan op een efficiënte wijze en economisch verantwoord. Toch, een aantal organisaties is in staat gebleken aantoonbare beheersing van IT-beveiliging op effectieve én efficiënte wijze te realiseren. Uit onze ervaring gedurende de afgelopen jaren blijkt dat organisaties die hierin slagen, met name de volgende kenmerken hebben:

  • Deze organisaties gaan uit van eigen kracht en richten IT-beveiliging in uit vrije wil en wachten niet op wet- en/of regelgeving.
  • De gewenste wijzigingen worden gerealiseerd in een eigen tempo, waardoor in plaats van kortetermijn- direct langetermijnoplossingen tot stand worden gebracht.
  • Deze organisaties kunnen wijzigingen absorberen, omdat deze stapsgewijs worden ingevoerd, in plaats van (te) veel wijzigingen tegelijkertijd.
  • Er wordt door deze organisaties onderkend dat IT-applicaties en gegevens verschillende gevoeligheden kunnen hebben betreffende beschikbaarheid, integriteit en vertrouwelijkheid. Op basis hiervan vindt risicogebaseerd scoping van relevante ICT plaats, vervolgens vindt compliancegebaseerd implementatie van beveiligingsmaatregelen plaats.

Ambitieniveaus

Veel organisaties hebben, door wijzigingen in wet- en regelgeving, evenals de cultuur in de samenleving, een cultuurverandering ervaren als gevolg waarvan de volwassenheid van IT-beheersing en daarmee IT-beveiliging diende te worden verhoogd naar het niveau van aantoonbare beheersing, onder andere onder invloed van SOX en Tabaksblat. Het ambitieniveau van aantoonbare beheersing is daarmee een gegeven. Veel organisaties bevonden zich echter op een grote afstand van dit gewenste niveau, namelijk op het niveau tussen ad hoc en gedefinieerde processen.

C-2007-2-Kornelisse-t1

Tabel 1. Kenmerken van ambitieniveaus.

Er is voor die organisaties dan ook een grote stap te maken. Organisaties die onder invloed van SOX in korte tijd van tussen herhaalbaar en gedefinieerde processen naar aantoonbare beheersing dienden te groeien, ervoeren hierbij dan ook groeipijnen. Er ontstond veel druk in deze organisaties en wijzigingen werden nogal eens ‘kort door de bocht’ gerealiseerd, waardoor inefficiënties optraden.

Het is van belang voor organisaties vast te stellen welk ambitieniveau betreffende de volwassenheid van IT-beheersing gewenst is, gegeven de geldende wet- en regelgeving en de gewenste risicobeheersing binnen de organisatie.

Er was ook veel onduidelijkheid over de implicaties van het gedefinieerde ambitieniveau:

  • Voor welke beheerprocessen en ICT-objecten geldt het ambitieniveau van aantoonbare beheersing (scoping)?
  • Welke eisen dienen te worden gesteld aan de ICT-objecten binnen de scope?

Deze onderwerpen worden hierna behandeld.

Scoping

Het blijkt moeizaam voor organisaties om op adequate wijze de relevante scope vast te stellen betreffende de ICT-beheerprocessen en ICT-componenten die op het niveau aantoonbare beheersing dienen te zijn ingericht ([Korn05]). In de praktijk dient een organisatie hiertoe de relevante IT-applicaties vast te stellen, door per IT-applicatie het materiële risico voor het bijbehorende bedrijfsproces te bepalen, bijvoorbeeld door het evalueren van operationele risico’s en risico’s betreffende financiële rapportages.

Op basis van de onderkende IT-applicaties kunnen eenvoudig de applicatiespecifieke ICT-componenten worden vastgesteld; dit zijn de aan de IT-applicaties gerelateerde applicatie- en databaseservers.

Voor generieke ICT-infrastructuurcomponenten (ICT-componenten die door meerdere applicaties worden gebruikt, zoals bedrijfsnetwerken en beheerplatforms) blijkt dit moeizamer, met name door druk binnen de organisatie om ICT-componenten out-of-scope te verklaren, waardoor aantoonbare beheersing eenvoudiger haalbaar lijkt te worden.

Bij het selecteren van de relevante generieke ICT-infrastructuur is het van belang af te wegen welke ICT-componenten op de paden van de eindgebruikers tot de data en van de beheerders tot de te beheren objecten liggen. Dit vraagt om een complexe en uitgebreide analyse. Efficiënter en effectiever blijkt het de essentiële beveiligingsarchitectuur van de ICT-infrastructuur te definiëren, hetgeen veelal resulteert in een scoping van het interne netwerk, identity management en security monitoring.

Weliswaar is daarmee de scoping van de generieke ICT-componenten slagvaardig uitgevoerd, echter, de meeste organisaties ervaren deze drie ICT-componenten als lastig om in scope te verklaren. De reden hiervoor ligt veelal in het feit dat aantoonbare beheersing voor deze ICT-componenten thans niet is gerealiseerd.

Bijvoorbeeld netwerkkoppelingen met derde partijen worden vaak als risicovol gezien en verdienen veelal een aantoonbare beheersing. Toch, diverse organisaties hebben geen juist en volledig overzicht van deze externe netwerkkoppelingen en controleren externe netwerkkoppelingen ook niet op gestructureerde wijze.

Voor scoping is het van belang eerst de bij de relevante bedrijfsprocessen behorende essentiële IT-applicaties te selecteren. Op basis van de onderkende essentiële IT-applicaties worden de onderliggende applicatiespecifieke IT-componenten geselecteerd. Tevens worden de generieke ICT-componenten geselecteerd, die samen de essentiële beveiligingsarchitectuur van de organisatie vormen. De bij de IT-applicaties en ICT-componenten horende IT-beheerorganisaties en -processen horen tot slot ook binnen de scope.

Veelvoorkomende knelpunten

Procesmatige knelpunten

Tot de knelpunten van dit type behoren:

  • Identity & Access Management;
  • ICT-component security;
  • change management.
Identity & Access Management

Identity & Access Management dient te borgen dat alleen volgens een strikte procedure de eindgebruikers en beheerders met passende bevoegdheden in de systemen worden geïmplementeerd, en dat periodiek wordt gerapporteerd en gecontroleerd of alleen de juiste eindgebruikers en beheerders en bevoegdheden zijn geïmplementeerd.

Veel organisaties werken bij eindgebruikers (nog) niet (integraal) met single sign-on en Role Based Access Control, met als gevolg dat het verkrijgen van een volledig overzicht van gebruikers en hun bevoegdheden niet effectief en efficiënt kan plaatsvinden. Bijgevolg ontvangen applicatie-eigenaren en afdelingshoofden niet of niet regelmatig overzichten en worden daardoor de geïmplementeerde gebruikersaccounts en gebruikersbevoegdheden niet periodiek gecontroleerd.

Voor beheerders ligt dit vaak nog moeilijker. Voor elke ICT-component, van database tot server tot netwerkcomponent, is het gewenst de beheerderaccounts en beheerderbevoegdheden te controleren. Echter, de beheerderaccounts zijn veelal niet eenduidig geadministreerd en worden veelal ook niet regelmatig gerapporteerd.

Het is van belang Identity & Access Management voor eindgebruikers en beheerders dusdanig op te zetten, dat op effectieve en efficiënte wijze verantwoordingsinformatie kan worden opgeleverd.

Naast het rapporteren en controleren van bevoegdheden wordt nogal eens onderkend dat bij diverse organisaties de beheerders met hoge bevoegdheden een vertrouwensfunctie hebben, hetgeen betekent dat een beheerder activiteiten kan uitvoeren die niet door een ander (kunnen) worden gecontroleerd. Dit is niet gewenst voor het ambitieniveau van aantoonbare beheersing.

ICT-component security

Het aantoonbaar beveiligen van ICT-componenten vraagt om twee belangrijke activiteiten:

  • implementatie van ICT-componenten volgens security baselines;
  • patch management voor alle ICT-componenten.

Het is gewenst voor elk type van de aanwezige ICT-componenten een security baseline te hebben, de ICT-componenten conform de gedefinieerde security baselines te implementeren en periodiek te controleren of ICT-componenten conform baselines zijn geïmplementeerd.

Diverse organisaties blijken echter niet te beschikken over (alle relevante) security baselines, bijvoorbeeld doordat bepaalde ICT-componenten zoals mainframes en netwerkcomponenten slechts in beperkte mate voorkomen.

Daarnaast hebben veel organisaties controle van de compliance van ICT-componenten aan de bijbehorende security baselines niet ingeregeld en/of geautomatiseerd, waardoor controle van compliance aan security baselines niet plaatsvindt of dusdanig inefficiënt blijkt te zijn dat deze niet voldoende regelmatig plaatsvindt.

Wat betreft patch management blijkt dat organisaties nieuwe patches niet of laat analyseren en niet of niet tijdig implementeren, waardoor de organisaties meer gevoelig zijn voor virussen en inbrekers.

ICT-component security is één van de voornaamste preventieve maatregelen om te voorkomen dat derden (personen van buiten de organisatie) of interne medewerkers op ongeautoriseerde wijze de ICT-omgeving van de organisatie binnendringen. Om dit te voorkomen dienen ICT-componenten conform security baselines te worden geïmplementeerd, hetgeen ook periodiek dient te worden gecontroleerd, in samenhang met de geïmplementeerde patches.

Change management

Veel organisaties hebben voor change management een duidelijke procedure vastgesteld. In de praktijk wordt echter onderkend dat naast reguliere changes ook plaatsvinden:

  • urgente changes met beperkte tot geen goedkeuring vooraf, die achteraf dienen te worden verantwoord, evenals
  • kleine wijzigingen in de productieomgeving, die niet via change management verlopen.

Het lastige van urgente changes en kleine wijzigingen in de productieomgeving is, dat het niet altijd duidelijk is wanneer een change als urgent of klein mag worden geclassificeerd. Dit vraagt om duidelijke spelregels die echter nogal eens ontbreken en/of niet eenduidig zijn.

De meeste organisaties zijn niet in staat ongeautoriseerde changes te detecteren door het ontbreken van hulpmiddelen hiertoe, terwijl dergelijke hulpmiddelen wel bestaan (bijvoorbeeld checksumprogrammatuur van TripWire).

Wijzigingen dienen adequaat te worden getest, en bijgevolg zijn gelijke omgevingen gewenst voor het testen van wijzigingen en verwerking in productie. Echter, in de praktijk zijn deze omgevingen niet altijd in voldoende mate gelijk, waardoor de kwaliteit van het testen wordt beperkt.

Bij een change zijn diverse medewerkers betrokken, die allen een deel van de documentatie verzorgen en een deel van een change testen. Daardoor komt het nogal eens voor dat voor een change niet alle documentatie betreffende ontwerpen en testen is gebundeld, hetgeen controle van een change achteraf bemoeilijkt.

Bij change management dienen duidelijke spelregels te zijn vastgesteld voor reguliere, urgente en kleine wijzigingen. Voor kritieke bestanden dient te kunnen worden vastgesteld of zich wijzigingen hebben voorgedaan.

Betreffende alle wijzigingen dient de bijbehorende documentatie te worden verzameld en bewaard, opdat achteraf een change kan worden gecontroleerd.

Technische knelpunten

Als gevolg van onvolwassenheid van beheerprocessen, zoals het ontbreken of het niet adequaat inrichten van een aantal beheerprocessen, ontstaan nogal eens technische knelpunten die de beveiliging van de ICT-omgeving ondermijnen. Op technisch gebied is het daarom van belang een eenvoudige securityarchitectuur en IT-infrastructuur te handhaven. Dit vereist het proactief ontwerpen van benodigde IT-voorzieningen, bijvoorbeeld netwerkfiltering (extern en intern), authenticatievoorzieningen (Active Directory, Radius) en security monitoring (verzamelen, controleren en rapporteren inzake logging, evenals controleren van systeemconfiguraties, verzamelen en rapporteren inzake afwijkingen).

Een organisatie dient een eenvoudige securityarchitectuur en IT-infrastructuur te ontwerpen, te implementeren en in stand te houden.

Oorzaken van geconstateerde knelpunten

Op basis van onze ervaringen bij vele organisaties blijkt het gerealiseerde volwassenheidsniveau van IT-beveiliging steeds weer te worden beïnvloed door vier aspecten, die juist een basis voor IT-beveiliging zouden kunnen leggen:

  • Sponsoring en leiderschap betreffende IT-beveiliging ontbreekt, waardoor gestructureerde beheersing van IT-beveiliging uitblijft. Ad hoc worden bij strikte noodzaak onsamenhangende beveiligingsoplossingen gerealiseerd.
  • Beveiliging is veelal IT-gedreven; de business is niet of onvoldoende betrokken, waardoor beveiliging niet wordt gebaseerd op het risicoprofiel van de organisatie en haar bedrijfsprocessen.
  • Een organisatie heeft geen ambitieniveau vastgesteld betreffende de beheersing van IT-beveiliging, waardoor het belang van het vastleggen van procedures en beveiligingsstandaarden niet wordt erkend, evenals het belang van controle op naleving hiervan.
  • Een organisatie onderkent IT-beveiliging niet als een continu proces maar als een eenmalige gebeurtenis. Als gevolg hiervan ontbreekt veelal een gestructureerd (jaar)plan om IT-beveiliging op niveau te houden. In figuur 2 is IT-beveiliging als een continu proces weergegeven.

C-2007-2-Kornelisse-2

Figuur 2. Cyclus van IT-beveiliging.

Als een adequaat ambitieniveau voor IT-beveiliging niet is vastgesteld, dan resulteert dit veelal in de diverse gebreken, zoals:

  • Rapportage betreffende IT-beveiliging vindt niet plaats, waardoor zowel de werkvloer als het verantwoordelijke management niet worden geïnformeerd over mogelijke operationele knelpunten en de gevolgen daarvan.
  • Structurele voorzieningen ontbreken, zoals een documentbeheersysteem en registratie- en rapportagevoorzieningen, waardoor informatie niet efficiënt en effectief toegankelijk is.
  • Bij uitbesteding worden door de organisatie geen concrete eisen gesteld in contracten en/of SLA’s.
  • Bij nieuwe ontwikkelingen, bijvoorbeeld het gebruik van USB-geheugens, wordt geen beleid opgesteld en geïmplementeerd, waardoor nieuwe risico’s ontstaan.

Aandachtspunten voor de organisatie

Afwachten tot wet- en/of regelgeving op een organisatie afkomt, vraagt om het behalen van een bepaalde mate van beveiliging in (te) korte tijd en werkt dan kostenverhogend. Door proactief zelf beveiliging ter hand te nemen, kunnen direct langetermijn- in plaats van kortetermijnoplossingen worden ingeregeld en kunnen tevens beveiligingsrisico’s veelal efficiënter en effectiever worden gemitigeerd.

Een organisatie dient hiertoe de aansturing van IT-beveiliging te borgen. Dit vraagt om sponsoring vanuit de leiding van de organisatie en leiderschap van de verantwoordelijke voor IT-beveiliging. Voor de sturing zijn een informatiebeveiligingsbeleid en tactische beveiligingseisen nodig. Deze dienen op operationeel niveau te worden vertaald naar onder andere IT-beheerprocedures en systeemconfiguraties van IT-infrastructuurcomponenten.

C-2007-2-Kornelisse-3

Figuur 3. Inrichting van IT-beveiliging.

Naast een adequate inrichting van IT-beveiliging is het van belang het ontworpen huis periodiek te evalueren, via interne controle (bijvoorbeeld op het punt van registraties en systeeminstellingen), risicoanalyses, penetratietests en IT-audits. Hiertoe is het van belang jaarlijks vast te stellen welke mate van zekerheid gewenst is betreffende IT-beveiliging, zowel wat de IT-beveiligingsprocessen als de feitelijk ingerichte IT-beveiliging op operationeel niveau aangaat.

Op het operationele niveau is het van belang voor de essentiële IT-applicaties de ontworpen en geïmplementeerde maatregelen te inventariseren en te evalueren. Hierbij worden onderzocht: administratie en interne controle, IT-applicatieve maatregelen, IT-infrastructurele maatregelen en IT-beheermaatregelen (zie figuur 4).

C-2007-2-Kornelisse-4

Figuur 4. Operationele aandachtsgebieden.

De wijze waarop IT-beheerprocessen en beveiligingsstandaarden worden gedocumenteerd en gedistribueerd, bepaalt mede de effectieve en efficiënte inzet van deze middelen binnen een organisatie.

In de praktijk blijken organisaties die expliciet eisen voor het opstellen van interne documentatie hebben gedefinieerd en voor distributie bijvoorbeeld een intranet hanteren, slagvaardiger te zijn. Dit kan nog verder worden versterkt als registraties en rapportages hierbij worden meegenomen.

Aandachtspunten voor de IT-auditor

Organisaties vragen in veel gevallen aan een IT-auditor om de huidige status van de IT-beveiliging te beoordelen. Een perfecte situatie wordt in de praktijk niet vaak aangetroffen, en de IT-auditor zal veelal diverse (operationele) bevindingen en aanbevelingen kunnen rapporteren.

Knelpunten betreffende de operationeel gewenste maatregelen dienen te worden gerapporteerd, bijvoorbeeld risico’s betreffende IT-beheerprocessen en ongewenste systeeminstellingen van ICT-componenten.

Daarnaast is het van belang aan het management van de organisatie de risico’s te rapporteren ten aanzien van vertrouwelijkheid, betrouwbaarheid en continuïteit, door aan te geven welke functiescheidingen kunnen worden doorbroken, hoe groot de kans daarop is en met een inschatting van de mogelijke impact (bijvoorbeeld welke gegevens kunnen worden ontsloten, en/of welke gegevens en programma’s kunnen worden gewijzigd, en/of welke bedrijfsprocessen kunnen worden verstoord).

C-2007-2-Kornelisse-5

Figuur 5. Vereiste functiescheidingen.

Het is ook van belang te beseffen wat de organisatie na het rapporteren door de IT-auditor vervolgens wenst, namelijk risico’s onderkennen en keuzen maken betreffende de mate van en de wijze waarop aanbevelingen dienen te worden opgevolgd. Om te voorkomen dat een organisatie alleen geconstateerde operationele knelpunten oplost, dienen in het bijzonder ook de oorzaken van deze pijnpunten te worden geadresseerd. Hiertoe dient de IT-auditor te deduceren welke oorzaken ten grondslag liggen aan de geconstateerde operationele knelpunten. Dit betreft nogal eens het volgende:

  • IT-beveiliging is niet gestructureerd ingericht, bijvoorbeeld richtlijnen, procedures en/of beleid (op onderdelen) ontbreken.
  • Rapportages betreffende IT-beveiliging ontbreken, waardoor het management zich niet bewust is van risico’s en prioriteitstelling betreffende verbeteringen niet adequaat plaatsvindt.
  • IT-security is niet ingericht als een continu proces, bijvoorbeeld beveiligingsproblemen worden geïsoleerd opgelost.
  • Gestructureerde vastlegging van documenten vindt niet plaats, waardoor het gebruik ervan beperkt blijft.

Tot slot

In de loop der jaren blijken diverse organisaties een hoog niveau van IT-beveiliging te hebben kunnen bereiken. Ook zijn er diverse organisaties die al jaren aan de slag zijn en bewust pogen een hoger niveau van beveiliging te realiseren, maar het lukt hen (nog) niet. Hierbij is veel geld tevergeefs uitgegeven en is mogelijk schade opgelopen.

Het is van groot belang de consequenties van adequate IT-beveiliging onder ogen te zien, namelijk dat hierbij keuzen dienen te worden gemaakt, de flexibiliteit kan worden beperkt, maar ook het kwaliteitsbesef kan worden verhoogd, en dat daardoor nogal eens de efficiëntie en de effectiviteit en de slagvaardigheid van de organisatie kunnen worden verbeterd.

Alle betrokkenen van de organisatie dienen te beseffen dat IT-beveiliging een continu proces is en dat zij IT-beveiliging adequaat dienen te ondersteunen. IT-beveiliging blijft echter mensenwerk, hetgeen betekent dat individuen binnen de organisatie een transitie dienen te ondergaan van onbewust niet adequaat naar onbewust adequaat (zie figuur 6) betreffende IT-beveiliging. Hiermee wordt gestimuleerd dat de medewerkers van de organisatie op het punt van IT-beveiliging spontaan proactief handelen en op alle functies beveiliging verder brengen.

C-2007-2-Kornelisse-6

Figuur 6. Ontwikkeling van besef inzake IT-beveiliging.

Wacht dan ook niet af, maar bepaal de eigen koers van de organisatie voor een efficiënte en effectieve beveiliging.

Literatuur

[Cocg03] Commissie corporate governance, De Nederlandse corporate governance code, 9 december 2003.

[DNB01] DNB, Regeling organisatie en beheersing, 29 maart 2001.

[Korn06] Ir. P. Kornelisse RE CISA en H. IJkel RE CISA CISSP, Een inleiding tot integrated audit, Compact 2006/2.

[Korn05] Ir. P. Kornelisse RE CISA, R.P.J. van den Berg RA en A.A. van Dijke, SOX – Scoping van de relevante ICT, Compact 2005/3.

[Korn04] Ir. P. Kornelisse RE CISA, Security monitoring – De IT-infrastructuur aantoonbaar in control, de EDP-auditor 2004/4.

[Korn03] Ir. P. Kornelisse RE, Zuinig beveiligen?, Compact 2003/4.

[USSE03] US Securities and Exchange Commission, Final Rule: Management’s Reports on Internal Control Over Financial Reporting and Certification of Disclosure in Exchange Act Periodic Reports, Release Nos. 33-8238; 34-47986; IC-26068; File Nos. S7-40-02; S7-06-03, USA, June 2003.

In control ten aanzien van uw autorisatiemanagement

‘In control’ ten aanzien van autorisatiemanagement is een vereiste vanuit steeds stringenter wordende wet- en regelgeving, zoals Sarbanes-Oxley (SOX), Basel II en privacywetgeving. In dit artikel wordt beschreven op welke wijze organisaties effectief en efficiënt het voldoen aan deze vereisten aan kunnen tonen (‘compliance verification’) om vervolgens het huis structureel op orde te krijgen en te houden. Autorisatiemanagement op basis van het concept rolgebaseerd autoriseren kan hierbij een belangrijke rol spelen. In dit artikel wordt vooral ingegaan op de praktische kant van het onderwerp, gebaseerd op een aantal concrete praktijkvoorbeelden. Daarnaast wordt de relatie toegelicht met het thema Identity & Access Management (IAM).

Inleiding

Al zolang organisaties gebruikmaken van informatietechnologie speelt de toegangsverlening tot de informatie van de organisatie een belangrijke rol. Informatie is tegenwoordig één van de meest waardevolle ‘assets’ van een organisatie. Zonder de juiste informatie worden foutieve beslissingen genomen, kan het bedrijfsproces niet goed worden uitgevoerd, worden klanten minder goed geholpen of wordt schade geleden. Uiteraard speelt hierbij ook het voldoen aan wet- en regelgeving, zoals SOX en Basel II, een belangrijke rol. Het is dus zaak dat iemand over de juiste informatie kan beschikken en dat onbevoegden geen toegang hebben tot informatie, bijvoorbeeld financiële gegevens, klantgegevens en informatie die wordt gebruikt voor de besturing en uitvoering van de primaire processen.

Met het steeds complexer wordende applicatielandschap, fusies en overnames en eisen van de business ten aanzien van IT is het voor organisaties een voortdurende uitdaging om de autorisaties op orde te krijgen, en die ook op orde te houden. In dit artikel wordt een aanpak geschetst van de wijze waarop de organisatie de enorme brij aan foutieve autorisaties op orde kan krijgen en de juiste autorisaties daarna ook op orde kan houden. Dit laatste wordt vaak vergeten of hiervoor wordt niet tijdig een proces ingericht. Het gevolg hiervan is dat jaarlijks projecten worden opgestart om de autorisaties te schonen. Dit levert veel frustraties op aan zowel de IT- als de businesskant en slokt bovendien te veel tijd op. Hierdoor komen medewerkers niet aan hun primaire taken toe en wordt compliance onnodig duur.

Autorisatiemanagement – merendeel van de organisaties onvoldoende ‘in control’

Een enquête van KPMG uit 2006, waarin ongeveer duizend verantwoordelijken voor IT werden geënquêteerd, laat zien dat het merendeel van de organisaties aangeeft niet volledig in control te zijn ten aanzien van autorisaties ([KPMG06]). Zo geeft het merendeel van de geënquêteerden aan niet te weten of de uitgegeven autorisaties correct zijn en geen goed en up-to-date-overzicht te hebben van de verstrekte autorisaties. Wetende dat controleerbaarheid en het uitvoeren van deze controles één van de belangrijkste vereisten is van eerdergenoemde diverse wet- en regelgeving, is het niet erg bemoedigend dat slechts 38 procent van de geënquêteerden regelmatig autorisaties controleert.

Kader 1. Enkele uitkomsten enquête KPMG ten aanzien van autorisaties.

  • 73% van de ondervraagden weet niet of uitgegeven autorisaties correct zijn.
  • 77% van de ondervraagden heeft geen goed up-to-date inzicht in de verstrekte autorisaties.
  • Slechts 38% van de ondervraagden geeft aan autorisaties regelmatig te controleren.

C-2007-2-Hermans-k1

Autorisatiemanagement – relatie met compliance

Met de komst van SOX, Basel II en Tabaksblat is transparantie een niet te ontwijken eis geworden voor veel organisaties. In tabel 1 wordt een overzicht gegeven van de meest in het oog springende wet- en regelgeving. Het merendeel hiervan stelt ten aanzien van privacy en integriteit van data soortgelijke vereisten. Deze vereisten zijn terug te voeren op richtlijnen voor de opzet van autorisatiemodellen binnen organisaties evenals het proces van beheer van toegang tot data. Daarbij is het noodzakelijk om het daadwerkelijk voldoen aan deze vereisten aantoonbaar te maken (compliance). Recent onderzoek van The Ponemom Institute toont aan dat de meeste organisaties een handmatige aanpak hebben voor het verifiëren van controls ten aanzien van autorisaties ([Pone07]).

C-2007-2-Hermans-t1

Tabel 1. Overzicht van toepasselijke wet- en regelgeving.

De meeste wet- en regelgeving behandelt:

  • privacy- en data-integriteit;
  • het beheer van toegang tot deze data (‘wie heeft toegang tot welke data en hoe wordt dit gegarandeerd’);
  • een verandering van ‘vertrouwen’ naar ‘bewijzen’ → aantoonbaar ‘in control’ zijn.

Kortom, indien een organisatie niet aantoonbaar ‘in control’ is, bestaat er dan een oplossing waarbij een organisatie op een efficiënte wijze effectief autorisatiemanagement kan inrichten?

In de voorgaande paragraaf is aangegeven dat veel organisaties niet ‘in control’ zijn ten aanzien van autorisatiemanagement. Veel organisaties starten projecten, of hebben reeds projecten gestart, om het autorisatiemanagement te verbeteren. Uit al gestarte projecten blijkt dat veel organisaties moeite hebben met de tijdige realisatie van hun doelstelling, te weten effectief en efficiënt autorisatiemanagement. Belangrijke oorzaken hiervan zijn:

  • Geen gefaseerde aanpak met tussenresultaten. Wanneer een organisatie direct een zeer fijnmazig rollenmodel wil implementeren, kost dit een behoorlijke inspanning wat een langdurig traject tot gevolg heeft. Het risico hiervan is dat projecten worden gestaakt omdat na verloop van tijd nog steeds geen concrete resultaten zijn geboekt en de organisatie nog niet ‘in control’ is.
  • Veel projecten worden vanuit de IT-organisatie opgestart, waardoor de aansluiting met de business niet of nauwelijks wordt bereikt.
  • Het autorisatiemanagementproces wordt niet verbeterd en uitgebreid in relatie tot het beheren van rollen, een middel waarmee de organisatie in staat wordt gesteld haar verantwoordelijkheid te nemen ten aanzien van autorisatiemanagement.

Om wel tot een succesvol project te komen en de organisatie ‘in control’ te brengen ten aanzien van autorisatiemanagement moet de projectaanpak:

  • efficiënt en pragmatisch zijn. De business moet worden betrokken maar de benodigde betrokkenheid van de business, uitgedrukt in tijd, moet minimaal zijn. Zo niet, dan verliest het project al snel draagvlak.
  • leiden tot een structurele oplossing zodat er niet ieder jaar een opschoningstraject hoeft te worden gestart.
  • snel resultaat opleveren zodat de grootste problemen snel worden opgelost en het project aantoont echt toegevoegde waarde te bieden.

In figuur 1 is de aanpak waarmee autorisatiemanagement wordt verbeterd, schematisch weergegeven. Belangrijkste onderdelen hieruit zijn:

  • het inrichten van een complianceverificatieproces teneinde snel het eerste niveau van compliance te bereiken. In dit proces wordt gerapporteerd over de status van de huidige uitgegeven autorisaties en het management neemt mitigerende acties op basis van de rapportages.
  • het herinrichten, optimaliseren en automatiseren van delen van het autorisatiemanagementproces om nieuwe vervuiling te voorkomen en om te kunnen werken met rolgebaseerde autorisaties. Hierbij wordt het gebruik van een autorisatiemanagementtool aangeraden.

C-2007-2-Hermans-1

Figuur 1. Aanpak verbetering van autorisatiemanagement.

Het complianceverificatieproces

Inrichting van het complianceverificatieproces

Aangezien het aantonen van het niveau van compliance voor de organisatie vaak de hoogste prioriteit heeft, richt de eerste stap zich dan ook op het opzetten en inrichten van dit verificatie- en rapportageproces. In dit proces wordt in kaart gebracht welke bedrijfsregels er gelden ten aanzien van autorisaties (bijvoorbeeld functiescheiding) en wordt gevalideerd of de regels in de praktijk ook zijn nageleefd bij de daadwerkelijk geïmplementeerde autorisaties. De uitvoering van deze stap is daarnaast noodzakelijk om autorisaties rolgebaseerd te kunnen gaan beheren. Anders gaat men immers foutieve autorisaties in nieuwe rollen opnemen.

De zogenoemde bedrijfsregels worden afgeleid van intern beleid en procedures, evenals externe wet- en regelgeving, zoals:

  • SOX 404;
  • mededingingswetgeving (NMa);
  • privacywetgeving (Wet bescherming persoonsgegevens).

De bedrijfsregels worden opgesplitst in generieke en applicatiespecifieke regels. De generieke regels zijn van toepassing op de autorisaties van alle applicaties. Daarnaast kunnen ook generieke regels bestaan voor het beheer van de IT-infrastructuur. Naast de generieke regels wordt per applicatie bepaald welke regels van toepassing zijn in relatie tot de autorisaties. Deze specifieke regels worden vaak opgesteld op basis van beschikbare functionele ontwerpen, risicoanalyses in relatie tot functiescheiding en beschikbare autorisatiematrices. Tabel 2 geeft een aantal voorbeelden van bedrijfsregels.

C-2007-2-Hermans-t2

Tabel 2. Voorbeelden van generieke en applicatiespecifieke maatregelen.

Om een efficiënte analyse mogelijk te maken, kan voor complianceverificatie een geautomatiseerde analysetool worden gebruikt. Het voordeel hiervan is dat de analyse vele malen sneller wordt uitgevoerd. Eigenlijk is een handmatige analyse onmogelijk voor omvangrijke applicaties en gebruikersgroepen. Een tweede voordeel is, dat de analyse consistent wordt uitgevoerd op basis van geprogrammeerde regels.

Het is hierbij belangrijk om zich te realiseren dat de analysetool slechts een hulpmiddel is. Er moet nog steeds een proces worden ingericht en het opstellen van de bedrijfsregels is iets wat een analysetool niet doet. De inhoud van de bedrijfsregels bepaalt de output van de analyse en niet een geavanceerde analysetool die mogelijk door ondeskundigen wordt gebruikt.

In figuur 2 is het complianceverificatieproces schematisch weergegeven en in tabel 3 is iedere processtap kort beschreven.

C-2007-2-Hermans-2

Figuur 2. Complianceverificatieproces ten aanzien van autorisatiemanagement.

C-2007-2-Hermans-t3

Tabel 3. Processtappen behorende bij complianceverificatie. [Klik hier voor grotere afbeelding]

Resultaat van het complianceverificatieproces

Het beschreven complianceverificatieproces stelt de organisatie in staat:

  • op een snelle wijze te rapporteren over het niveau van compliance ten aanzien van voor de organisatie geldende compliancevereisten ten aanzien van autorisatiemanagement;
  • de verantwoordelijkheid bij de juiste functionarissen te beleggen;
  • door het verkregen inzicht de gewenste situatie ten aanzien van autorisaties te herstellen door het opschonen van accounts en autorisaties (verwijderen van zogenaamde ‘ghost accounts’ en van excessieve toegangsrechten);
  • op basis van de opgeschoonde situatie haar autorisatiemanagement structureel te verbeteren en desgewenst rolgebaseerd autorisatiemanagement in te voeren.

Aandachtspunten bij de inrichting van het complianceverificatieproces

Bij de inrichting van het complianceverificatieproces spelen de volgende aandachtspunten c.q. randvoorwaarden een belangrijke rol:

  • Van de applicaties in scope moet een eigenaar bekend zijn en tevens moet functioneel en technisch beheer helder zijn belegd. Deze betrokkenen moeten immers de benodigde documentatie en informatie aanleveren.
  • Beschikbaarheid van up-to-date documentatie zoals beleidsuitgangspunten ten aanzien van autorisatiemanagement, evenals autorisatiematrices en systeemdocumentatie waarin ook het autorisatiemodel van de applicatie wordt beschreven.
  • Beschikbaarstelling van de data, zeker als het systeem of de toepassing is geoutsourcet. Vaak zijn hierover geen afspraken gemaakt in de contracten of service level agreements (SLA).
  • Veel controles maken gebruik van verrijkte data. Het moet dus mogelijk zijn de ‘platte’ autorisatiedata uit een systeem of toepassing te verrijken met hr-data. Ofwel de gebruikersidentiteit moet herleidbaar zijn tot een natuurlijk persoon in hr.
  • Het autorisatieconcept van de toepassing zelf. Maakt de applicatie bijvoorbeeld gebruik van Active Directory-groepen voor de autorisatie of werkt de applicatie met een eigen autorisatiedatabase?

Is uw organisatie ‘in control’ na complianceverificatie?

In principe wel, want de autorisaties zijn nu weer op orde. Om ‘in control’ te blijven is het echter een randvoorwaarde dat de autorisatiemanagementprocessen (aanvraag, goedkeuring, controle) goed zijn ingericht. En dit is nu juist de uitdaging, het complianceverificatieproject is immers niet voor niets gestart. Gedurende het opschonen is het dus van belang dat het autorisatiemanagementproces wordt verbeterd. Dat kan natuurlijk op een procedurele wijze, met daarbij onderstaande nadelen:

  • grote beheerinspanning;
  • risico op verslappen van aandacht voor autorisaties;
  • controle achteraf en dan in het bijzonder ten aanzien van de aangebrachte autorisaties, echter geen controle op het totstandkomingsproces (autorisatiemanagementproces).

Om dus ‘in control’ te blijven is een structurele oplossing nodig die zich richt op:

  1. Herinrichting van autorisatiemanagement op basis van rolgebaseerd autoriseren. Hierbij komen de volgende aspecten aan bod:
    • rolanalyse;
    • rolontwerp;
    • rolmanagement.
  2. Automatiseren van delen van de autorisatiemanagementprocessen. Hierbij ligt een nauwe relatie met het thema Identity & Access Management (IAM). Het verband tussen autorisatiemanagement en IAM wordt aan het slot van dit artikel behandeld.

Herinrichting van autorisatiemanagement, met als uitgangspunt rolgebaseerd autoriseren

Essentie van rolgebaseerd autoriseren is dat een gebruiker geautoriseerd wordt voor toegang tot een object via één of meer rollen. De voordelen van rolgebaseerd autoriseren worden in detail weergegeven in kader 2.

Kader 1. Traditioneel autorisatiemanagement.

Traditioneel autorisatiemanagement

Van oudsher heeft elk IT-systeem en elke applicatie een eigen implementatie voor autorisatiemanagement of, preciezer, toegangscontrole. Dit komt erop neer dat een gebruiker gescheiden accounts heeft op elk systeem dat en elke applicatie die hij gebruikt, elk met hun eigen permissiestructuur en methode om autorisaties toe te wijzen.

Over het algemeen zijn de permissiestructuur en de methode om rechten toe te wijzen in deze traditionele systemen vrij direct ingericht. Een veelgebruikte methode voor autoriseren is een Access Control List (ACL). Autorisaties voor de applicaties en systemen zijn direct gekoppeld aan gebruikers of gebruikersgroepen, zoals is weergegeven in de onderstaande afbeelding.

C-2007-2-Hermans-k2

De permissies die gebruikt worden binnen een applicatie of systeem zijn veelal op een gedetailleerd en technisch niveau.

De (bijna) directe relatie tussen de technische autorisaties en de gebruikers maakt dat het moeilijk is om op een functioneel niveau snel te zien wat een gebruiker daadwerkelijk binnen het systeem of de applicatie kan doen. Hieruit volgt dat het zeer lastig is om de toegang voor gebruikers te beheren.

Het gebrek aan overzicht van de toegangsrechten en de mogelijkheid tot goed beheer van deze rechten binnen organisaties neemt toe met het aantal systemen en applicaties dat in gebruik is. Naast het feit dat het gebruik van meerdere applicaties betekent dat het aantal permissies toeneemt en het aantal toewijzingsmethoden dat begrepen en geanalyseerd moet worden groter wordt, gaat het bestaan van meerdere accounts per gebruiker ook een rol spelen.

Verschillende systemen hebben verschillende regels, beperkingen of simpelweg ander beleid voor het aanmaken van accountnamen, wat betekent dat een gebruiker bij verschillende systemen bekend is onder verschillende accounts. Deze situatie wordt hieronder weergegeven.

C-2007-2-Hermans-k3

De volgende stappen moeten worden ondernomen om een overzicht te krijgen van de rechten die een gebruiker heeft op de IT-resources van een organisatie:

  • Stel vast welke accounts een gebruiker heeft op alle systemen waar hij toegangsrechten bezit. Dit kan een ‘kip en ei’-probleem opleveren, omdat een gebruiker over het algemeen toegang heeft tot systemen waarop hij een account heeft.
  • Bepaal welke (technische) permissies de gebruiker heeft binnen elk systeem, gebruikmakend van alle gebruikersaccounts.
  • Onderzoek wat de gebruiker op functioneel (business) niveau daadwerkelijk kan doen met de permissies die hij bezit.

Het doorlopen van deze stappen kan een behoorlijke uitdaging zijn. Het beheren van toegang (door de bovenstaande stappen in omgekeerde volgorde te behandelen) is nog lastiger.

Kader 2. Rolgebaseerd autorisatiemanagement.

Rolgebaseerd autorisatiemanagement (Role Based Access Control)

Zoals de naam doet vermoeden, spelen rollen een belangrijke rol binnen Role Based Access Control (RBAC). RBAC-rollen bevinden zich tussen de permissies en de gebruikers, en hebben zowel een functie bij het organiseren als bij het koppelen van deze niveaus. Dit wordt hieronder afgebeeld.

C-2007-2-Hermans-k4

Binnen dit model is een permissie een recht om een zekere actie op een bepaald (type) object te voltooien. De permissies zijn samengevoegd in rollen. De rollen worden toegewezen aan gebruikers. Zodra dit gebeurt, zijn de permissies binnen die rol ook beschikbaar voor de gebruiker.

Hoewel rollen slechts een kleine toevoeging lijken te zijn aan de traditionele autorisatiemanagementoplossingen, zijn ze wel degelijk een belangrijke factor in het verplaatsen van autorisatiemanagement naar het businessniveau. Een aantal redenen is hiervoor te geven, waaronder:

  • Een enkele rol kan permissies voor meerdere systemen of applicaties bevatten. Rollen overstijgen daardoor de grenzen van die systemen en applicaties. In traditionele autorisatiemanagementoplossingen compliceren deze grenzen het verkrijgen van een overzicht van en grip op permissies van gebruikers.
  • Aan rollen kunnen namen worden gegeven die betekenisvol zijn voor de business, en rollen zijn op deze manier ook te relateren aan businessconcepten. Bijvoorbeeld, als bepaalde permissies worden toegekend aan medewerkers met een bepaalde functie binnen de organisatie, dan kunnen die permissies worden gegroepeerd in een rol die de naam draagt van die functie. De permissies worden dan toegekend aan de betrokken medewerkers in die functie door hen die rol te geven. Ook mogelijk is dat sommige permissies toegekend worden aan alle medewerkers. In een dergelijk geval kan er een rol worden gemaakt met de naam ‘Medewerker’ die wordt toegekend aan alle medewerkers.

    Het kunnen geven van betekenisvolle namen aan rollen is een belangrijk voordeel. Immers, in de huidige situatie wordt het verantwoordelijke management vaak geconfronteerd met allerlei technische benamingen van autorisatieprofielen, welke voor hem eigenlijk geen betekenis hebben. Hierdoor kan hij geen verantwoordelijkheid nemen ten aanzien van autorisatiemanagement.
  • Rollen ondersteunen situaties met meerdere abstractieniveaus van permissies door gebruik te maken van rolovererving. Door rolovererving kunnen rollen die permissies bevatten zelf ook gecombineerd worden tot abstractere rollen.

    Stel bijvoorbeeld dat een organisatie applicatie-eigenaren heeft die over gedetailleerde kennis beschikken van de technische permissies binnen hun applicaties. Deze applicatie-eigenaren kunnen deze technische permissies groeperen in rollen, waarbij elke rol de permissies bevat die nodig zijn om een bepaalde taak binnen de applicatie uit te voeren. Een lijnmanager kan deze applicatierollen combineren, om zo tot rollen op een hoger niveau te komen. Elk van deze laatste rollen kan overeenkomen met een businessfunctie.
  • Rollen vormen een basis voor het implementeren van bepaalde beleidsregels, zoals functiescheidingen. Een beleidsregel die stelt dat twee taken of functies niet toegekend mogen worden aan dezelfde werknemer, kan vertaald worden naar een RBAC-regel die ervoor zorgt dat de betrokken rollen niet aan dezelfde gebruiker worden toegekend.

De levenscyclus van rollen

Een rol is allesbehalve statisch te noemen. Aangezien een organisatie en haar ‘business’ aan verandering onderhevig zijn, geldt dit ook voor autorisaties en bijbehorende rollen. Hierbij is het van belang te zoeken naar een goede balans tussen hoeveelheid rollen en benodigde rolwijzigingen. Om een dergelijk proces goed in te kunnen richten, is het om te beginnen belangrijk de levenscyclus van rollen te onderkennen. Deze wordt weergegeven in figuur 3.

C-2007-2-Hermans-3

Figuur 3. Levenscyclus van rollen.

De levenscyclus van rollen bevat drie fasen:

  • Rolanalyse. Tijdens de rolanalyse worden de rollen geïdentificeerd die binnen de organisatie kunnen worden onderkend. De rollen worden geïdentificeerd op basis van onder meer beleidsdocumenten, de organisatiestructuur, bedrijfsprocessen en functieomschrijvingen.
  • Rolontwerp. Tijdens het rolontwerp worden de rollen geïdentificeerd zoals deze zijn geïmplementeerd in de geautomatiseerde systemen. Op basis van de rolanalyse en het onderzoek naar de rollen in de geautomatiseerde systemen wordt een nieuw ontwerp voor rollen ontwikkeld, dat wordt vastgelegd in een zogenoemde rolcatalogus.
  • Rolmanagement. Rolmanagement omvat de processen voor het management van rollen, zoals aanvraag, aanmaak, activering, intrekking en schorsing alsmede het doorvoeren van wijzigingen in rollen als gevolg van bijvoorbeeld wijziging van organisatiestructuren, wet- en regelgeving of IT-omgeving.

Rolanalyse en -ontwerp

Om te komen van een bestaand autorisatiemodel naar een op rollen gebaseerd autorisatiemodel zijn twee aanpakken mogelijk, te weten ([Mien05]):

  • Top-down rolontwerp, een veelal meer strategisch georiënteerde aanpak. Hierbij wordt vanuit informatiebeleid, IT-governance en bijbehorende processen (ofwel de administratieve organisatie) bepaald welke autorisaties bij welke rollen zouden moeten horen. Uitdaging hierbij is dat IT-governance in de praktijk eveneens sterk in ontwikkeling is en nog tijd nodig heeft om tot volle wasdom te komen door alle veranderingen die het in ontwikkeling zijn met zich meebrengt.
  • Bottom-up rolontwerp, een veelal meer operationeel georiënteerde aanpak. Hierbij worden op basis van bestaande autorisaties binnen geselecteerde objecten op een geautomatiseerde wijze rollen gedestilleerd. Hiertoe zijn reeds diverse tools beschikbaar, alhoewel de markt van dergelijke tools nog erg in ontwikkeling is. Een uitdaging hierbij is daarom vooral het vertalen van de uitkomsten van deze technische analyse naar voor objecteigenaren begrijpelijke uitkomsten.

In werkelijkheid zullen deze aanpakken worden gecombineerd, waarbij bottom-up rolengineering zal worden uitgevoerd met gebruik van geautomatiseerde tools, waarna deze IT-rollen gecombineerd zullen worden tot businessrollen met gebruik van de top-downaanpak.

Om te kunnen beginnen met het bottom-up rolontwerp met gebruikmaking van geautomatiseerde rapportages en analysetools, is het nodig dat de data die zullen worden geanalyseerd bij het rolminingproces voldoen aan bepaalde kwaliteitscriteria. Gebaseerd op zowel de eerste analyse van de datakwaliteit als de rapporten over de verleende permissies naar de betrokken stakeholders worden de bestaande autorisaties geschoond. Na het bereiken van het benodigde kwaliteitsniveau wordt het geautomatiseerde rolminingproces gestart, gecombineerd met de top-down rolengineering van de resultaten uit de stap waarbij de rolminingactiviteiten worden omgezet naar businessrollen.

Nadat deze schoningsactiviteiten hebben geleid tot autorisatiedata van het vereiste kwaliteitsniveau, kan het proces van rolmining en rolengineering van start gaan. Rolmining wordt gebruikt voor het ontdekken van IT- of systeemrollen en rolengineering wordt gebruikt voor het creëren van businessrollen (ofwel het combineren van IT- of systeemrollen tot betekenisvolle businessrollen).

Het verschil tussen businessrollen en IT- of systeemrollen wordt weergegeven in figuur 4.

C-2007-2-Hermans-4

Figuur 4. Verschil tussen businessrollen en systeemrollen.

In autorisatiemanagement maken we een onderscheid tussen:

  • Permissieniveau. Dit is het laagste en meest grove niveau binnen de autorisatiemanagementaanpak. De permissies van deze aanpak zijn gekoppeld aan groepen, profielen of gelijkwaardige gebruikerscontainers in de beheerde applicaties.
  • IT- of systeemrollen. Bevatten veelal permissies die nodig zijn om een bepaalde businesstaak uit te voeren. Bedenk dat IT- of systeemrollen permissies kunnen bevatten van één of meer applicaties.
  • Businessrollen. Komen overeen met businessfuncties of zelfs businessrollen, en worden gecreëerd door het combineren van de daarvoor benodigde systeemrollen (de businesstaken).

Opgemerkt moet worden dat het mogelijk is meerdere niveaus van de zojuist genoemde businessrollen toe te voegen. Op deze manier wordt een businessrolhiërarchie gecreëerd. In de praktijk is het aantal omgevingen waarin dit noodzakelijk of praktisch is, vrij beperkt.

Met betrekking tot de autorisatiemanagementaanpak kunnen de volgende taken worden geïdentificeerd:

  1. Rolmining met behulp van een geautomatiseerde rolminingtool:
    • het identificeren en creëren van permissies;
    • het samenstellen van systeemrollen.
  2. Het samenstellen van businessrollen via een top-downaanpak.
  3. Het implementeren en toepassen van beleidsregels (zoals functiescheidingen en rolactivatie gebaseerd op zogenaamde ‘rules’). Deze regels kunnen per rol worden aangegeven.

Rolmanagement

Een rol is een generieke term voor het groeperen van toegangsrechten die benodigd zijn voor het uitvoeren van taken door de gebruiker. In veel gevallen zijn deze taken direct gerelateerd aan de activiteiten die deze persoon uitvoert in een proces, een project of zijn of haar organisatorische eenheid.

Om te garanderen dat het ontwikkelen en managen van rollen volgens een consistent en uniform proces verloopt, is het belangrijk om rolmanagement in de organisatie te verankeren.

Rolmanagement bevat wijzigingsbeheer voor de roldefinities, gebaseerd op het managementbeleid. De coördinator van dit proces is de tactische rolmanager. De rol van de tactische rolmanager en de betrokken partijen en processen zijn getoond in figuur 5.

C-2007-2-Hermans-5

Figuur 5. Overzicht tactisch rolmanagement.

Het proces van het toewijzen van rollen aan gebruikers maakt geen deel uit van rolmanagement.

De uitkomst van het rolmanagementproces bestaat uit de definitie van de rollen. Deze definities kunnen worden opgeslagen in de autorisatiemanagementinfrastructuur.

Het beleid voor rolmanagement bevat met name een beschrijving van hoe de governancestructuur moet zijn met daarbij diverse rollen en verantwoordelijkheden van de betrokken functionarissen. Hierbij kan een zogenaamd RACI-schema worden gehanteerd (zie tabel 4).

C-2007-2-Hermans-t4

Tabel 4. RACI-matrix behorende bij rolmanagement.

Automatiseren van delen van de autorisatiemanagementprocessen

Teneinde een te onderhouden autorisatiemodel gebaseerd op rollen te verkrijgen, verdient het de voorkeur om de uitkomsten van rolanalyse en -ontwerp vast te leggen in een daarvoor ontworpen geautomatiseerd systeem. Hier geldt de anekdote ‘boekhouding kun je natuurlijk op papier doen, met een geautomatiseerd systeem is het toch wel wat efficiënter’.

Naast dat enerzijds de roldefinities zullen worden vastgelegd in een geautomatiseerde administratie, zullen daarin anderzijds ook aspecten worden opgenomen als welke groep functionarissen welke rollen mag toedelen, alsmede condities en voorwaarden waaronder een rol mag worden toebedeeld.

Rolgebaseerd autorisatiemanagement en IAM

In [Herm06] wordt een toelichting gegeven op een integrale set van processen die tezamen IAM wordt genoemd. Naast autorisatiemanagement, dat in dit artikel centraal staat, bestaat IAM uit een viertal andere processen. In figuur 6 worden deze (nogmaals) weergegeven. Naast de drijfveer ‘compliance’ en dientengevolge benodigde ‘verification’ is algehele procesverbetering (‘operational excellence’) een nimmer verdwijnend thema binnen organisaties. Het valt dan ook aan te bevelen om de inspanningen rondom autorisatiemanagement hand in hand te laten gaan met verbeteringen in de andere IAM-processen. Zo kunnen bijvoorbeeld aanvraagprocessen voor autorisaties alsmede het doorzetten van gewenste autorisaties (provisioning) richting objecten worden geautomatiseerd. Deze vorm van procesoptimalisatie wordt door veel organisaties uitgevoerd binnen een specifiek IAM- of algeheel security-verbeteringsprogramma.

Het verdient hierbij aanbeveling om autorisatiemanagement niet alleen in perspectief te zien met gerelateerde processen maar eveneens benodigde verbeteringen stap voor stap te realiseren (evolutie in plaats van revolutie).

C-2007-2-Hermans-6

Figuur 6. Overzicht IAM-processen. [Klik hier voor grotere afbeelding]

Kader 3. Resultaten van de herinrichting van autorisatiemanagement.

Resultaat van de herinrichting van autorisatiemanagement

  • Er is altijd een up-to-date inzicht in de autorisaties van medewerkers.
  • Een efficiënte en effectieve migratie naar het rolgebaseerd autorisatiemodel.
  • De huidige gewenste situatie is vastgelegd in het autorisatiesysteem.
  • De huidige situatie komt overeen met de gewenste situatie.
  • De efficiëntie kan worden verhoogd door gebruik te maken van analytische tools.
  • De transparantie, het onderhouden, de effectiviteit en de verificatiemogelijkheden worden verbeterd.
  • Autorisatiemanagement is aantoonbaar ‘in control’.
  • Door autorisatiemanagement nadrukkelijk in verband te brengen met (bestaande) inspanningen op het gebied van IAM kan er verdere ‘operational excellence’ worden behaald.

Kader 4. Aandachtspunten voor herinrichting van autorisatiemanagement.

Aandachtspunten bij herinrichting van autorisatiemanagement

Rolmining

  • Automatische rolmining heeft alleen succes als de te minen data voldoen aan de vereiste kwaliteitscriteria.

Rolengineering

  • Te veel variatie in rollen – de implementatie van een autorisatiemodel dat gebaseerd is op rollen is bedoeld om het aantal administratieactiviteiten te verkleinen door te standaardiseren. Om het aantal (variaties in) rollen te beperken, is het mogelijk contextafhankelijkheid onderdeel te laten uitmaken van het rolontwerp.
  • Een mogelijk probleem dat vaak wordt genoemd in relatie tot de implementatie van RBAC-oplossingen is rolexplosie of rolproliferatie. Rolexplosie kan voorkomen in een situatie waarbij een zeer groot en vrijwel onbeheersbaar aantal rollen moet worden gemaakt om alle permissies in de IT-omgeving te omvatten. Een nadere analyse van de oorzaken die hieraan ten grondslag liggen geeft vaak weer dat meestal te veel op elkaar lijkende permissies in gebruik zijn; ook wel omschreven als permissie-explosie.
  • Normaal gesproken zijn de verschillen tussen permissies min of meer direct te relateren aan de context waarin ze gebruikt worden. Bijvoorbeeld, in een organisatie waarin iedere divisie haar eigen fileshare op het netwerk heeft, moet men vaak een aparte permissie aanmaken voor iedere fileshare, en dus voor elke divisie. Bovendien is het nodig om een aparte rol voor elke divisie aan te maken die de filesharepermissie voor de divisie in kwestie bevat.
  • Soortgelijke voorbeelden kunnen worden gegeven voor organisaties (of divisies) met meerdere geografische locaties, medewerkers met verschillende niveaus van senioriteit, enz.

Om dit probleem te verhelpen kan het concept van zogenaamde Context-Sensitive Permissions (CSP’s) worden overwogen. CSP’s kunnen dienen als permissiesjablonen die velden voor contextinformatie kunnen bevatten.

Contextinformatie kan een eigenschap zijn van:

  • de applicatie waarvoor de permissie is gedefinieerd;
  • de rollen waarin de permissie is gevat;
  • de organisatorische eenheid en gebruikers aan wie de rollen worden toegewezen.

Wanneer een CSP daadwerkelijk wordt toegekend aan een gebruiker (door toekenning of activering van een rol die de CSP bevat) wordt de permissie voor die gebruiker aangemaakt door de relevante eigenschappen op te halen en ze te gebruiken om het sjabloon in te vullen. De afbeelding hieronder laat dat zien.

C-2007-2-Hermans-k5

Als de CSP wordt gekoppeld aan een andere gebruiker, wordt mogelijk een verschillende permissie aangemaakt. Dit zou het geval kunnen zijn als de tweede gebruiker lid is van een andere organisatorische eenheid en de CSP velden bevat voor eigenschappen van organisatorische eenheden. Door dit mechanisme is het niet nodig om handmatig meerdere permissies of rollen toe te wijzen om verschillende toegangsrechten toe te kennen.

Dit maakt Context Sensitive Permissions een zeer krachtige tool om rolexplosie tegen te gaan.

Conclusie

Het krijgen en houden van grip op autorisatiemanagement is van belang voor organisaties. Enerzijds vanuit overwegingen te maken vanuit compliancevereisten, anderzijds vanuit het perspectief van het realiseren van procesverbeteringen (efficiëntie en effectiviteit). Het verdient daarom aanbeveling het beheerproces rondom autorisaties stap voor stap te verbeteren door gebruik te maken van het concept ‘rolgebaseerd autoriseren’. Voordeel van het complianceperspectief is dat de aantoonbaarheid van wie toegang heeft tot welke data kan worden vergemakkelijkt.

Echter, invoering van rolgebaseerd autoriseren is bepaald geen sinecure. Waar te beginnen? Welke applicaties eerst, welke kunnen wachten? Hoeveel rollen heb ik eigenlijk nodig? Kritieke succesfactor daarom is vooral het bewandelen van ‘de weg van geleidelijkheid’. Hierbij dient een strategische aanpak te worden gecombineerd met een meer operationele. Ofwel beleid en IT-governance als kaderstelling versus concreet per applicatie bekijken welke autorisaties zijn er nu eigenlijk toebedeeld aan mensen en horen die autorisaties er wel te zijn?

Ten slotte is het raadzaam autorisatiemanagement te bezien vanuit het bredere raamwerk van IAM-processen. Tezamen zullen deze uw organisatie stap voor stap aantoonbaar ‘in control’ brengen en houden!

Literatuur

[Herm06] Ing. J.A.M. Hermans RE, drs. D.B. van Ham CISA en drs. J. ter Hart, Globalisering en de complexiteit van logische toegang: nut en noodzaak van een strategie op het gebied van Identity & Access Management (IAM), Compact 2006/3.

[Herm05] Ing. J.A.M. Hermans RE en drs. J. ter Hart, Identity & Access Management: operational excellence of ‘in control’?, Compact 2005/3.

[Koor04] Drs. ing. R.F. Koorn RE en ing. J.A.M. Hermans RE, Identity Management: hoe (on)toereikend is het nu en hoe kan het beter?, Compact 2004/2.

[KPMG06] KPMG IT Advisory, Onderzoek informatiebeveiliging: zes belangrijke signalen uit de praktijk, 2006.

[Mien05] Ing. P. Mienes RE, De (harde) praktijk van role engineering, Compact 2005/3.

[Pone07] The Ponemon Institute, Survey on Identity Compliance, 1 March 2007.

De spagaat van internationale complianceprojecten

Stelt u zich eens voor dat u als projectverantwoordelijke een door corporate geïnitieerd internationaal project dient te managen waarvan de bedrijfsonderdelen het nut initieel niet inzien en het vooral zien als een instrument van corporate om meer invloed uit te oefenen dan nodig, terwijl u bij voorbaat al kwaliteitsconcessies moet doen vanwege tijdsdruk. Een project gedoemd om te mislukken. Toch is dit vaak de omgeving waarin projecten als Sarbanes-Oxley of Tabaksblat uitgevoerd dienen te worden (of reeds zijn uitgevoerd) en waarbij falen eigenlijk geen optie is. In dit artikel wordt van een tweejarig internationaal complianceproject binnen DSM aangegeven wat de succesfactoren waren en wat beter had gekund. Het artikel is ook relevant voor organisaties die de eerste stappen op het gebied van Sarbanes-Oxley hebben gezet en nu druk doende zijn om of de ‘total costs of compliance’ te verlagen of om in de slipstream van de complianceboodschap processtandaardisatie- of -verbetering door te voeren.[De auteurs bedanken de heer R. van Beekum (DSM Corporate Risk Management) voor zijn bijdrage aan dit artikel.]

Inleiding

Doel van dit artikel is de lezer inzicht te geven in de succesfactoren van een internationaal complianceproject en handvatten te bieden voor een succesvolle, door corporate gedreven uitvoering ervan. Daarbij is de te hanteren projectstijl de meest kritische succesfactor. Dit is vooral van belang omdat de implementatie van de corporatestrategie steeds vaker door middel van projecten wordt gerealiseerd ([Donk05]).

Complexe internationale projecten

Complexe internationale projecten worden in dit artikel gedefinieerd als projecten die vanuit de holding worden geïnitieerd en op internationale schaal worden uitgevoerd in de verschillende bedrijfsonderdelen (divisies, businessunits). Internationaal betekent in dit artikel dat de bedrijfsonderdelen divers zijn in markten, producten en technologieën, regionaal gespreid (afstand tot de holding) en verschillend in volwassenheid met betrekking tot het onderwerp van het project. De complexiteit refereert aan de verhouding tussen corporate en de bedrijfsonderdelen en de eisen aan de projectbeheersing. De volgende projecten zijn voorbeelden van complexe internationale projecten:

  • wereldwijde complianceprojecten, met als doel om te voldoen aan wetgeving zoals Sarbanes-Oxley;
  • concernbrede standaardisatie en harmonisatie van bedrijfsprocessen in het kader van ‘operational excellence’ en/of met als doel processen te centraliseren in shared service centra;
  • het wereldwijd uitrollen van een standaardinformatiesysteem, met als doel de uitvoering van de processen en/of de procesbeheersing te verbeteren en/of het applicatielandschap te rationaliseren;
  • special focus-projecten, met als doel om bijvoorbeeld wereldwijd de inkoopkosten terug te brengen, de winstgevendheid te verbeteren of de personeelsomvang te reduceren;
  • het wereldwijd uitrollen van een standaard technische infrastructuur, zoals bijvoorbeeld een standaard-desktop, waardoor deze remote kan worden beheerd;
  • het collectief veranderen van gedrag, bijvoorbeeld op het gebied van veiligheid, onderling respect, innovatie, compliance of klantbewustzijn. De implementatie van organisatiespecifieke, expliciet vastgelegde en gecommuniceerde ‘waarden’ van de organisatie staat daarin vaak centraal.

Bovenstaande projecten kunnen verschillen in de omvang van de organisatie die ‘geraakt’ moet worden en de diepgang van de verandering die tot stand moet worden gebracht. Dit zijn belangrijke factoren bij het kiezen van de juiste projectstijl.

Spanningsveld van corporateprojecten

Waarom leveren corporate projecten spanning op, en waarom geldt dat voor complianceprojecten in het bijzonder?

  • Corporate wenst invloed uit te oefenen op het reilen en zeilen van de bedrijfsonderdelen. In elke hiërarchische relatie zal, zodra een meerdere zich bemoeit met een ondergeschikte, de ondergeschikte zich minder direct verantwoordelijk voelen voor het eindresultaat. Hij/zij is namelijk niet zelf volledig in staat het eindresultaat te bepalen. Zo werkt het ook in de verhouding tussen de holding en de afzonderlijke bedrijfsonderdelen. Zodra de holding zich gaat bemoeien met de ‘business’, dan voelt het management van de onderliggende bedrijfsonderdelen zich minder verantwoordelijk voor het eindresultaat.
  • De toegevoegde waarde van compliance staat ter discussie, er zijn vaak geen directe baten te verbinden aan het voldoen aan regels en wetten. Zeker het voldoen aan Sarbanes-Oxley en Tabaksblat wordt vaak negatief in verband gebracht met de bedrijfsprestaties en het innoverend vermogen ([HFD04]).
  • Compliancewetgeving is gelijk voor elk bedrijfsonderdeel, vaak onafhankelijk van geografische locatie. Daarnaast maken complianceregels geen onderscheid tussen bedrijfsonderdelen die qua levenscyclus in een oogstfase of in een consolidatiefase zitten. Ook voor het volwassenheidsniveau van een unit op het gebied van interne controle maken de regels geen onderscheid. Dit betekent dat een gelijke set van regels voor diverse typen units moet worden geïmplementeerd.
  • De wet, zoals Sarbanes-Oxley, stelt de deadline vast waarop het ‘project’ dient te zijn afgerond. Daardoor kan vaak niet gekozen worden voor de optimale oplossing. Zo hebben veel organisaties als primair doel gesteld om eerst, kost wat kost, compliant te worden en pas daarna ‘het compliant zijn en blijven’ te optimaliseren. Ook wordt de scope van de complianceprojecten in beginsel vaak zo nauw mogelijk gedefinieerd, al was het bijvoorbeeld efficiënter geweest om naast de beheersing van de financiële rapportageprocessen ook meteen meer beheersing in de logistieke processen te realiseren.

Verderop in dit artikel zal worden aangegeven welke invloed de afstemming van projectaanpak en projectmanagementstijl heeft op de mate waarin de spanning oploopt.

Corporate-projectstijl: ‘push’ of ‘pull’

Een holdingorganisatie kan op meerdere wijzen invloed uitoefenen op de afzonderlijke bedrijfsonderdelen om de corporatestrategie te realiseren. Invloed uitoefenen door de holding op bedrijfsonderdelen (of, meer in het algemeen, van meerderen op ondergeschikten) kan volgens Merchant ([Merch03]) door middel van een mix van vier typen controlesystemen:

  1. Resultaatgericht. De holding vereist van de onderliggende units dat er een bepaald resultaat wordt gehaald. Het hoe staat niet ter discussie. De gewenste formeel overeengekomen resultaten kunnen financieel of niet financieel van aard zijn en worden door middel van kritische prestatie-indicatoren gecommuniceerd. Het gebruik van balanced scorecards om de performance te monitoren en te rapporteren is een bekend instrument. Het voordeel is dat de onderliggende units zelf verantwoordelijkheid kunnen nemen voor hoe zij de doelstellingen wensen te realiseren.
  2. Actiegericht. De holding schrijft voor hoe bepaalde activiteiten dienen te worden uitgevoerd. Denk aan procedures, richtlijnen, beleid maar ook voorgeconfigureerde informatiesystemen met applicatiecontroles en autorisaties. Het resultaat staat niet centraal, maar de wijze van uitvoering (het hoe) wel.
  3. Persoonsgericht. Door middel van werving en selectie, job rotation en vergaande training wordt gerealiseerd dat de juiste man/vrouw op de juiste plek terecht komt en dat hij/zij ervoor zorgt dat de gewenste plannen worden uitgevoerd, niet alleen qua inhoud en kennis maar ook qua vaardigheden en stijl.
  4. Cultuurgericht. Een omgeving wordt gerealiseerd, waarin door waarden en normen een gewenst gedrag wordt afgedwongen. Dit kan door de stijl van het management desgewenst te veranderen door correctief op te treden bij ongewenst gedrag, gewenst gedrag te stimuleren en te belonen, en bijvoorbeeld teamprestaties expliciet te waarderen.

De zojuist genoemde controlesystemen kan men ook projecteren op de aanpak van corporateprojecten zoals die vanuit een centraal Project Management Office (hierna PMO) ([Donk02]) kunnen worden geïnitieerd. De resultaat- en de actiegerichte projectaanpak zijn bij corporateprojecten de meest voorkomende typen.

Bij de resultaatgerichte aanpak zal de holding slechts het gewenste resultaat en tijdstip van realisatie noemen en zal zij de realisatiewijze grotendeels aan de bedrijfsonderdelen overlaten, inclusief de inhuur van derden en de keuze van de procesinrichting, de bijbehorende informatiesystemen en de te gebruiken tools. Natuurlijk maakt de holding wel vooraf de consequenties duidelijk bij het niet of niet tijdig realiseren van de doelstellingen. De holding stelt dan mogelijk centraal budget beschikbaar en op basis van de plannen van de afzonderlijke bedrijfsonderdelen beslist het PMO of er wel of geen geld gegeven wordt. De organisatieonderdelen met de plannen die het meest aansluiten bij de wensen van de holding krijgen de grootste financiële ondersteuning. Het PMO heeft bij een dergelijke aanpak primair een coördinerende rol: het beoordeelt de plannen en toetst de uitvoering. De volgens deze aanpak uitgevoerde projecten worden in dit artikel ‘pull’-projecten genoemd, omdat de holding aan de organisatieonderdelen ‘trekt’ om te komen met een aanpak die ze zelf wenselijk acht.

De andere mogelijkheid is dat de centrale organisatie zelf een zware projectorganisatie optuigt en de bedrijfsonderdelen langs gaat om het project uit te voeren. Van de bedrijfsonderdelen wordt dan verwacht dat zij tijd en resources vrijmaken en actief participeren. Dit type projecten wordt in dit artikel ‘push’-projecten genoemd, aangezien de centrale organisatie op basis van haar prioriteiten, resourceplanning en wensen bepaalt wanneer het organisatieonderdeel aan de beurt is, hoe het project wordt uitgevoerd en wat van haar wordt verwacht. In een puur ‘push’-project neemt de holding de verantwoordelijkheid van het resultaat van het project over van de afzonderlijke bedrijfsonderdelen. Pure ‘push’-projecten zijn bijvoorbeeld infrastructurele projecten op het gebied van standaard-desktop.

Beide controlesystemen (resultaat, acties) hebben hun specifieke neveneffecten. Bekende neveneffecten van een ‘internationale’ resultaatgebaseerde projectaanpak (‘pull’) zijn:

  • Controllability principle. Indien projectmanagers worden beoordeeld op de projectresultaten van een onderdeel, terwijl ze niet alle aspecten binnen dat onderdeel die van invloed zijn op de projectvoortgang kunnen beïnvloeden, kan risicoavers gedrag worden gestimuleerd. Dit wordt ook wel het ‘controllability principle’ genoemd. Dit neveneffect kan optreden zodra een projectmanager in zijn resultaat afhankelijk wordt van bijvoorbeeld de medewerking van de leiding van een bedrijfsonderdeel, zonder dat hij/zij mandaat heeft haar te corrigeren.
  • Negatieve houding. Indien de relatie tussen het resultaat en de beloning onduidelijk is, kan dit tot frustraties leiden, wat een negatieve houding van de projectmanagers tot gevolg kan hebben en/of kan leiden tot ongewenst handelen.
  • Suboptimalisatie. Dit is een neveneffect dat valt onder de term ‘behavioral displacement’. De projectmanager streeft dan naar het maximale voor zijn eigen verantwoordelijkheidsgebied en niet voor dat van de gehele organisatie. Dit verschijnsel kan optreden bij projecten waarbij de projectverantwoordelijkheid bijvoorbeeld ligt op het niveau van de afzonderlijke bedrijfsonderdelen, hetgeen bij ‘pull’-projecten vaak het geval is. De projectmanagers per onderdeel kunnen dan beslissingen nemen die beter zijn voor hun eigen onderdeel dan voor de gehele organisatie, of kunnen het delen van best practices achterwege laten.

Aan projecten die sterk ‘push’-gericht zijn, ligt vaak een gedetailleerd ‘roll-out script’ ten grondslag. Hierin staat exact beschreven wie wat wanneer en op welke wijze moet opleveren. Bekende neveneffecten van een ‘internationale’ actiegerichte projectaanpak (‘push’) zijn:

  • Afstompen/inflexibiliteit. De corporate-projectmanager blijft vasthouden aan de projectaanpak, wars van lokale omstandigheden. Door het hoge actievoorschrijvende gehalte (procedures, instructies, plannen) wordt de creativiteit, het ‘out of the box’ denken afgestompt. Ook bij veranderende omstandigheden is de projectmanager of werkgroepleider niet in staat zich aan te passen. Omdat bij internationale projecten de bedrijfsonderdelen vaak veel van elkaar verschillen, kan dit neveneffect zeer nadelige gevolgen hebben voor het uiteindelijke resultaat.
  • Frustratie. Dit verschijnsel treedt op indien niet wordt begrepen waarom het project op deze wijze, met deze acties, wordt uitgerold. Het kan optreden bij de mensen in de bedrijfsonderdelen, maar ook bij de projectmedewerkers. In het laatste geval komt de frustratie voort uit het onvermogen zelf invloed te kunnen uitoefenen en eigen verantwoordelijkheid te kunnen nemen.
  • Vertraging. Indien in het project veel procedures moeten worden geïmplementeerd en verplichte besluiten moeten worden genomen, dan wordt het project gauw ‘stroperig’. Het ‘push’-project is zelf vaak ook aan sterke actiegerichte controls onderworpen. Wanneer het dan vertakt is over vele bedrijfsonderdelen kan een stroperige projectorganisatie voor veel vertraging zorgen. Zeker indien in een internationaal project bepaalde beslissingen alleen centraal mogen worden genomen.

Projectorganisatie voor ‘push’- en ‘pull’-projecten

Tabel 1 geeft op hoog niveau inzicht in de verschillen tussen ‘push’-, ‘pull’- en persoons/cultuurgerichte projecten. Elk project zal van alle drie systemen gebruikmaken, echter de accenten zullen verschillen.

C-2007-1-Vreeke-t1

Tabel 1. Verschillen tussen ‘push’- en ‘pull’-projecten. [Klik hier voor grotere afbeelding]

De keuze voor een ‘push’- of ‘pull’-aanpak zal leiden tot een ander type projectorganisatie. Ook zonder omvangrijk onderzoek te doen kan men inzien dat bij de organisaties die een ‘push’-aanpak kiezen het PMO ook de rol van ‘conflictmanagement’ zal moeten vervullen. Daar waar de organisatie kiest voor een ‘pull’-aanpak zal ‘consequentiemanagement’ één van zijn belangrijkste taken zijn. In beide gevallen zal de programmamanager van de Raad van Bestuur voldoende mandaat moeten krijgen om de bijbehorende rol te kunnen uitoefenen. Om zorg te dragen dat de wijze van uitrol niet tot onnodige weerstand leidt, zullen bij ‘push’-gerichte projecten ook deelnemers vanuit de onderliggende bedrijfsonderdelen in de stuurgroep vertegenwoordigd moeten zijn. Ze kunnen dan in een vroeg stadium meebeslissen over de wijze en timing van de uitrol. Commitment wordt dan via de formele besluitvormingsweg georganiseerd.

C-2007-1-Vreeke-t2

Tabel 2. Verschillen in de projectorganisatie bij ‘push’- en ‘pull’-projecten. [Klik hier voor grotere afbeelding]

De ‘push’- en ‘pull’-projecten kunnen op een continuüm worden geplaatst. Het internationale complianceproject van DSM, dat centraal staat in dit artikel, heeft de gulden middenweg bewandeld.

De spagaat van complianceprojecten

Doordat de wetgeving (1) de persoonlijke aansprakelijkheid van bestuurders raakt en (2) een harde deadline kent, hebben veel organisaties bewust een zodanige keuze gemaakt inzake de corporate-projectaanpak en de te installeren controls, dat deze niet de optimale zullen zijn voor de lange termijn. Die, door de spagaat tussen wat moet en wat wenselijk is, afgedwongen keuze leidt vaak tot:

  • een sterke ‘push’-aanpak van projecten;
  • suboptimalisatie in de ‘total costs of compliance’;
  • diversiteit in het gebruik van ondersteunende tools;
  • beperkte diepgang en reikwijdte van de controls
De ‘push’-aanpak van complianceprojecten

Vanuit risicomijdend oogpunt en gelet op de inhoud van de wet en codes hebben veel organisaties gekozen voor een zeer sterke ‘push’-benadering met een sterk instrumenteel karakter. ‘Push’-projecten hebben, zoals hierboven geschetst, als nadeel dat zij dwingend van aard zijn en weinig rekening kunnen houden met lokale omstandigheden. Het voordeel is dat er meer projectbeheersing is en dat centraal het tempo en het consistente eindresultaat worden bepaald. Om grip te houden wordt het standaard-implementatieplan verheven tot wet en staan het gewenste resultaat en de implementatiewijze vooraf vast. Het is echter geen geheim dat de effectiviteit van maatregelen, zoals het invoeren of wijzigen van procedures, bepaald wordt door de mensen die ze uitvoeren. En het is ook de mens die besluit gebruik te maken van achterdeuren of ‘work arounds’ bij geautomatiseerde controls. Daarnaast is het de mens die bewust of onbewust afwijkend gedrag vertoont of fouten maakt. Fouten op basis van zijn eigen tekortkoming of door tekortkomingen (zichtbaar of latent) in de omgeving waarin hij acteert. In een complianceproject moet je de factor ‘mens’, vaak via de bedrijfscultuur, raken wil je toekomstvast ‘compliant’ blijven. Kaptein en Klamer ([Kapt04]) geven in hun artikel ‘De implementatie van bedrijfscodes in Nederland’ aan dat zowel Enron als Worldcom beschikte over ‘een voortreffelijk geschreven bedrijfscode’. Maar het raken van de mens lukt via ‘pull’-projecten ontegenzeggelijk beter, omdat daar de wijze van uitvoering lokaal kan worden ingevuld en daarom lokaal beter kan worden aangesloten bij de geldende normen en waarden. Ook kan het verbeteren van de werkomgeving waarin het individu acteert in scope van het project worden genomen. De ‘pull’-aanpak is vele malen flexibeler én door het kunnen nemen van de eigen verantwoordelijkheid neemt de acceptatie toe.

Konden de organisaties die aan SOX moeten voldoen anders dan een sterke ‘push’-gerichte benadering kiezen? Nee, mogelijk niet; zoals reeds eerder gezegd is er de deadline en daarnaast de begrijpelijke wil van de holding om risico’s te vermijden. Dat laatste werd nog versterkt doordat de wet nog veel onduidelijkheden bevatte. Ook vereist de wet nu eenmaal dat veel instrumenteel toetsbare zaken, zoals het systeem van internecontrolemaatregelen, transparant moeten zijn opgezet en gerealiseerd, en dat de effectieve werking ervan moet kunnen worden bewezen. De kwaliteit van de ‘control environment’ daarentegen wordt niet echt hard in wetgeving en codes vastgelegd, ondanks het belang voor toekomstvast compliant gedrag. De keuze voor ‘push’-projecten, waarin de controlemaatregelen in de processen van de bedrijfsonderdelen worden doorgedrukt, is dan een logische keuze. Dat is echter nog geen reden om niet in aanvulling daarop via ‘pull’-technieken de attitude van de mens te veranderen en tevens de controls goed te verankeren in de bestaande kwaliteits- en managementsystemen van de diverse organisatieonderdelen.

Suboptimalisatie op het gebied van ‘total costs of compliance’

Een ander aspect dat tot uitdrukking komt in de complianceprojecten onder tijdsdruk is dat er vaak kwaliteitsconcessies zijn gedaan in de keuze van de controls. Het doel van complianceprojecten is het totaal van actiegerichte controls binnen het management-controlsysteem van de organisatie dusdanig in te richten (dus procedures, autorisaties, beleid, werkinstructies, systeemcontrols, rapportages, etc.), dat zekerheden toenemen over de betrouwbaarheid van de externe financiële rapportages. Vanuit het oogpunt van de ‘total costs of compliance’ dient de voorkeur te worden gegeven aan preventieve geautomatiseerde controls boven handmatige procedures. Deze zijn namelijk het meest stringent, met andere woorden met de implementatie van deze maatregelen is de kans dat de controledoelstelling wordt gerealiseerd het grootst. Eén van de kwaliteitsconcessies die organisaties vanwege tijdsdruk hebben gedaan, is echter om in het eerste SOX-jaar de meest simpele en goedkope controls in te richten qua opzet en initiële implementatie. Dit zijn vaak handmatige procedures. Deze controls kennen echter hoge kosten op het gebied van testen en onderhoud en bieden minder strakke waarborgen in vergelijking met geautomatiseerde controles. De inspanning om de effectiviteit van een control aan te tonen is bij geautomatiseerde controles (wijzigingsbeheer nalopen) veel minder dan bij handmatige procedures (steekproefsgewijze afloopcontroles). Na het eerste SOX-jaar zien wij organisaties dan ook stap voor stap de handmatige controles vervangen door geautomatiseerde controles. Een verschijnsel dat binnen KPMG ‘controls transformation’ wordt genoemd.

Suboptimalisatie op het gebied van ondersteunende tooling

Daarnaast hebben organisaties, om een naar hun perceptie langdurig selectietraject te vermijden, beperkt gebruikgemaakt van gespecialiseerde ondersteunende tools bij het ontwerpen, implementeren en testen van de controls. De toevlucht uit tijdnood genomen tot suboptimale tooling, zoals Microsoft Excel en Access, illustreert deze spagaat waarin veel organisaties verzeild zijn geraakt. Het gebruik van een suboptimale toolset betekent dat in de praktijk het testproces stroef verloopt, omdat de verplichte activiteiten op het gebied van vastlegging en bewijsverzameling zeer beperkt worden ondersteund. Daarnaast is het maken van rapportages over de status van de controls zonder goede tools vaak een tijdrovend en handmatig proces.

Suboptimalisatie op het gebied van de scope van de controls

Het vierde punt waaruit suboptimalisatie door de tijdsdruk blijkt, is de scope van de controls. Die is vaak zo nauw mogelijk gedefinieerd om zeker te zijn dat de implementatie van de wet tijdig werd gerealiseerd. Alleen die controls die in het kader van de financiële verslaggeving relevant zijn, werden vaak in scope van het project genomen. Ook al begrijpt eenieder dat in de slipstream uit efficiencyoogpunt beter direct een verbetering van de controls in andere processen had kunnen worden gerealiseerd ([Vree06]).

Casus: Succesfactoren van het internationale complianceproject van DSM

Het programma, True Blue geheten, waarvan de succesfactoren worden toegelicht, heeft in totaliteit twee jaar gelopen en is recentelijk afgerond. Het was het doel van het programma om de meeste bedrijfsonderdelen van het concern (totale omzet meer dan 8 miljard euro) compliant te maken met de nieuwe Corporate Requirements op het gebied van interne controle en de resterende onderdelen ervoor toe te rusten dat binnen een vastgestelde periode zelf te doen. Om de bedrijfsonderdelen hierbij te assisteren is een centrale projectorganisatie ingericht, bestaande uit enkele tientallen personen. Om de units op locatie te ondersteunen met het compliant raken zijn zogenaamde ‘flying squads’ opgericht en is een sterk centraal ‘methods & tooling center’ ingericht. In twee jaar zijn door de squads ongeveer vijftig bedrijfsonderdelen bezocht, waarbij als basis een on-site support periode van ongeveer twee maanden is genomen. Twee weken werden gereserveerd om de mate van compliancy vast te stellen, de rest van de tijd was voor het assisteren bij het repareren en het overdragen van de resultaten. De organisatiestructuur van het programma is weergegeven in figuur 1. In de stuurgroep zaten zowel vertegenwoordigers uit de Raad van Bestuur (CEO en CFO) als vertegenwoordigers van de bedrijfsonderdelen (divisiemanagement). De projectwerkzaamheden worden verderop in het artikel nader toegelicht.

C-2007-1-Vreeke-1

Figuur 1. Projectorganisatie.

De succesfactoren van het project worden aan de hand van de volgende aspecten toegelicht:

  • evenwicht tussen managementstijl en projectstijl;
  • programma- versus roll-out management;
  • gelaagdheid in requirements, flexibiliteit in compliance-eisen op detailniveau;
  • verpakken van de complianceboodschap;
  • roll-out script, compliance tracking & toolbox;
  • communicatie;
  • aandacht voor mens en gedrag;
  • gebruik van ondersteunende tools.

Evenwicht tussen corporate-managementstijl en corporate-projectstijl

Eén van de belangrijkste succesfactoren van het project is dat de centrale organisatie erin is geslaagd de balans te vinden tussen ‘push’ en ‘pull’. Ondanks dat er centraal een zwaar projectteam is opgericht, dat actief de verschillende bedrijfsonderdelen heeft ondersteund, is de verantwoordelijkheid voor het compliant raken niet door de centrale organisatie van het management van de afzonderlijke bedrijfsonderdelen overgenomen. Dit laatste is ook continu bevestigd door communicatie vanuit de Raad van Bestuur. Indien de bedrijfsonderdelen zelf niet optimaal profiteerden van de aanwezigheid van het flying squad, dan was dat hun eigen verantwoordelijkheid.

Om zorg te dragen voor een eenduidige interpretatie van wat compliant betekent, stond de wijze waarop de compliancemetingen werden gedaan en gemonitord vast (meten op resultaat = ‘pull’). Daarnaast lag echter ook de wijze waarop de gaps met de requirements moesten worden gedicht vast, inclusief de inhoud van het procesdesign van de daarvoor ondersteunende tools (sturen op activiteit = ‘push’). Daar waar activiteiten dienden te worden uitgevoerd om het compliancebewustzijn te veranderen, en hierdoor een blijvend resultaat te realiseren, konden de bedrijfsonderdelen weer veel meer hun eigen weg bewandelen. Een centraal ontwikkelde toolkit met posters, games, trainingen en video’s was aanwezig, maar hoe en op welke schaal daarvan gebruik te maken is aan de bedrijfsonderdelen zelf overgelaten. Er werden ook methoden aangereikt om de cultuurontwikkeling te meten en gedrag te corrigeren, maar ook deze waren niet verplicht. Op deze wijze werden de bedrijfsonderdelen gestimuleerd een persoons- en cultuurgerichte implementatiemethode te volgen waarbij rekening kon worden gehouden met de volwassenheid van de bestaande compliancecultuur en met andere specifieke ‘culturele’ aspecten van het bedrijfsonderdeel en de nationaliteit.

Tabel 3 geeft aan hoe het project de balans heeft gezocht tussen ‘push’ en ‘pull’ op de gebieden organisatie, proces en systemen.

C-2007-1-Vreeke-t3

Tabel 3. De balans tussen ‘push’ en ‘pull’ op enkele gebieden.

Ook in de projectuitvoering heeft het centrale management de gulden middenweg bewandeld. Er was een zeer gedetailleerd roll-out script en ook de lijst met requirements en gedetailleerde controls was omvangrijk (‘push’), maar de flying squads konden best van het script afwijken, na formeel overleg en goedkeuring van het programmamanagement (‘pull’).

Geconcludeerd kan worden dat de wijze van de corporate-projectaanpak aansluit bij de corporate-managementstijl van de DSM-organisatie als geheel. Ook daarin hebben de Business Groepen veel eigen verantwoordelijkheid ten aanzien van het resultaat, maar is er een corporate-invloed op de keuze van bijvoorbeeld de IT-systemen en worden corporate-initiatieven op het gebied van shared services afgedwongen. Ook daarin is er duidelijk een balans tussen ‘invloed uitoefenen’ en ‘eigen verantwoordelijkheid geven’ gevonden.

Programma- versus roll-out management

DSM beschikte op het moment van de implementatie van dit project nog niet over een PMO op corporate niveau. Voor dit project werd derhalve speciaal een PMO ingericht, zodat een duidelijk onderscheid gemaakt kon worden tussen programmamanagement en het managen van de implementatie van de requirements in de afzonderlijke bedrijfsonderdelen. De programmadirecteuren kwamen wekelijks met de leiders van de werkgroepen en het squad support center bijeen in een kerngroep, waarbij programmadirecteur I de algehele leiding had. Deze gelaagdheid heeft ervoor gezorgd dat de programmadirecteuren voldoende tijd hadden voor coördinatie, reflectie, het afstemmen van corporate-initiatieven, het zorg dragen voor brede communicatie en het ‘masseren’ van het management van de bedrijfsonderdelen. De gelaagdheid creëerde tevens ruimte voor escalatie, waardoor de operationele flying squads door konden met hun activiteiten. Daarnaast kon op basis van feedback van de flying squads en de bedrijfsonderdelen worden bijgestuurd in de aanpak en compliance-eisen, zonder dat de squads daar verantwoordelijk voor werden gehouden (don’t shoot the messenger). In een enkel geval betekende dit dat compliance-eisen werden verlicht, net nadat bedrijfsonderdelen om compliant te geraken sterk verandermanagement hadden doorgevoerd. Natuurlijk leidde dit tot soms tot frustraties. Het programmamanagement had in ieder geval voldoende afstand en supervisie om soms wat harder aan te touwtjes te trekken (‘push’) en soms deze te laten vieren (‘pull’).

De leiders van de flying squads hadden zelf veel eigen verantwoordelijkheid waar het erom ging de bedrijfsonderdelen te bewegen tot het implementeren van de Corporate Requirements. De mate waarin zij erin slaagden het compliancepercentage in de aan hen toevertrouwde bedrijfsonderdelen te laten groeien, was van directe invloed op hun jaarbonus. Om die eigen verantwoordelijkheid te kunnen invullen, konden de leiders van de squads, binnen enkele randvoorwaarden, afwijken van het script of het gebruik van de tools. De beste teams waren in staat pragmatisch te opereren, toch het detail te zoeken, goed contact op te bouwen met het management van de bedrijfsonderdelen en vooral het eigen initiatief binnen de bedrijfsonderdelen aan te wakkeren. Ook hielden zij zich zoveel mogelijk aan het vastgestelde script, waardoor zij heel helder konden communiceren over afwijkingen; daardoor was support van het squad support center optimaal mogelijk. De squads, die dachten alleen via ‘push’-technieken zelf zoveel mogelijk gaps te kunnen dichten, kwamen vaak van een koude kermis thuis. Juist dan waren de Business Groepen soms in staat in de stuurgroep vertragingen goedgekeurd te krijgen.

Gelaagdheid in requirements, flexibiliteit in compliance-eisen op detailniveau

Als afgeleide van de bedrijfswaarden (DSM Values) vormen de Corporate Requirements de kapstok van de gehele structuur van internecontrole-eisen. Deze per discipline ingerichte en op het intranet beschikbare set regels beschrijft op hoog niveau wat het concern vereist op het gebied van kwaliteit, beheersing, rapportages en uitvoering voor alle primaire en ondersteunende processen. Sommige requirements kunnen worden getypeerd als internecontrole-requirements. Het zijn deze requirements die in scope waren van het project. Ondanks dat de requirements op hoog niveau zijn beschreven, zijn zij wel concreet genoeg om direct te implementeren en zijn ze auditeerbaar.

De requirements, dus ook de internecontrole-requirements, zijn dusdanig geformuleerd, dat zij toepasbaar zijn voor alle bedrijfsonderdelen, onafhankelijk van typologie, locatie, informatiesysteem, groeifase of omvang. Naast de Corporate Requirements beschikt de organisatie over zeer gedetailleerde internecontroleraamwerken, waarin per processtap en per risico is aangegeven wat de standaardmaatregelen van interne controle zijn om de risico’s te beheersen. De DSM Values en de Corporate Requirements zijn ‘wet’ voor alle bedrijfsonderdelen, maar de gedetailleerde normenkaders zijn alleen voor die onderdelen verplicht die gebruikmaken van SAP en voor niet-SAP-gebruikers slechts een best practice. Deze gelaagdheid (detailniveau) in de requirements heeft de organisatie het middel gegeven om:

  • op alle niveaus in de organisatie commitment te krijgen voor de compliance-eisen;
  • op alle niveaus in de bedrijfsonderdelen de compliance-eisen te communiceren en te toetsen;
  • te differentiëren naar de ‘controlvolwassenheid’ van de bedrijfsonderdelen.

Figuur 2 illustreert hoe de gelaagdheid in requirements de organisatie in staat stelde deze efficiënt uit te rollen (zie ook volgende subparagraaf). De eerste kolom toont de gelaagdheid, de tweede de primaire doelgroep, de derde de wijze van vastlegging per niveau.

C-2007-1-Vreeke-2

Figuur 2. Gelaagdheid in requirements.

Verpakken van de complianceboodschap

Gedurende het project heeft het uitrollen van standaardbedrijfsprocessen een steeds prominentere rol gekregen. Hierdoor kon de complianceboodschap ook een positieve wending krijgen. De internecontrole-eisen worden gezien als een impliciet kwaliteitsaspect van het standaardbedrijfsproces. De testfase (zie volgende subparagraaf) is dan ook uitgevoerd op basis van het standaardbedrijfsproces. Door middel van interactieve workshops en detailsessies met proces- en systeemspecialisten zijn de standaardbedrijfsprocessen (inclusief de internecontrole-eisen) gevalideerd. Daarbij werd gebruikgemaakt van het ‘drieluik’: (1) lijst met eisen op verschillende detailniveaus, (2) processchema’s van het standaardbedrijfsproces en (3) rolbeschrijvingen. Het werken met dit drieluik om op een interactieve manier de gaps vast te stellen en direct kennis over te brengen van het standaardbedrijfsproces, bleek succesvol.

C-2007-1-Vreeke-3

Figuur 3. Overzicht drieluik validatiesessies en gap-analyse.

Het complianceproject heeft zo veel bijgedragen aan de kennisverbetering over de standaardbedrijfsprocessen en het standaardsysteem. Daarnaast heeft het project ‘afwijkingen’ met de standaard (denk aan functiescheidingen) gecorrigeerd en is bij veel bedrijfsonderdelen de oprijlaan om het standaard-SAP-systeem uit te rollen geplaveid, door bijvoorbeeld de standaardrollen en -procedures alvast te implementeren.

Omdat in de bedrijfsstrategie ook ‘operational excellence’ en ‘stimuleren van innovatie’ als doelstellingen prominent worden genoemd, kon dit vehikel mede worden gebruikt om de compliancedoelstelling in te verpakken. Die van ‘operational excellence’ ligt voor de hand, processtandaardisatie biedt ruimte voor optimalisatie door procesverbetering of procescentralisatie. Maar hoe verbind je compliance en het stimuleren van innovatie?

Allereerst resulteren compliance en standaardisatie in beheerst verlopende processen die relatief weinig managementaandacht vereisen. Dit betekent dat het management meer aandacht overhoudt voor het zoeken naar en doorvoeren van verbeteringen. De return on management ([Simo95]) neemt toe. Een andere, meer indirecte relatie tussen compliance en innovatie is dat compliance de transparantie in een organisatie verhoogt, wat de basis is voor vertrouwen. Daar waar vertrouwen is, wordt samenwerking gestimuleerd. Samenwerking is de basis voor veel succesvolle innovaties ([Boon05]).

Aan het eind van het project waren de standaardbedrijfsprocessen aanzienlijk verbeterd en voorzien van aan solide implementatie en onderhouds-toolbox. Om de resultaten van het project in te bedden in de staande organisatie is een Business Process Competence Center opgericht. Hierin zullen alle onderdelen van de standaardbedrijfsprocessen worden beheerd (denk aan procesbeschrijvingen, rolbeschrijvingen, functionele ontwerpen, internecontrolerapportages, etc.), terwijl ook de uitrol naar de bedrijfsonderdelen die nog niet op de door SAP ondersteunde standaardbedrijfsprocessen zijn overgegaan, door deze organisatie uitgevoerd zal worden. Natuurlijk zal het standaard-procesmanagement dan een perfecte basis zijn voor procesimprovement. Proces- en organisatieveranderingen kunnen dan snel worden doorgevoerd, omdat enerzijds de AS-IS situatie volledig bekend is, en daarnaast op basis van gap-analyse exact duidelijk wordt op welke systemen, processen en organisatieonderdelen de wijziging impact heeft. Ook het integreren van nieuwe organisatieonderdelen zal door het hebben van standaardbedrijfsprocessen kunnen worden versneld.

Door de uitkomsten van het strak implementeren van standaardbedrijfsprocessen op deze wijze te verbinden aan de corporatestrategie, krijgt de ‘push’ waarmee ze geïmplementeerd worden voor de afzonderlijke bedrijfsonderdelen een meer legitiem karakter, waardoor de betrokkenheid toeneemt en de weerstand daalt.

Flexibiliteit in ‘push’-aspecten

Zoals al aangegeven kende dit project een redelijk hoog ‘push’-gehalte. Als je zoveel investeert, wil je bepaalde minimale garanties over de uitkomsten. Daarnaast wil je organisatiebreed een consistente en harmonieuze standaardset van internecontrolemaatregelen uitrollen. Het ‘push’-element kwam met name terug in het voorgeschreven roll-out script, het continu meten van de compliancestatus en de ondersteunende toolbox.

Roll-out script

In het roll-out script stond per fase van de uitrolactiviteiten bij de bedrijfsonderdelen vast wat er moest gebeuren, door wie, in welke vorm en wat er opgeleverd moest worden. Naarmate de best practices toenamen, werden ook de inhoud en de vorm van de op te leveren resultaten steeds vaster. Het roll-out script gaf tot in detail aan hoe bepaalde workshops dienden te worden georganiseerd, wie daarbij aanwezig moesten zijn en hoe deze moesten worden voorbereid. Het roll-out script refereerde aan ondersteunende tools, voorbeelden en best practices. In de testfase is ook gebruikgemaakt van tools om verschillende ERP-systemen door te lichten op ‘in control’-indicatoren. In het roll-out script werd ook gerefereerd aan de miniprojecten waarmee de reparatiewerkzaamheden (het oplossen van compliance gaps) vorm konden worden gegeven. Denk hierbij dan aan (1) inrichten master data organisatie, (2) oplossen functiescheidingsconflicten, (3) formaliseren procedures, (4) training uitzonderingsrapportages, (5) implementatie monitoringtools, etc. De miniprojecten stonden vast. Figuur 4 geeft een voorbeeld van het roll-out script.

C-2007-1-Vreeke-4

Figuur 4. Roll-out script.

Echter, daar waar het standaard roll-out script door omstandigheden niet kon worden gevolgd, kon exact worden bepaald hoe moest worden afgeweken en wat de consequenties zouden zijn op het gebied van het ‘te verwachten resultaat’, de planning en de resourcing. Het hebben van een standaard roll-out script kan dus ook de flexibiliteit bevorderen. Het wordt zo exact duidelijk waar ‘push’ omslaat in ‘pull’ en hoe daarmee de projectaansturing voor die bedrijfsonderdelen moet veranderen.

Compliance tracking

Tijdens de testfase is door middel van een zeer gedetailleerde scorekaart (circa duizend regeltjes) exact per proces of functioneel gebied de compliancescore in kaart te brengen. Per criterium werd met scores (0-5) aangegeven wat het volwassenheidsniveau van het bedrijfsonderdeel was op deze controlemaatregel. Vervolgens was het mogelijk per proces- en functioneel aandachtsgebied (grafisch) te rapporteren over het compliancepercentage en kon op basis van de compliancescore, vroegtijdig, een inschatting worden gegeven van de benodigde capaciteit en doorlooptijd van de herstelwerkzaamheden. Tijdens de herstelfase werd de compliancestatus nog tweemaal gemeten, waarvan de laatste keer vlak voor de overdracht. Op deze wijze kon in het project zeer gedetailleerd over de compliancestatus worden gerapporteerd. Tevens kon zo worden vastgesteld, welke bedrijfsonderdelen en supportteams het meest succesvol waren. Ook na het project zal het op detail kunnen meten van de compliancestatus door middel van tools ingebed worden in de staande organisatie.

Toolbox

Voor de ondersteuning van de squads is in het squad support, methods & tooling center een volledige toolbox ontwikkeld, die via het intranet ter beschikking is gesteld. Deze toolbox was volledig volgens het eerdergenoemde roll-out script gestructureerd. In de toolbox werd per fase van de roll-out aangegeven welke compliance-eisen, tools, templates en standaardpresentaties moesten worden gebruikt. Door te klikken op een onderdeel in het roll-out script werden direct de bijbehorende documenten toegankelijk. Ook werden alle internecontroleraamwerken via de toolbox beschikbaar gesteld.

Communicatie

Indien je in internationaal verband een corporateproject uitrolt, dan is een sterke visuele ondersteuning en branding van groot belang. De naam van het project is daarbij zeer belangrijk. Het gevecht om aandacht is de eerste ‘battle’ die moet worden gewonnen, voordat je de doelstelling mag komen uitleggen. Natuurlijk is managementcommitment een randvoorwaarde, maar zonder ‘visual presence’ is er een grote kans dat je het gevecht om managementaandacht verliest. Communicatie is zeker één van de sterkste pijlers onder het project geweest. Onder directe supervisie van programmadirecteur I is er een communicatiegroep opgezet, die behalve voor het ontwikkelen van communicatietools, zoals flyers, posters, banners, intranetpagina’s en internetcommunicatie, ook verantwoordelijk was voor het consistent uitdragen van de ‘brand’ en de juiste boodschappen op het juiste tijdstip aan de juiste doelgroepen. Eigen templates, pictures, cartoons en styles zijn hiervoor ontwikkeld. Daarnaast hebben de communicatiespecialisten een actieve rol gespeeld in de trainingen voor de projectmedewerkers. Daar waar bedrijfsonderdelen ook in hun eigen media iets over het programma wilden publiceren, konden zij rekenen op steun van deze communicatiegroep. Wel op basis van ‘pull’.

Aandacht voor mens en gedrag

Een andere belangrijke key success factor is het verankeren van rollen in de organisatie geweest. Met medewerking van de corporate HR-afdeling zijn alle standaardprocesrollen (inclusief SAP-systeemprofielen), gespiegeld aan HR-functiebeschrijvingen, die uiteindelijk samen met competenties en vaardigheden tot organisatorische posities per bedrijfsonderdeel flexibel konden worden opgebouwd. Op die manier ontstond er een directe link tussen de taken en verantwoordelijkheden in systemen en procedures met de HR-functiebeschrijvingen. Dit heeft er bij een aantal bedrijfsonderdelen toe geleid dat in de persoonlijke jaarlijkse evaluatiemeeting de prestaties op het gebied van compliance onderdeel gingen uitmaken van de beoordelingsstructuur.

Daarnaast is met behulp van arbeidspsychologen materiaal ontwikkeld om het compliancebewustzijn te verbeteren en het verandertraject handen en voeten te geven. Naast video’s, rollenspellen en trainingsmateriaal zijn er hulpmiddelen tot stand gekomen op het gebied van consequentiemanagement (‘just right management’). Een belangrijk onderdeel van het trainingsmateriaal is hoe ‘leadership’ ondergeschikten kan aanspreken op foutief gedrag en hoe dit consequenties moet trekken inzake non-compliant gedrag. Dit met als doel een cultuur te creëren, waarin open wordt gecommuniceerd over afwijkingen en waarin actief samen wordt gezocht naar verbeteringen en oplossingsrichtingen. Op dit vlak heeft de organisatie gebruikgemaakt van haar uitgebreide ervaring op het gebied van Safety, Health en Environment.

Ondersteunende tools

Veel organisaties hebben ervoor gekozen om in hun complianceproject, althans aanvankelijk, geen gebruik te maken van geavanceerde workflow tools, ook wel Compliance Management Software of Governance, Risk & Assurance Platforms genoemd. De afweging is dan vaak, dat ze eerst willen zien wat exact de requirements zijn. Maar ook vanwege de tijdsdruk is er vaak voor gekozen om gewoon office-tools te gebruiken als Excel en Access voor de vastlegging van de controls, testinstructies en resultaten. In tabel 4 wordt een overzicht gegeven van alle ondersteunende tools die reeds zijn uitgerold in het project of die mogelijk in de nabije toekomst kunnen worden uitgerold. Het lijkt een lappendeken, maar in de praktijk is dit niet het geval. Veel van de tools zijn van dezelfde leveranciers en integreren met elkaar. Daarnaast zijn er nog geen tools op de markt die alle benodigde functionaliteit bieden. De verwachtingen op het gebied van de nieuwe Governance, Risk en Compliance-functionaliteiten van SAP (mede door de overname van Virsa en de integratie en uitbouw van de oude SAP Management of Internal Control-oplossing) zijn echter hooggespannen. Door het gebruik van onderstaande tools heeft DSM een stevig fundament om op efficiënte wijze compliant te blijven.

C-2007-1-Vreeke-5

Figuur 5. Ondersteunende tools.

C-2007-1-Vreeke-t4

Tabel 4. Overzicht van ondersteunende tools. [Klik hier voor grotere afbeelding]

Lessons learned

In het project zijn er natuurlijk ook zaken te onderkennen die bij nader inzien anders en wellicht beter hadden gekund.

  • Bewaking van het ‘push’-gehalte met betrekking tot tools. In het project begon de zo succesvolle toolbox zo in omvang toe te nemen dat de squads op een gegeven moment door de bomen het bos bijna niet meer zagen, met als bekend neveneffect, dat het ‘out of the (tool)box’ denken dreigde te stoppen. Na goede interne evaluaties en onder druk van de complexere en meer diverse bedrijfsonderdelen zijn in het tweede jaar van het programma afwijkingen van het roll-out script en de toolbox wat meer toegestaan. In het begin, daarentegen, toen de toolbox nog niet geheel gereed was, hebben wij kunnen constateren dat het volgen van het standaard roll-out script en de toolbox een schijnzekerheid voor succes was voor sommige squads. Lesson learned: de omvang en het detail van de toolbox zijn kritisch.
  • Iets meer ‘push’ bij het gedrag? Naarmate het programma vorderde werd in de praktijk bewezen dat het veranderen van de attitude en het inbedden van consequence management op non-compliant gedrag bedrijfsonderdelen het snelst vooruit hielpen. Echter, door het hoge ‘pull’-gehalte op dit gebied zijn er slechts een paar bedrijfsonderdelen waar een echte compliancecultuur is gerealiseerd. Het terrein van ‘sustainable compliance’ zal dan ook worden gecontinueerd na het eindigen van het programma. Lesson learned: wat vroeger en dwingender inzetten op gedrags-beïnvloedingsmiddelen, zoals consequence management.
  • Sterker sturen op ‘cost of compliance’ en integratie met procesverbeteringen. Het implementeren van het True Blue-programma, en met name de implementatie van standaardbedrijfsprocessen daarbinnen, geeft ruime mogelijkheden om de ‘total costs of compliance’ te laten dalen. Tevens zijn stevige voordelen te behalen met shared services en procesoptimalisaties. Aangezien deze twee elementen niet als primaire doelstellingen in het project zijn meegenomen (het ging immers vooral om compliance), zijn de te behalen voordelen onderbelicht gebleven. Enkele bedrijfsonderdelen zijn inmiddels begonnen deze mogelijkheden alsnog te benutten. Deze potentie is als positieve driver voor het project echter onderbenut. Lesson learned: benut te behalen businessvoordelen van meet af aan als driver voor complianceprojecten.

Conclusie

In de resultaten van het project heeft de reeds aan de start aanwezige infrastructuur van risk management en interne controle een belangrijke rol gespeeld. Zo beschikte de onderneming al over Corporate Requirements, internecontroleraamwerken, internecontrolefunctionarissen per bedrijfsonderdeel en veel ondersteunde tools naast een standaard-SAP-systeem. Daarop voortbouwend waren de voornaamste succesfactoren van het project, waarop het project zich mogelijk onderscheidt van andere:

  • Een goede balans tussen ‘push’ en ‘pull’, waardoor én een bepaald resultaat afgedwongen kon worden, én ook de eigen verantwoordelijkheid niet aangetast werd. Door het ‘push’-gehalte was tevens het leereffect groot en ontstond er ruimte voor het delen van best practices. De stijl van het project sloot aan bij de managementstijl van de organisatie.
  • Het programma is altijd vanuit een positieve boodschap gecommuniceerd. Het project kende veel ruimte voor creativiteit en eigen inbreng. Dit straalde uit naar de projectmedewerkers en de vertegenwoordigers vanuit de bedrijfsonderdelen. Voor velen zowel intern als extern was dit internationale project een zeer positieve ‘once of a lifetime’-ervaring.
  • Gelaagdheid in het projectmanagement. Een duidelijke scheiding tussen programmamanagement en dagelijkse projectuitvoering. Het afstemmen van allerlei corporate-initiatieven en het managen van frustraties en conflicten kon hierdoor voldoende aandacht krijgen van de ervaren programmadirecteuren.
  • De complianceboodschap is zoveel mogelijk verpakt in de bijdrage aan de strategie, door operational excellence (processtandaardisatie) en innovatiestimulering.
  • De ‘pull’-activiteiten op het gebied van bewustzijn en gedrag en de sterke integratie met enkele HR-tools.

Voor die organisaties die klem zitten in hun complianceproject is dan ook het advies meer ‘pull’-aspecten toe te laten in het project, en daarnaast:

  • zich niet blind te staren op het aantal controls, maar te focussen op de slimheid van de controls. Slimme (lees preventieve en geautomatiseerde) controls zijn goedkoper in onderhoud en strakker. Daarnaast kunnen ook dagelijkse controles mogelijk worden vervangen door periodieke overspannende verbandscontroles.
  • de scope te verbreden van financiële controls alleen naar ook de business controls en daarmee direct ook te streven naar operational excellence-initiatieven. Indien controls onderdeel uitmaken – als kwaliteitsaspect – van standaardbedrijfsprocessen, dan vangt de organisatie twee vliegen in één klap. Bij de implementatie en instandhouding van de standaardbedrijfsprocessen dienen die activiteiten op het gebied van interne controle naadloos te worden geïntegreerd. Zowel dus in beheer, uitrol als naleving (audit).
  • controlsintegratie hoog op de agenda te zetten. Ook al kunnen de controledoelstellingen voor de verschillende standaarden (bijvoorbeeld SOX/Tabaksblat, ISO, cGMP, FDA, Cobit, BS7799) verschillen, via de testinstructie kan toch de effectiviteit van de controls naar de verschillende standaarden toe worden opgerold en aangetoond. Controlsintegratie zal de testinspanning en het beheer van de raamwerken significant doen afnemen. Het aantal audits bij de verschillende bedrijfsonderdelen zal zeer sterk dalen. Voor controlsintegratie is ondersteunende tooling noodzaak.
  • te kiezen voor een goede ondersteunende toolset, ondanks dat de ‘holy grale’ op dit gebied, als een volledig geïntegreerde tool, nog niet bestaat. Organisaties dienen eerst goed vast te stellen wat hun visie is op het gebied van corporate governance, enterprise risk management, testen, continuous assurance, etc. en op basis hiervan eisen op te stellen. Vervolgens moeten zij een goede leverancier of combinatie van leveranciers kiezen die hen kan ondersteunen in het realiseren van een ondersteunend platform om die visie in te vullen. Het helder formuleren van eisen is belangrijk, zodat toch nog tijdig kan worden bijgestuurd als de gekozen tools niet blijken te leveren wat werd verwacht, of als andere tools in de markt zich beter ontwikkelen.

Het True Blue-programma is nu ontbonden en de projecttaken worden momenteel verankerd in de staande organisatie. De oprichting van het (SAP supported) process management center met daarin geïntegreerd de internecontroleactiviteiten en tools, de verankering van proceseigenaarschap op concernniveau en de oprichting van een corporate risk management-afdeling zijn hierin belangrijke pijlers.

Tot slot

Wil een organisatie meer halen uit complianceprojecten, dan zal zij ‘pull’-elementen moeten toestaan in haar project, moeten focussen op de ‘total costs of compliance’ en de complianceboodschap enigszins moeten verpakken. Daarnaast is sterke communicatie en aandacht voor de mens en de HR-functie essentieel om een blijvend resultaat af te dwingen. Diverse softwaretools zijn op de markt om tijdens de gehele controls-lifecycle ondersteuning te bieden. Echter, deze zijn nog niet volwassen en geïntegreerd. Om het gehele spectrum te ondersteunen zullen nu nog ‘best-of-breed’ producten nodig zijn.

Literatuur

[Boon05] A. Boons, Meer controle, meer creativiteit, Chief Financial Officer, januari-februari 2005, p. 66.

[Donk02] J.A.M. Donkers en R. Oudega, Van projectaudit tot projectcontrol, Compact 2002/4.

[Donk05] J.A.M. Donkers, R. Oudega en S. van der Meijs, Commitments: het realiseren van de baten van projecten, Compact 2005/4.

[HFD04] Diverse artikelen Het Financieele Dagblad, katern ‘Corporate Governance’, dinsdag 21 september 2004.

[Kapt04] M. Kaptein en H. Klamer, De implementatie van bedrijfscodes in Nederland, finance & control, August 2004, pp. 11-15.

[Merc03] K.A. Merchant en W.A. van der Stede, Management Control Systems, performance measurement, evaluation and incentives, Prentice Hall, 2003.

[Simo95] R. Simons, Levers of Control, how managers use innovative control systems to drive strategic renewal, Harvard Business School Press, Boston 1995.

[Vree06] A. Vreeke, B. Coolen en F.T. Kooistra, Beheersing van de business cycle ‘Material to Product’, Compact 2006/2.

Excuse me, do you speak ITGC?

Vanaf 2005 zijn alle beursgenoteerde ondernemingen in de EU verplicht IFRS toe te passen. Met deze verplichting is een belangrijke stap gezet in de wereldwijde harmonisatie in de financiële verslaggeving ofwel de ‘financiële wereldtaal’. Als we kijken naar het beheersingsvraagstuk binnen het IT-domein zijn er momenteel diverse standaarden voorhanden, echter ontbreekt een ‘wereldtaal’. Ondanks dat de IT general controls door de IT-auditberoepsgroep (internationaal) zijn uitgewerkt, blijkt in de praktijk dat verschillende belanghebbenden (zoals klanten, toezichthouders en de externe accountant) verschillende standaarden gebruiken dan wel verschillende verklaringen vragen over de beheersing van de IT controls. Dit leidt nogal eens tot afstemmingsproblemen en interpretatieverschillen. Dit artikel geeft een aanzet om de IT controls zowel intern als extern, nationaal en internationaal te harmoniseren en standaardiseren.

Inleiding

Een aantal ontwikkelingen in de afgelopen jaren, zoals de invoering van de Sarbanes-Oxley (SOX) regelgeving en de International Financial Reporting Standards (IFRS), hebben gevolgen gehad voor de normering die de grondslag vormt voor de oordelen van auditors. Deze ontwikkelingen hebben ervoor gezorgd dat er op internationaal niveau wordt gesproken over uniformering dan wel harmonisatie van normen. Zo zijn vanuit de SOX-wetgeving heldere richtlijnen opgesteld over de verklaringen die moeten worden afgegeven door het management van een organisatie en de externe auditors. Hierbij is het van groot belang dat de onderliggende normeringen die internationaal door auditors worden gebruikt, gelijk zijn. Met andere woorden, auditors maar ook de auditees en de afnemers van de oordelen van auditors moeten dezelfde ‘taal’ spreken (of op z’n minst de gesproken ‘taal’ begrijpen). Kijken we naar de financiële verslaggeving dan zien we dat hier sinds de invoering van IFRS internationaal een set van afspraken geldt over hoe bedrijven hun jaarverslag moeten presenteren. Dat het gebruik van een dergelijk gemeenschappelijk normenkader voordelen heeft spreekt voor zich. Interpretatieverschillen worden hiermee geminimaliseerd en in bepaalde gevallen voorkomen. De accountants onder ons weten overigens wel dat er door de toepassing van IFRS als verslaggevingsstandaard in Nederland naast de Nederlandse wet- en regelgeving nog niet helemaal sprake van een eenduidige en uniforme verslaggevingstaal.

Het inrichten en onderhouden van beheersingsmaatregelen rond informatietechnologie (IT controls) is de afgelopen jaren, ook als onderdeel van de financiële verslaglegging en de verantwoording die daarover moet worden afgelegd, belangrijker geworden. IT controls vormen een onderdeel van de algemene interne beheersingsmaatregelen die een organisatie kan treffen. Interne beheersing definiëren we hierbij als een stelsel van processen dat is ingericht door de leiding van een organisatie om een redelijke mate van zekerheid te krijgen over het realiseren van de effectiviteit en efficiency van de bedrijfsvoering, de betrouwbaarheid van de financiële verslaglegging en de naleving van relevante wet- en regelgeving ([Fijn05]).

Bij de IT controls maken we onderscheid tussen applicatiespecifieke beheersingsmaatregelen (application controls) en algemene IT-beheersingsmaatregelen (IT general controls). De application controls omvatten alle maatregelen in en rond een specifieke toepassing[Kenmerk van een application control is dat de beheersingsmaatregelen in de programmatuur zijn vastgelegd, zodat ze consequent worden uitgevoerd. Soms komen bij application controls uitgebreide berekeningen voor, maar vaak ook blijven application controls beperkt tot vergelijkingen. Bij berekeningen kan gedacht worden aan eenvoudige controlegetallen of complexe hashtotals en bij vergelijkingen aan totalen of standen of aan details in een transactie ([Fijn06]).]. De IT general controls (ITGC) hebben niet slechts betrekking op een enkele applicatie, maar op alle aspecten van de informatievoorziening.

C-2007-1-Mancham-1

Figuur 1. Relatie tussen application controls en IT general controls.

In de publicatie IT control Objectives for Sarbanes-Oxley van het IT Governance Institute worden de ITGC als volgt ingedeeld:

  • Access to Programs and Data (Logische toegangsbeveiliging);
  • Computer operations (IT-beheer en exploitatie);
  • Program changes (Wijzigingsbeheer);
  • Program development (Systeemontwikkeling).

In dezelfde publicatie worden de application controls gerelateerd aan de bedrijfsprocessen en wordt een voorbeeld gegeven van application controls die de juistheid en volledigheid van de informatie in een inkoopproces kunnen waarborgen. Als we kijken naar de application controls dan heeft hier nog geen uniformering dan wel harmonisatie plaatsgevonden.

Als we kijken naar de ITGC, een belangrijk auditdomein van de IT-auditor, dan kunnen we stellen dat er steeds meer sprake is van uniformering dan wel harmonisatie: er zijn diverse normen, richtlijnen en ‘best practices’ die door de IT-auditor worden gehanteerd als referentiekader zoals Cobit, de Code voor Informatiebeveiliging (ISO/IEC 17799:2005), en ITIL. Op dit moment zien we dat internationaal de ‘IT Control Objectives for Sarbanes-Oxley’ steeds vaker als ‘leidraad’ door IT-auditors maar vooral door organisaties zelf worden gebruikt. De uitwerking van ITGC die in deze publicatie zijn opgenomen, zijn afgeleid van Cobit, de Code voor Informatiebeveiliging en ITIL, en sluiten aan bij COSO.

In de huidige praktijk worden er diverse internationale standaarden, zoals Cobit en de Code voor Informatiebeveiliging, gebruikt voor het beoordelen van (de onderdelen van) de IT controls, terwijl veel organisaties en ook samenwerkingsverbanden tussen organisaties ook eigen normenkaders hebben ontwikkeld, weliswaar vaak gebaseerd op algemene standaarden maar gericht op specifieke doeleinden. Door het ontbreken van een algemene standaard (een wereldtaal), die voor de meest voorkomende praktijksituaties concreet toepasbaar is, ontstaan er afstemmingsproblemen tussen organisaties en auditors bij het onderling gebruikmaken van verklaringen over de beheersing van de IT controls.

In dit artikel wordt eerst een aantal ontwikkelingen geschetst die aanleiding geven om te komen tot verdere harmonisatie en standaardisatie van IT controls. Alvorens, naar analogie van de ontwikkeling van IFRS, de weg naar een IT controls wereldtaal te verkennen, worden de voor de IT controls relevante raamwerken en standaarden benoemd. Daarnaast wordt een overzicht gegeven van verklaringen die momenteel door organisaties worden gebruikt om aan derden aan te tonen of en zo ja, in hoeverre de IT controls ‘in control’ zijn.

Kader 1. Sarbanes-Oxley (SOX).

SOX

De Amerikaanse SOX-regelgeving uit 2002 is genoemd naar de opstellers ervan, de voorzitters van het Huis van Afgevaardigden en de Senaat van de Verenigde Staten, Sarbanes en Oxley. De prikkel voor deze wetgeving komt voort uit de debacles die aan het eind van de vorige eeuw bij een aantal bedrijven ontstonden. Daarbij speelden ‘oneerlijkheid’ en ‘ondoorzichtigheid’ in het handelen van de bedrijfsleiding een belangrijke rol. De SOX-wetgeving richt zich op de inrichting van bedrijfsprocessen met betrekking tot de financiële verslaglegging en de verantwoording die daarover moet worden afgelegd.

Bron: Trends in IT-beveiliging 2006.

Ontwikkelingen

IT is bij nagenoeg alle ondernemingen een belangrijk onderdeel van de bedrijfsprocessen en is feitelijk het ‘hart’ van de organisatie. Organisaties steunen dan primair op de kwaliteit van de IT controls om de betrouwbaarheid van de (financiële) gegevensverwerking te waarborgen. Mede als gevolg van de steeds toenemende afhankelijkheid van IT zien we een aantal ontwikkelingen die aanleiding geven om te komen tot verdere harmonisatie van IT controls. Een voorbeeld is de steeds verdergaande proces- en ketenintegratie. Om de efficiency in het auditen van dergelijke informatieketens te bevorderen zien we auditors steeds vaker verklaringen afgeven waarop een andere auditor kan steunen. Het bekendste voorbeeld hiervan is een zogeheten SAS 70-verklaring.

Daarnaast zien we dat door de ketenpartners en auditors meer en meer gebruik zal worden gemaakt van een gemeenschappelijk dan wel geïntegreerd en procesgericht stelsel van internecontrolemaatregelen. Nu zien we vaak dat interne beheersingssystemen van de verschillende ketenpartners onvoldoende op elkaar aansluiten en hanteren de betrokken (externe) auditors hun eigen normenkader. Niet alleen vertoont het werk van de auditors hierdoor overlap, maar tevens bestaat de kans dat er onvoldoende inzicht is in de kwaliteit van het gehele proces.

Bovengenoemde ontwikkelingen hebben een belangrijke impact op de wijze waarop de IT-auditor zijn of haar werkzaamheden uitvoert en vastlegt. De verschuiving van ‘trust me’ naar ‘prove me’, het toenemende belang van transparantie en de aard van de ‘in control’-verklaringen van het management eisen dat de IT-auditor te allen tijde de deugdelijke grondslag van de uitgevoerde audit dient aan te tonen. Dit betekent niet alleen standaardisatie van werkwijze (waaronder dossiervorming) maar ook standaardisatie van normenkaders. In de volgende paragraaf wordt een overzicht gegeven van de raamwerken en standaarden die gebruikt worden voor IT controls. Hierna gaan we in op een aantal verklaringen die door organisaties worden gebruikt om aan derden aan te tonen of en zo ja, in hoeverre de ITGC ‘in control’ zijn.

Raamwerken en standaarden voor IT controls

In de inleiding hebben we al aangegeven dat er rond het gebied van de application controls nauwelijks sprake is van harmonisatie en uniformering. Er zijn dan ook geen breed toepasbare normenkaders, richtlijnen en/of ‘best practices’.

Voor het inrichten en onderhouden van de ITGC zien we in de praktijk dat verschillende raamwerken en standaarden worden gehanteerd. Hieronder geven we een kort overzicht van de verschillende raamwerken/standaarden. Het algemeen aanvaarde COSO-model voor interne beheersing kan worden gezien als de basis voor al deze raamwerken en wordt daarom als eerste behandeld. Daarna besteden we aandacht aan Cobit, een raamwerk voor de beheersing van informatietechnologie, dat mede op COSO is gebaseerd. Andere relevante raamwerken dan wel standaarden die we hier behandelen zijn de Code voor Informatiebeveiliging (ISO/IEC 17799:2005) en ITIL voor IT-beheer (ISO/IEC 20000:2005). Deze raamwerken, die elkaar gedeeltelijk overlappen, geven een verdere verdieping van de aandachtsgebieden binnen Cobit.

COSO

COSO heeft niet zozeer betrekking op IT, als wel op interne beheersing in brede zin. Als geïntegreerd raamwerk voor corporate governance wordt meestal gesteund op het COSO-model. Dit model is in de jaren negentig ontwikkeld door de Committee of Sponsoring Organizations of the Treadway Commission als gevolg van een aantal boekhoudschandalen in de Verenigde Staten. Het COSO-model helpt ondernemingen en andere organisaties met het beoordelen en verbeteren van de interne beheersingssystemen. Volgens COSO bestaat interne beheersing uit vijf verschillende componenten die onderling samenhangen: beheersingsomgeving, risicoanalyse, beheersingsmaatregelen, informatie en communicatie, en monitoring.

C-2007-1-Mancham-2

Figuur 2. COSO.

Cobit

Eind jaren negentig ontwikkelde de Information Systems Audit and Control Association (ISACA) de Control Objectives for Information and related Technology, ofwel Cobit. Cobit wordt gezien als de invulling van het COSO-model voor IT. Het Cobit-raamwerk biedt management en auditors richtlijnen om de IT-beheerprocessen in te richten en te beoordelen. Het Cobit-raamwerk is gebaseerd op drie dimensies. De eerste dimensie bestaat uit een zevental kwaliteitskenmerken van informatie en informatiesystemen: effectiviteit, efficiency, vertrouwelijkheid, integriteit, beschikbaarheid, naleving en betrouwbaarheid. De tweede dimensie bestaat uit vijf categorieën van informatiemiddelen: gegevens, applicatiesystemen, technologie, faciliteiten en mensen. De derde dimensie bestaat uit vier domeinen, waarbinnen beheersingsmaatregelen worden gegroepeerd: de planning en organisatie van de inzet van informatietechnologie, de acquisitie en implementatie van informatiesystemen, de levering van IT-diensten en de ondersteuning daarbij, en de bewaking van de voorgaande drie domeinen. Binnen elk van de domeinen definieert Cobit een aantal beheersingsdoelstellingen op procesniveau. In totaal zijn er 34 van dergelijke doelstellingen.

C-2007-1-Mancham-3

Figuur 3. Cobit.

Code voor Informatiebeveiliging

De Code voor Informatiebeveiliging is een ‘best practice’ voor het inrichten van een beveiligingsproces en het invoeren van beveiligingsmaatregelen. De Code voor Informatiebeveiliging is uitgegroeid tot de internationaal meest gebruikte (toonaangevende) standaard op het gebied van informatiebeveiliging.

De Code beschrijft meer dan honderd beveiligingsmaatregelen die door de opstellers ervan als minimaal noodzakelijk worden beschouwd. De maatregelen zijn ingedeeld in elf hoofdstukken, die gaan over beleid, organisatie, classificatie, personeel, fysieke beveiliging, beheer, logische toegangsbeveiliging, ontwikkeling en onderhoud, beveiligingsincidenten, continuïteit en naleving (compliance).

ITIL

Een andere relevante standaard is de Information Technology Infrastructure Library (ITIL), een verzameling richtlijnen voor het beheer van informatiesystemen, opgesplitst in modules voor de meest uiteenlopende beheerprocessen: configuratiebeheer, wijzigingsbeheer, probleembeheer, netwerkbeheer, enz. ITIL is een ‘best practice’: de procesbeschrijvingen zijn gebaseerd op de manier waarop een groot aantal bedrijven en instellingen het beheer van de informatievoorziening heeft ingericht. ITIL is inmiddels algemeen geaccepteerd en wordt in tal van varianten toegepast. Aan ITIL is twee jaar geleden een belangrijke ontbrekende schakel toegevoegd: de module Security Management, een Nederlands initiatief, gebaseerd op de Code voor Informatiebeveiliging. Veel automatiseringsafdelingen en serviceorganisaties werken op dit moment volgens ITIL.

In 2005 verscheen ISO/IEC 20000, een standaard voor IT Service Management. Deze standaard kent twee delen, namelijk 20000-1, waarin de formele specificaties voor certificatie staan beschreven, en 20000-2, ‘best practice’ voor IT Service Management. ISO/IEC 20000 is gebaseerd op BS 15000.

Verklaringen of statements over de beheersing van IT controls

Niet alleen SOX-trajecten, maar ook de eis van opdrachtgevers om de kwaliteit van uitbestede diensten te beheersen leidt tot de vraag naar SAS 70-verklaringen en/of andere verklaringen. Daarnaast eisen sommige instellingen van hun leveranciers dat ze aan een algemeen erkende norm voldoen zoals de Code voor Informatiebeveiliging. Soms wordt in aanvulling hierop nog een oordeel gevraagd met betrekking tot een specifiek stuk dienstverlening voor een bepaalde leverancier in de vorm van een third-partymededeling (TPM).

Hierna volgt een kort overzicht van een aantal verklaringen of statements over de beheersing van de IT controls. Deze verklaringen verstrekken een bepaalde mate van zekerheid. Per type verklaring staan we dan ook kort stil bij het zekerheidsniveau van de betreffende verklaring.

TPM

Een third-partymededeling (TPM) is een schriftelijke uiting van een onafhankelijk auditor ten behoeve van één of meer gebruikers waarbij naar aanleiding van een onderzoek een bepaalde mate van zekerheid wordt geboden over het stelsel van beheersingsmaatregelen dat de kwaliteit van de dienstverlening van een leverancier moet waarborgen. Afhankelijk van het type van onderzoek geeft een TPM een redelijke (audit) of beperkte (review) mate van zekerheid[Met redelijke mate van zekerheid bedoelen we de situatie waarin de IT-auditor toereikend bewijsmateriaal heeft verkregen om te kunnen oordelen dat het object van onderzoek in alle van materieel belang zijnde opzichten voldoet aan de gestelde criteria. Met beperkte mate van zekerheid bedoelen we de situatie waarin de IT-auditor toereikend bewijsmateriaal heeft verkregen om ervan overtuigd te zijn dat het object van onderzoek gegeven de omstandigheden voldoet aan de criteria. De mate van zekerheid correspondeert met ‘plausibel’.]. De wijze waarop het onderzoek wordt uitgevoerd en de wijze waarop wordt gerapporteerd, is niet aan bepaalde regels gebonden zoals bij SAS 70.

SAS 70-verklaring

SAS 70 staat voor Statement on Auditing Standards No. 70. Met SAS 70 wordt de standaard aangeduid van het rapport waarmee de ene auditor zich richt tot de andere auditor. De externe auditor van de aanbieder (service auditor) beoordeelt de interne beheersings- en controlemaatregelen die relevant zijn voor een klant en geeft hierover een oordeel af. De externe auditor van de klant (user auditor) kan vervolgens steunen op dit oordeel.

De serviceorganisatie (bijvoorbeeld IT service provider) beschrijft in een SAS 70-rapport op hoofdlijnen de beheerorganisatie en geeft hierbij aan hoe zij specifieke beheersingsdoelstellingen bereikt. Een externe auditor voegt een rapport toe over de mate waarin die beheersingsdoelstellingen worden gerealiseerd. Het resultaat is dat de uitbestedende organisatie inzicht krijgt in de wijze waarop de uitbestede processen worden beheerst.

C-2007-1-Mancham-4

Figuur 4. SAS 70.

Een SAS 70-verklaring geeft een redelijke mate van zekerheid dat de beheersingsmaatregelen op een bepaald moment in opzet toereikend zijn en ook daadwerkelijk bestaan (type I-verklaring) dan wel in een bepaalde periode ook hebben gewerkt (type II-verklaring).

Hoewel SAS 70 een aantal formaliteiten kent – zoals de verplichte hoofdstukindeling – zijn de grenzen van het object van onderzoek van een SAS 70-rapport niet voorgeschreven. De serviceorganisatie en de uitbestedende organisatie zijn (in onderling overleg) vrij om te bepalen welke processen en beheersingsdoelstellingen worden meegenomen in het onderzoek.

Certificatie van Informatiebeveiliging op basis van ISO/IEC 27001 en van IT Service Management op basis van ISO/IEC 20000

Certificering van Informatiebeveiliging of IT Service Management zijn onderzoeken waarbij een geaccrediteerde certificerende instelling niet zozeer de beheersingsmaatregelen op zich beoordeelt, maar het proces dat is ingericht om de (met behulp van risicoanalyse) geselecteerde beheersingsmaatregelen vast te stellen, in te voeren, uit te voeren, te controleren, te beoordelen en te verbeteren. De organisatie dient zelf aan te tonen dat het proces functioneert in overeenstemming met de ISO-standaard. In feite worden de geselecteerde beheersingsmaatregelen door de auditor aan de hand van steekproeven getoetst om het functioneren van het proces te beoordelen. Een certificeringsonderzoek kent grofweg twee fasen. De documentatiereview (te vergelijken met opzet), waarin de risicobeoordeling, de selectie van risicoreducerende maatregelen en de documentatie wordt getoetst, en de implementatiebeoordeling (te vergelijken met bestaan), waarin het stelsel van beheersingsmaatregelen wordt beoordeeld. Komt een organisatie in aanmerking voor een certificaat dan is dit certificaat voor drie jaar geldig. Gedurende deze periode voert de auditor periodieke controles uit om vast te stellen of het gedocumenteerde proces blijvend voldoet aan de ISO-standaard. Een dergelijk certificaat geeft een beperkte mate van zekerheid, ofwel de auditor heeft een gerechtvaardigd vertrouwen dat het gedocumenteerde proces functioneert in overeenstemming met de ISO-standaard.

Andere verklaringen

Naast de hierboven genoemde verklaringen zijn er nog een aantal andere verklaringen die in de praktijk voorkomen om bijvoorbeeld het vertrouwen van consumenten in websites te vergroten, zoals Systrust/Webtrust (www.webtrust.org). Met een Systrust- of een Webtrust-rapport geeft een onafhankelijke accountant aan in hoeverre de verklaring van het management dat de beheersingsmaatregelen in overstemming zijn met de van toepassing zijnde Trust Service Principles van de AICPA, redelijk en gerechtvaardigd is. De Trust Service Principles betreffen Security, Avalability, Processing Integrity, Online Privacy en/of Confidentiality. Een Systrust- of Webtrust-rapport geeft een beperkte mate van zekerheid.

De verschillende verklaringen die we hebben behandeld, zijn moeilijk met elkaar te vergelijken. Niet alleen omdat de reikwijdte en het onderzoeksobject verschillend zijn, maar ook omdat er geen voorgeschreven normen zijn voor de IT controls.

Een ITGC wereldtaal à la IFRS

Het nut van een ITGC-normenset en de weg ernaartoe

In de praktijk is het voor organisaties lastig om, naar tevredenheid van de verschillende belanghebbenden (auditor, toezichthouders, klant, etc.), een uitspraak te doen over het al dan niet ‘in control’ zijn. Dit komt niet zozeer doordat de (IT-) organisaties dit niet willen of kunnen, integendeel. De complexiteit zit vooral in het feit dat belanghebbenden nogal eens een verschillende uitspraak vragen en/of verschillende normenkaders hanteren. Binnen de eigen organisatie werkt de IT-afdeling vaak conform ITIL, terwijl vanuit oogpunt van interne beheersing door de business gekozen is voor Cobit, een bepaalde klant eist een certificaat op basis van ISO/IEC 27001:2005 en weer een andere klant vraagt een SAS 70-verklaring. En dan hebben we de externe accountant en toezichthouder nog niet eens genoemd. Om een lang verhaal kort te maken: als het gaat om de beheersing van de IT controls spreken de verschillende belanghebbenden nog onvoldoende dezelfde taal. Een gemeenschappelijke taal levert niet alleen voordelen op in de interne en externe communicatie maar ook worden er besparingen gerealiseerd in de kosten voor de IT-beheersing als geheel. De weg naar een dergelijke gemeenschappelijke ITGC-taal kan lopen zoals het is gegaan met IFRS als wereldwijde financiële taal.

Kader 2. Praktijkcasus Cordares.

Praktijk bij Cordares

Cordares is uitvoerder van pensioenregelingen voor ondernemingen en bedrijfstakken en van andere arbeidsvoorwaardelijke regelingen, collectief en privaat. Daarnaast verzorgt Cordares aanvullende inkomensverzekeringen en dekt het werkgeversrisico’s af. De meer dan één miljoen deelnemers mogen rekenen op een uitgebalanceerd pakket voor inkomenszekerheid. Bij pensionering, maar ook bijvoorbeeld bij arbeidsongeschiktheid of overlijden. Momenteel voert Cordares 27 verschillende regelingen uit met een totaal van één miljard euro aan premie-inkomsten per jaar. Het belegd vermogen bedraagt 23 miljard euro.

Cordares IT levert IT-diensten aan zowel interne partijen als aan externe partijen zoals het UWV. Voor het UWV wordt jaarlijks een TPM verstrekt door de stafafdeling Risk & Audit Services (RAS). Deze TPM is gebaseerd op door het UWV aangeleverde normen en is gericht op opzet, bestaan en werking van de (Key) IT controls.

Naast de jaarlijkse TPM worden IT-auditwerkzaamheden door RAS uitgevoerd voor de verschillende SAS 70-trajecten (type I en type II), voor het verantwoordelijk lijnmanagement, voor de controle van de jaarrekeningen van de klanten van Cordares en de jaarrekeningen van Cordares zelf. Bij deze IT- auditwerkzaamheden werd tot 2006 gebruikgemaakt van verschillende ITGC-normensets afkomstig uit verschillende bronnen. Ook de diepgang van de IT-audits was per onderzoek verschillend.

In 2006 is het stelsel van informatiebeveiliging van Cordares IT gecertificeerd op basis van ISO 27001 (voorheen BS 7799-2) door BSI Management B.V.

In 2005 is Cordares gestart met de code-Tabaksblat. Deze code heeft zijn weerslag op de beoordeling en beheersing van de IT-risico’s in het kader van de jaarlijkse ‘In Control Statements’.

Als recente relevante ontwikkeling in dit kader valt IT2Share te noemen; het samenwerkingsverband van Cordares en Mn Services op het gebied van continuïteit. Bij IT2Share hebben de auditors van RAS te maken met normen van Cordares, Mn Services en van de controlerende accountants van beide organisaties.

Deze ontwikkelingen waren voor RAS aanleiding om ‘het roer om te gooien’, om meer vanuit een ‘multi purpose single audit’-gedachte te gaan werken.

RAS heeft in 2006 een ITGC-normenset ontwikkeld die de basis vormt voor de IT-audits binnen Cordares. Deze set is dekkend voor bovenstaande onderzoeken. Binnen de normenset maakt RAS onderscheid tussen de Key IT Controls en de zogenaamde Add On Controls die in bijzondere onderzoeken worden meegenomen. De ITGC-normenset is in een vroeg stadium ook afgestemd met verantwoordelijk management en de externe accountants. Het verantwoordelijk IT-management heeft eind 2006 de ITGC-normenset opgepakt om deze verder te integreren in de IT-processen binnen Cordares. Hiervoor is een project opgestart dat medio 2007 dient te worden afgerond. De IT-organisatie wil zelf vanuit een zelflerende gedachte excelleren om in continuïteit aantoonbaar ‘in control’ te zijn.

Na het afronden van de ITGC-audits 2006 zal RAS in het voorjaar van 2007 de gekozen aanpak, gehanteerde werkwijze en toegevoegde waarde van de nieuwe aanpak kritisch evalueren en waar nodig actualiseren. De externe accountants worden bij deze evaluatie nauw betrokken.

IFRS als voorbeeld hoe het kan

In de afgelopen jaren moesten de beursgenoteerde bedrijven overgaan naar een wereldwijde financiële verslaggevingstaal: IFRS. De Europese Commissie heeft in een verordening vastgelegd dat alle beursgenoteerde bedrijven vanaf 1 januari 2005 hun jaarverslag in overeenstemming met IFRS moeten presenteren. IFRS is opgesteld door de International Accounting Standards Board (IASB). De IASB is een onafhankelijk internationaal orgaan belast met het opzetten van standaarden voor jaarverslagen en jaarrekeningen. De IASB bestaat niet alleen auditors, maar ook uit bedrijven (opstellers van jaarverslagen) en bijvoorbeeld overheden (gebruikers van jaarverslagen).

Eén van de belangrijkste doelstellingen van IFRS is de transparantie en onderlinge vergelijkbaarheid tussen ondernemingen te verbeteren. Met de invoering van IFRS is tevens de onderliggende normering voor financiële verslaggeving geharmoniseerd. Wereldwijd heeft de toepassing van IFRS ook voor de auditors voordelen bij het uitvoeren van financial audits. Immers, overal ter wereld wordt gebruikgemaakt van dezelfde normeringen op het gebied van financiële verslaggeving. Een kritische lezer zal bij het lezen van deze passage opmerken dat IFRS nog niet wereldwijd verplicht is voor alle ondernemingen en dat het ‘principle based’ (naar de geest) is en niet ‘rule based’ (naar de letter)[Principle based wil zeggen dat de verslaggevingsregels gebaseerd zijn op beginselen (doelstellingen) in plaats van op gedetailleerde regels. Rule based verslaggevingsregels zijn erop gericht zoveel mogelijk situaties met specifieke voorschriften af te dekken.]. Dat is zeker zo, maar de invoering van IFRS heeft de weg naar volledige harmonisatie versneld. IFRS heeft aangetoond dat harmonisatie duidelijk voordelen heeft voor zowel de ondernemingen als de auditors.

De weg naar een IT controls wereldtaal

Om de in dit artikel geschetste problematiek het hoofd te bieden heeft een aantal grote organisaties in Nederland gezamenlijk een ITGC-raamwerk ontwikkeld. Daarnaast hebben Platform Informatiebeveiliging[Het Platform Informatiebeveiliging, kortweg PI genoemd, is een vereniging die zich beijvert voor de beveiliging van informatie en informatiesystemen. De belangrijkste pijler voor PI is het ontwikkelen en onderhouden van richtlijnen voor de praktische inrichting van informatiebeveiliging.] en NOREA (de beroepsorganisatie van IT-auditors) een werkgroep in het leven geroepen, met ruime vertegenwoordiging uit de grote accountantskantoren, overheid en ICT-dienstverleners, om een algemeen aanvaarde standaard voor de ITGC te ontwikkelen. Dit alleen is echter niet genoeg. Analoog met IFRS zou een onafhankelijke en door alle belanghebbenden geaccepteerde organisatie een dergelijke standaard moeten vaststellen. Via wet- en regelgeving kan dan vervolgens het gebruik van deze standaard worden afgedwongen.

Conclusie

Binnen het IT domein neemt naar aanleiding van de ontwikkelingen in de financiële verslaggeving de aandacht voor het vraagstuk van interne beheersing in een snel tempo toe. Het nut en de noodzaak om te komen tot een geharmoniseerde normenset voor de beheersing en de beoordeling van de IT controls is in dit artikel nader toegelicht.

Als we kijken naar de application controls dan heeft hier nog geen standaardisatie dan wel harmonisatie plaatsgevonden. Nu is dit ook lastig doordat bedrijfsprocessen en dus ook de applications control per bedrijf nogal verschillen. Toch zijn er mogelijkheden voor harmonisatie en standaardisatie, bijvoorbeeld als het gaat om de wijze waarop de application controls worden bepaald. Maar daarnaast zijn er ook mogelijkheden om (analoog aan Starreveld) per typologie van organisaties voor de hand liggende application controls te definiëren.

Kijken we naar de ITGC, dan zien we dat er verschillende standaarden, richtlijnen en ‘best practices’ zijn. Echter, een algemene standaard (een wereldtaal), die voor de meest voorkomende praktijksituaties concreet toepasbaar is, ontbreekt. Om te komen tot een wereldtaal is het, net als bij IFRS, van belang dat een onafhankelijke instantie die door bedrijven, overheid en auditors wordt geaccepteerd, een dergelijke standaard vaststelt.

Literatuur

[Eijk03] S. van der Eijk-Van Eck en K.H.G.J.M. Ho RE RA, Third-partymededelingen: de ervaringen van de gebruikersorganisaties, Compact 2003/3.

[Fijn05] R. Fijneman, E. Roos Lindgreen en P. Veltman, Grondslagen IT-auditing, Sdu Uitgevers, 2005.

[Fijn06] R. Fijneman, E. Roos Lindgreen en K. Hang Ho, IT-auditing en de praktijk, Sdu Uitgevers, 2006.

[ITGI04] IT Governance Institute, IT Control Objectives for Sarbanes-Oxley, 2004.

[NORE03] NOREA, Handreiking Oordelen van gekwalificeerde IT-auditors, 2003.

[NORE04] NOREA, IT-Governance, Een verkenning, NOREA, 2004.

[NORE06] NOREA, Het profiel van de audit. Update on ICT en controle, NOREA / Uitgeverij de kleine Uil, 2006.

[PI06] Platform Informatiebeveiliging, Trends in IT-beveiliging 2006, onder redactie van Cees Coumou, Hans Kroeze en Kees van der Zwan, 2006.

[Roos02] E. Roos Lindgreen, Over informatiebeveiliging, accountancy, informatiebeveiliging, Rede uitgesproken bij de aanvaarding van het ambt van hoogleraar IT en Auditing aan de Universiteit van Amsterdam op woensdag 16 oktober 2002.

[Rutk06] E.P. Rutkens en B. Derksen, Trends in IT en IT-auditing, Compact 2006/1.

IT-governancebenaderingen: … beyond compliance

Veel organisaties hebben de afgelopen jaren diep geïnvesteerd om compliant te geraken (SOX, Tabaksblat, Basel II, etc.). Dit heeft in de praktijk geleid tot een standaardisering en uniformering van procedures en werkwijzen binnen IT-organisaties. De IT-governance is naar de mening van de auteurs de afgelopen jaren door de toegenomen aandacht voor externe verantwoording en interne beheersing transparanter geworden. Een veelgehoorde klacht is echter wel dat de toegenomen beheersing organisaties bureaucratiseert en interngericht maakt. Terecht is er dan ook de zorg dat ‘de markt’ uit het oog wordt verloren onder de druk om te voldoen aan alle wet- en regelgeving. Nu organisaties een enorme voortgang hebben geboekt om te voldoen aan wet- en regelgeving duikt de vraag op: hoe nu verder?

Inleiding

Veel organisaties hebben in het kader van SOX control frameworks opgesteld. Het werken met dergelijke frameworks of controleraamwerken is een uitstekend hulpmiddel gebleken om blijvend te voldoen aan de SOX-regelgeving. Punt is echter dat deze frameworks meestal niet geschikt zijn gemaakt om naast compliance ook gebruikt te worden om het daadwerkelijk presteren van de IT inzichtelijk te maken. Hiervoor worden weer andere hulpmiddelen gehanteerd. In de praktijk zien wij dan ook dat organisaties allerlei verschillende frameworks en methodieken hanteren die alle een grote overlap met elkaar hebben zonder dat ze volledig in samenhang worden gebruikt (ITIL, Cobit, ISO 17799, CMM, ASL, BiSL, etc.).

De volgende stap, ofwel … beyond compliance moet dan ook volgens de auteurs worden gezocht in het combineren en afstemmen van de verschillende frameworks en methodieken. Behalve inzicht geven in de mate waarin wordt voldaan aan wet- en regelgeving, kunnen control frameworks een wezenlijke rol spelen bij het verbeteren van de volledige IT-governance.

C-2007-1-Leenslag-01

Figuur 1. Beyond compliance.

Zoals in figuur 1 wordt weergegeven, is het belangrijk om de balans te vinden tussen het gericht zijn op control en het gericht zijn op de performance van IT. Het enkel en alleen richten op control zal niet meer werken. Immers, IT moet presteren en het management van organisaties stuurt hier ook steeds meer op. Het uitsluitend focussen op performance zal ook niet gaan werken. Het belang van IT is voor organisaties te groot geworden. Tevens is de regelgeving dusdanig dat een organisatie zich het niet kan permitteren geen adequate control op IT te hebben.

Om organisaties een handreiking te geven om de kwaliteit van IT-governance te beoordelen wordt in dit artikel een IT-governancebenadering (aanpak) beschreven waarmee met geaccepteerde methoden de IT-governance inzichtelijk te maken is. Toepassing van deze methoden resulteert in een concreet toepasbaar IT-governance framework waarmee wordt ingespeeld op de toenemende vraag vanuit de praktijk naar een geïntegreerd control framework. Doel van een dergelijk framework is naast compliance ook prestaties van de IT ten aanzien van strategische bedrijfsdoelstellingen inzichtelijk te krijgen.

Beyond compliance

De verwachtingen van organisaties over de kwaliteit van informatievoorziening, functionaliteit, gebruikersgemak en snelheid van oplevering van nieuwe systemen zijn sterk toegenomen. Daarnaast vraagt de snelheid van veranderingen op het gebied van informatietechnologie en de snelheid van veranderingen binnen organisaties om een adequate beheersing van IT-risico’s en de IT-functie. De toenemende afhankelijkheid van informatiesystemen voor de bedrijfsvoering vraagt om IT-processen die zijn afgestemd op de organisatie ([NORE04]). Onder meer ITIL, CMM, BiSL, ASL, Prince2 en de balanced scorecard (BSC) zijn voorbeelden van populaire methoden waarover veel is gepubliceerd en die door veel organisaties zijn omarmd. De nadruk van deze methoden ligt op het verbeteren van de performance (efficiëntie en effectiviteit) van de IT.

Daarnaast bezorgen eisen vanuit de Amerikaanse Sarbanes-Oxley (SOX)-wetgeving managers van aan de Amerikaanse beurs genoteerde bedrijven, slapeloze nachten. Gezien de aandacht die SOX krijgt, zouden we bijna vergeten dat veel dichter bij huis ook belangrijke ontwikkelingen zijn op dit gebied. Zo bestaat in Nederland de code-Tabaksblat, die van toepassing is op in Nederland gevestigde beursgenoteerde vennootschappen. Tabaksblat ziet graag dat organisaties het nodige regelen op het gebied van risicobeheersing en interne controle, maar zwijgt over de praktische invulling hiervan ([Beuc05]).

Bij de interne beheersing en het afleggen van externe verantwoording moeten organisaties naast de algemene wet- en regelgeving ook rekening houden met branchespecifieke voorschriften, zoals de Regeling Organisatie en Beheersing van De Nederlandsche Bank en de Basel II-richtlijnen. Een voorbeeld van andere branchespecifieke voorschriften zijn de FDA-voorschriften voor de farmaceutische industrie ([NORE04]). Daarnaast zijn door het College voor Tarieven in de Gezondheidszorg/Zorgautoriteit in Oprichting (CTG/Zaio) door middel van de Kaderregeling AO/IC (Administratieve Organisatie en Interne Controle) eisen gesteld aan de wijze waarop de Diagnose-Behandeling-Combinaties (DBC’s)-processen rond registratie, validatie en facturering worden ingericht. ICT speelt een cruciale rol bij het implementeren van de kaderregeling ([NORE05]). Over 2006 dient op grond van deze kaderregeling een bestuursverklaring door de zorginstellingen te worden afgegeven. Ten aanzien van deze kaderregeling blijkt in de praktijk behoefte te bestaan aan een concretisering van de automatiseringsaspecten ([NORE06]).

Organisaties worden ‘gedwongen’ om, mede onder invloed van deze (externe) wet- en regelgeving en door de toenemende afhankelijkheid van IT, grip te krijgen op IT-risico’s. Zogenaamde frameworks zijn opgesteld waarin risico’s zichtbaar zijn gemaakt met bijhorende controls. Hierbij worden methoden als Cobit 4.0, ISO 17799 en BS15000 vaak als uitgangspunt genomen. Deze frameworks zijn gericht op de betrouwbaarheid en beveiliging van de IT.

Omdat gedurende de laatste jaren veel tijd en resources zijn geïnvesteerd in het compliant krijgen van organisaties, duikt de vraag op wat de volgende stap is.

Om antwoord te geven op deze vraag wordt in dit artikel ingegaan op een IT-governancebenadering die verder reikt dan alleen wet- en regelgeving en juist is gericht op het management van organisaties, ofwel … beyond compliance.

Wat te doen na(ast) SOX?

Eind 2004 stelden Gartner-analisten dat IT-professionals meer betrokken zullen raken bij de businessoperatie en dat IT-beslissingen aansluiting moeten hebben met de businessstrategie van organisaties. Naast SOX-compliance, of wellicht beter gezegd na SOX-compliance, blijven organisaties zitten met vraagstukken die beperkt of niet worden afgedekt tijdens SOX-trajecten. Organisaties ervaren problemen op IT-gebied en willen dat deze worden opgelost ([Fijn06]). Enkele vragen die zij stellen zijn:

  • Is de geselecteerde IT-leverancier betrouwbaar?
  • Levert het geld op als we deze IT-investeringen verrichten?
  • Kan ik op verantwoorde wijze werken met de output uit dit systeem?
  • Is mijn IT-manager geschikt en beschik ik over een capabele IT-organisatie?

Bovenstaande onderwerpen zijn vraagstukken op het gebied van de volledige IT-governance van een organisatie. Hierbij gaat het niet alleen om het beoordelen van operationele systemen, maar juist ook om tactische en strategische vraagstukken.

Uit onderzoek naar het beleid van Nederlandse organisaties, om de toepassing van IT effectief te sturen en te controleren, blijkt dat IT-governance de laatste jaren volop in de belangstelling staat. Helaas is de kwaliteit van IT-governance in veel gevallen nog ontoereikend. Slechts 22 procent van de CIO’s karakteriseert de kwaliteit van de eigen IT-governance als goed ([Gian04]).

Dat het onderwerp IT-governance populair is blijkt ook wel als wordt gekeken naar de intentie om deze te verbeteren. Zeker vier op de vijf Nederlandse organisaties wil de kwaliteit ervan op een hoger plan brengen. Elke organisatie die zich realiseert dat de kwaliteit nu onvoldoende of matig is, wil snel actie tot verbetering ondernemen. Ook organisaties waar de IT-governance nu op orde is, willen de kwaliteit nog verder verhogen om meer grip op IT te krijgen ([Gian04]). Echter, veel organisaties weten nog niet hoe ze dit vraagstuk moeten aanpakken.

De auteurs van dit artikel zien ook in de eigen praktijk dat binnen organisaties op diverse plekken vanuit verschillende perspectieven (Raad van Bestuur, lijnmanagement, wet- en regelgeving, accountants maar ook voor interne doeleinden) IT-governance frameworks zijn ontwikkeld en ingebruikgenomen. Medewerkers worden hierdoor meermalen benaderd om min of meer dezelfde vragen te beantwoorden. Tevens zien de auteurs dat:

  • de vragen niet altijd voor de specifieke medewerker van toepassing zijn;
  • onduidelijk is welke IT-componenten het betreft;
  • het invullen van de vragen veelal handmatig moet gebeuren.

Een organisatie in de directe omgeving van de auteurs heeft te kampen met bovengenoemde problematiek; voor de belangrijkste general IT controls is binnen de organisatie een control framework in gebruik. Het belangrijkste commentaar van de medewerkers op dit framework luidde:

  • De gehanteerde terminologie sluit niet aan bij de dagelijkse praktijk (beperkte integratie met de IT-processen).
  • Risico’s en bijbehorende maatregelen zijn algemeen verwoord.
  • Maatregelen zijn niet toegekend aan verantwoordelijke personen en niet gerelateerd aan de IT-componenten.

Deze organisatie heeft daarom besloten een geïntegreerd metamodel te ontwikkelen waarin alle in gebruik zijnde frameworks kunnen worden ondergebracht. Tevens dient vanuit dit metamodel een relatie te kunnen worden gelegd met de ‘werkelijkheid’ (onder meer IT-processen en rollen, hard- en softwarecomponenten en IT-leveranciers).

Eén van de belangrijkste doelstellingen voor de betreffende organisatie is om de kosten voor het up-to-date houden van het framework te gaan reduceren door te kiezen voor een geïntegreerde benadering en zoveel mogelijk de maatregelen te gaan automatiseren. Door de koppeling van het framework met de werkelijkheid te maken worden aan de medewerkers alleen die maatregelen toebedeeld waarvoor zij verantwoordelijk zijn en is bekend op welke IT-componenten de maatregelen betrekking hebben.

De belangrijkste kenmerken van het toegepaste model bij de organisatie zijn:

  • Risico’s en bijbehorende maatregelen zijn geïntegreerd met de (IT-) processen.
  • De mate van volwassenheid van de maatregelen en IT-processen kan worden aangegeven.
  • De relatie kan worden gelegd met de hard- en softwarecomponenten alsmede het besturings- en organisatiemodel.
  • De relatie kan worden gelegd naar de standaardmethoden / frameworks.

Op basis van onderkende risico’s van de betrouwbaarheid van de IT is het nieuwe model in samenwerking met de betrokken medewerkers uitgewerkt. Hierbij zijn Cobit en ValIT als uitgangspunt genomen. Belangrijkste verbeteringen die hiermee zijn behaald, betreffen de aansluiting met de IT-processen en het feit dat medewerkers alleen die risico’s en maatregelen toebedeeld krijgen waarvoor zij verantwoordelijk zijn. De komende periode worden de in gebruik zijnde frameworks geïntegreerd tot één framework. In dit framework worden de risico’s en maatregelen ondergebracht en gerelateerd aan de IT-componenten. Tevens wordt het framework ingevoerd in een geautomatiseerde tool.

Het is niet verwonderlijk dat veel organisaties zitten met vraagstukken over IT-governance en control frameworks. Het is voor organisaties alleen niet altijd even duidelijk wat wordt bedoeld met IT-governance en control frameworks, en hoe men die moet toepassen. Vaak wordt gezocht naar pasklare IT-governancebenaderingen zoals Cobit. Het is echter verstandiger om eerst na te gaan wat men wil bereiken en hoe men IT-governance kan toepassen. Daar komt (helaas) net iets meer bij kijken dan googelen naar de nieuwste Cobit-versie en deze op de organisatie loslaten. Uit eigen onderzoek van KPMG blijkt dat minder dan twintig procent van de organisaties methoden als Cobit en ITIL effectief toepast ([Doug05]).

Om in te spelen op de behoefte vanuit de praktijk heeft Leenslag onderzoek gedaan naar bovenstaand onderwerp. Daarbij heeft hij vanuit de theorie een IT-governancebenadering (metamodel, framework, beoordelingen) ontwikkeld waarmee de kwaliteit van IT-governance kan worden beoordeeld, gebaseerd op geaccepteerde methoden. Het nut van een dergelijke benadering is tweeledig. Allereerst kan zij gebruikt worden als overdraagbare methode om betrokkenen zoals IT-auditors een handreiking te geven bij het beoordelen van de kwaliteit van IT-governance. Daarnaast werkt de benadering als communicatiemiddel richting organisaties om aan te geven hoe zij ‘in control’ (kunnen) blijven van hun IT. Deze benadering moet generiek worden opgezet om toepasbaar te zijn bij meerdere organisaties, maar specifiek genoeg om eenvoudig te implementeren. Generiek en specifiek zijn van nature elkaars aartsrivalen en met dit spanningsveld moet doordacht worden omgegaan. Een generieke benadering zal altijd bij een organisatie specifiek gemaakt moeten worden (ofwel relateren aan de werkelijkheid).

Gebaseerd op de resultaten uit dit onderzoek wordt in dit artikel een IT-governancebenadering gepresenteerd waarmee organisaties in staat worden gesteld om de kwaliteit van IT-governance inzichtelijk te krijgen om op bovengenoemde ontwikkelingen uit de praktijk in te springen.

IT-governance: een definitie

NOREA beschrijft dat de essentie van governance het goed besturen van organisaties is en het aantoonbaar maken dat dit ook zo gebeurt. Kort gezegd gaat het erom:

  • wat goed bestuur inhoudt;
  • hoe daarop adequaat kan worden toegezien;
  • hoe daarover verantwoording kan worden afgelegd aan de belanghebbenden (ook wel stakeholders genoemd).

De organisatieleiding moet in de meeste gevallen richting de belanghebbenden aantoonbaar kunnen maken dat zij de bedrijfsprocessen beheerst ([NORE04]). Het onderdeel IT-governance geeft aan hoe een organisatie de activiteiten bestuurt of beheerst die verband houden met IT en het gebruik daarvan ([Park04]).

Ondanks vele publicaties (waaronder die van NOREA) hebben, zoals eerder aangegeven, veel organisaties nog geen duidelijk beeld van wat IT-governance precies inhoudt. Het probleem om IT-governance te omschrijven begint al bij het zoeken van een toepasbare definitie. In de literatuur worden door verschillende auteurs en verschillende instanties definities gegeven over IT-governance. Deze definities hebben overeenkomsten maar ook verschillen, en daarmee ontstaat al de verwarring over het onderwerp. Een eerste handicap voor organisaties die beginnen met een verkenning op het gebied IT-governance.

Toch is het interessant om een aantal definities (o.a. Weill et al., Van Grembergen en het IT Governance Institute (ITGI)) te bestuderen en daaruit de samenhang en essentie te vinden van IT-governance. Hieruit blijkt dat de volgende, abstracte, termen veel worden gebruikt om IT-governance te beschrijven: (1) structuren, (2) mechanismen en (3) processen. Deze termen representeren belangrijke concepten en hulpmiddelen voor de toepassing, implementatie en ontwikkeling van IT-governance. Deze concepten en hulpmiddelen zijn door Leenslag gebruikt als doelstelling bij het ontwikkelen van een IT-governancebenadering. Doel is dus om op een gestructureerde manier de kwaliteit van IT-governance-gerelateerde processen in kaart te brengen gebruikmakend van mechanismen (methoden). Een ander begrip dat in de literatuur als essentieel wordt gezien voor effectieve IT-governance is control. Dit onderwerp wordt als kader gebruikt van waaruit naar IT-governance gekeken wordt.

Voor een goede omschrijving van IT-governance hoeft overigens niet zo ver gezocht te worden. Brand et al. ([Bran04]) geven een heel bondige beschrijving van het begrip. Zij stellen dat IT-governance ervoor dient te zorgen dat de IT aansluit op bedrijfsprocessen en dat deze op de juiste manier wordt georganiseerd, bestuurd en beheerst. IT-governance verschaft de structuur die een link legt tussen IT-processen, IT-resources en informatie met de organisatiestrategie en -doelen. In een paar zinnen geven zij de essentie van IT-governance heel duidelijk weer.

IT-governancebenadering

Met een goede definitie in het achterhoofd is door Leenslag een IT-governancebenadering ontwikkeld die organisaties in staat stelt inzicht te krijgen in de kwaliteit van de IT-governance ([Leen06]). Hiervoor zijn eerst bestaande IT-governancebenaderingen, van bekende auteurs en instanties, bestudeerd en vergeleken ter inspiratie van de eigen benadering. De globale stappen bij de toepassing van de ontworpen IT-governancebenadering zijn in figuur 2 weergegeven. In het vervolg van dit artikel zullen de verschillende onderwerpen hiervan worden uiteengezet.

C-2007-1-Leenslag-02

Figuur 2. Toepassing IT-governancebenadering.

Metamodel

Bij bestudering van bestaande benaderingen blijkt al snel dat het vergelijken van deze verschillende IT-governancebenaderingen zonder een uniforme structurering zeer moeilijk is, aangezien elke benadering anders is beschreven. Gekozen is om een multi-dimensionaal metamodel op te zetten om IT-governancebenaderingen te structureren. Hiervoor zijn drie dimensies geïdentificeerd die worden gebruikt als invalshoeken van IT-governance. Deze dimensies zijn de wie, wat en hoe van IT-governance, beschreven door Broadbent ([Broa03a] en [Broa03b]). Dallas breidt de dimensies van Broadbent uit door invulling te geven aan deze componenten. De wat vertaalt zij naar de domeinen van IT. De wie geeft de stakeholders aan die belanghebbend zijn ([Dall02]). De hoe wordt door Broadbent gekoppeld aan mechanismen. Het ontworpen metamodel is een driedimensionaal model (kubus) waarbij elke zijde een dimensie van IT-governance representeert. Een voorbeeld van een toepassing van dit metamodel is weergegeven in figuur 3. Bij IT-governancebeoordeling kan eenieder zelf bepalen hoe hij of zij deze dimensies invult.

Met de uniforme structurering (metamodel) is het tijdens het onderzoek mogelijk geweest om een drietal bestaande IT-governancebenaderingen te vergelijken. Daaruit zijn de volgende bevindingen gekomen: (1) De benadering zoals beschreven door Weill et al. richt zich voornamelijk op de beslissingen die genomen moeten worden. In tegenstelling tot (2) de benadering van het ITGI wordt door Weill et al. niet uitvoerig gesproken over de uit te voeren processen. Dit is juist een sterk punt van het Cobit-framework, ontworpen door het ITGI. (3) De benadering beschreven door Thiadens bevat concrete methoden (zoals ITIL en Prince2) ([Thia04], [Thia05]). Daarnaast maakt deze benadering een duidelijk onderscheid tussen de vraag- en de aanbodorganisatie, wat weer niet expliciet gedaan wordt in de benadering van het ITGI. Met gebruik van het metamodel is het mogelijk de voor- en nadelen van verschillende IT-governancebenaderingen helder te krijgen.

Methodische invulling van het model

Voor het onderzoek zijn de drie eerder besproken dimensies in het metamodel ingevuld zoals weergegeven in figuur 3.

C-2007-1-Leenslag-03

Figuur 3. Metamodel IT-governancebenadering Leenslag (2006).

In het domein dat beschrijft wat belangrijk is voor IT-governance zijn processen geïdentificeerd die invloed hebben op de kwaliteit van IT-governance. De IT-aspecten geven in deze context IT-gerelateerde onderwerpen weer die relevant zijn voor organisaties. Bij bovenstaande benadering wordt gebruikgemaakt van verschillende perspectieven om te voorkomen dat een beoordeling van processen en IT-aspecten maar vanuit één oogpunt plaatsvindt. Op deze manier is een benadering gecreëerd waarbij alle relevante perspectieven evenwichtig behandeld worden bij beoordelingen.

De domeinen worden methodisch ingevuld door best practices (bijvoorbeeld ITIL), standaarden (bijvoorbeeld ISO 17799) en frameworks (bijvoorbeeld Cobit). De keuze van methoden maakt het mogelijk een organisatiespecifieke benadering te creëren.

Als laatste zijn de verschillende stakeholders belangrijk bij de toepassing van een IT-governancebenadering, zoals de Raad van Bestuur, lijnmanagement en de IT-verantwoordelijken.

Framework

In figuur 4 wordt een framework gepresenteerd dat concreet is ingevuld met methoden uit de literatuur. Dit framework is de leidraad om beoordelingen mogelijk te maken en is een directe vertaling van het abstracte metamodel naar een concreet toepasbaar framework. Hier zijn de IT-processen gestructureerd binnen aandachtsgebieden van Cobit. Daarnaast zijn de perspectieven van de IT-balanced scorecard herkenbaar, die de vier windstreken van het framework aangeven. Andere beheersingsmethoden zorgen voor verdere invulling van het framework. Het framework representeert op een concrete manier de eerdergenoemde IT-governanceconcepten en -hulpmiddelen. Het is een gestructureerd framework dat gebruikmaakt van mechanismen (methoden) om processen te beoordelen.

Deze concrete invulling kan per organisatie verschillen. Tijdens het onderzoek heeft Leenslag ([Leen06]) ervoor gekozen deze methoden te gebruiken zodat het framework breed inzetbaar is bij verschillende organisaties. Dit framework kan weer gekoppeld worden met de werkelijke situatie van de organisatie. De relatie met objecten (rekencentra, technische infrastructuur, applicaties, informatie en de bedrijfsprocessen) is de organisatiespecifieke vertaalslag die gedaan moet worden, al naargelang de behoeften van de organisatie.

De toegevoegde waarde van dit framework ten opzichte van bestaande frameworks, uit de literatuur, is dat expliciet onderscheid wordt gemaakt tussen de vraag- en aanbodorganisatie in combinatie met Cobit-processen. Sterke kant van de ontworpen IT-governancebenadering is dat processen methodisch ingevuld worden om IT-gerelateerde onderwerpen (IT-aspecten) te ondersteunen, zoals functioneel beheer (dat niet expliciet aan bod komt in Cobit), beveiliging en projectmanagement.

C-2007-1-Leenslag-04

Figuur 4. IT-governance framework in de organisatie gepositioneerd.

Bij de keuze van de gebruikte methoden zijn de gangbaarheid ervan en het af te dekken gebied leidraad geweest. Bovenstaande methoden zijn te rubriceren in drie categorieën: (1) methoden die de vraag- en aanbodorganisatie ondersteunen (algemene aspecten), (2) methoden die specifieke IT-aspecten ondersteunen, (3) methoden die beoordelingen en evaluaties mogelijk maken.

Normenkader

Het resultaat van de toepassing van methoden op dit framework is een IT-governancenormenkader met ongeveer tweehonderd normen (tabel 1). Dit normenkader vormt de concrete vertaling van het IT-governance framework (ingevuld door methoden) naar normen. Het normenkader stelt IT-auditors in staat de kwaliteit van IT-governance bij organisaties te beoordelen. Organisaties kunnen het IT-governancenormenkader tevens gebruiken bij het inrichten van hun IT-governancestructuur en bij het uitvoeren van (self)assessments. De normen zijn opgezet voor organisaties die zeer afhankelijk zijn van de inzet en het gebruik van IT. Zij zijn ontleend aan de verschillende methoden, waarbij het volwassenheidsniveau, volgens het CMM-concept, relatief hoog ligt (niveau 3).

C-2007-1-Leenslag-t1

Tabel 1. Voorbeeld norm.

Beoordeling: scores, analyse en conclusies

Nadat in het voorgaande de verschillende top-down vertaalslagen zijn beschreven, volgt nu de beschrijving van de stappen die de bottom-up activiteiten betreffen. Hierbij gaat het om de daadwerkelijke beoordeling. De focus van het normenkader ligt op het vergelijken van de feitelijke situatie met de norm. Een andere toepassing is de mogelijkheid om verschillende analyses uit te voeren. Met het toewijzen van scores (tabel 2) aan de normen kan een beoordeling worden gemaakt. Wanneer het IT-governancenormenkader volledig is ingevuld, kan een uitspraak worden gedaan over de kwaliteit op verschillende manieren:

  • Een uitspraak kan worden gedaan over de kwaliteit van processen binnen de aandachtsgebieden.
  • Een uitspraak kan worden gedaan over de kwaliteit van verschillende aspecten (in combinatie met de processen).
  • Een uitspraak kan worden gedaan over de verhouding van perspectieven. Waarbij beoordeeld wordt of de organisatie te weinig of te veel aandacht besteedt aan één of meer perspectieven (in combinatie met IT-aspecten en/of aandachtsgebieden).

C-2007-1-Leenslag-t2

Tabel 2. Scores norm.

Wanneer bijvoorbeeld slecht wordt gescoord op een aantal perspectieven in een bepaald aandachtsgebied, dan duidt dat onder andere op een matige integratie van IT-strategie met bedrijfsdoelen en matig beheer van de Information System (IS)-portfolio.

Om het nut van bovenstaande IT-governancebenadering te demonstreren wordt hieronder een tweetal analyses gegeven van de toepassing van de benadering. In deze casestudy (uitgevoerd tijdens het onderzoek) is aan de geïnterviewde gevraagd om zijn eigen organisatie te beoordelen. De casestudy geeft een voorbeeld van een uitwerking van het volledige traject zoals weergegeven in figuur 2. Bij toepassing kan de IT-auditor helpen om een onafhankelijk en onpartijdig oordeel te geven over de scores.

Voorbeeld 1

Figuur 5 geeft de toegewezen scores gerangschikt per IT-aspect weer. Sterk punt van deze analyse is dat zij heel expliciet de onderscheiden IT-aspecten laat zien. De meerwaarde van deze analyse ten opzichte van het gebruik van Cobit is, dat nu expliciet gemaakt wordt waar zich problemen voordoen (op welk IT-onderdeel). In dit specifieke voorbeeld is te zien dat applicatiebeheer minder goed scoort ten opzichte van functioneel beheer en technisch beheer. Bij een beoordeling van alleen de Cobit-processen of -aandachtsgebieden is zonder verder onderzoek niet helder of problemen zich bijvoorbeeld bevinden in de vraag- of in de aanbodorganisatie.

C-2007-1-Leenslag-05

Figuur 5. Scores per IT-aspect.

Voorbeeld 2

In figuur 6 zijn de scores per Cobit-aandachtsgebied en -perspectief weergegeven. Het aandachtsgebied Plan & Organise (PO) behandelt de strategie en de tactische vraagstukken en onderzoekt hoe IT het beste kan bijdragen tot het halen van bedrijfsdoelstellingen. Het aandachtsgebied Acquire & Implement (AI) identificeert IT-oplossingen die nodig zijn om bedrijfsdoelstellingen te realiseren. Daarnaast is dit aandachtsgebied verantwoordelijk voor het bouwen, aankopen en implementeren van de oplossingen. Het aandachtsgebied Deliver & Support (DS) behandelt vraagstukken rond de eigenlijke levering van IT-diensten, zoals het beheer van data en de operationele afdelingen ([Stev06]). In het aandachtsgebied Plan & Organise zijn er bepaalde perspectieven die matig scoren. Bij bestudering blijkt dat met name de aanbodorganisatie ‘verantwoordelijk’ is voor de lage scores. In figuur 5 was al te zien dat applicatiebeheer minder goed scoorde. De matige score van applicatiebeheer zit voornamelijk in het (strategische en tactische) aandachtsgebied Plan & Organise. Het tweede wat opvalt in figuur 6 is de hoge score van de ‘extern’ gerichte perspectieven in het aandachtsgebied Acquire & Implement. Dit toont onder meer aan dat de aansluiting van individuele applicaties/systemen met behoeften vanuit de gebruikersorganisatie hoog is. Tevens worden gebruikers voldoende betrokken als het gaat om onderwerpen zoals wijzigingsbeheer. De conclusie die uit deze twee observaties kan worden getrokken, is dat de ontwikkelde/gewijzigde IT-systemen van goede kwaliteit zijn en aansluiten op bedrijfsbehoeften (per product), maar dat de totale integratie van informatiesystemen (IS) met de IT-strategie nog onvoldoende bijdraagt aan de doelstellingen van de organisatie. Eenvoudig gezegd ontwikkelen ze goede, opzichzelfstaande systemen die onvoldoende geïntegreerd zijn. Vanuit het aandachtsgebied Plan & Organise zijn voor deze organisatie nog verbeterpunten te bedenken.

C-2007-1-Leenslag-06

Figuur 6. Score per Cobit-aandachtsgebied en -perspectief.

Conclusie

Veel tijd en resources zijn de afgelopen jaren gestoken in het SOX-compliant (in control) krijgen van organisaties. Nu is er weer de ruimte om verder te kijken dan alleen compliance. Frameworks die in het kader van SOX zijn ontwikkeld, dienen te worden uitgebreid tot een geïntegreerd framework dat naast het voldoen aan wet- en regelgeving gericht is op de betrouwbaarheid van de informatie en de performance van IT. Hierbij is het zaak om in te spelen op managementvraagstukken gericht op de volledige IT-governance van organisaties.

In dit artikel is een benadering gepresenteerd om de kwaliteit van IT-governance bij organisaties te beoordelen en verder te verbeteren. Dit artikel geeft een handreiking om beoordelingen van IT-governance overdraagbaar te maken en om het onderwerp concreet bespreekbaar te maken bij en/of binnen organisaties. In het gepresenteerde framework is een aantal bekende methoden toegepast en deze dienen als voorbeeld voor dit artikel. De lezer is vrij om dezelfde methoden of andere methoden (bijvoorbeeld CMM) toe te passen om zo een eigen IT-governance framework te creëren met een eigen normenkader. Andere (IT-) aspecten (ingevuld door methoden) kunnen worden toegevoegd om het framework toepasbaar te maken voor organisaties, waarbij het gepresenteerde metamodel en framework als uitgangspunt kunnen worden gebruikt.

Een sterk punt van de gepresenteerde, trapsgewijze, IT-governancebenadering is dat het een top-down aanpak kent bij het vertalen van abstracte, strategische doelen naar concrete, formele normen. Daarnaast biedt het de mogelijkheid voor een bottom-up analyse om de vertaalslag te maken van scores (van normen) naar conclusies en uitspraken over de kwaliteit van IT-governance op strategisch niveau.

Literatuur

[Beuc05] Drs. R.J.J. van den Beucken RE, drs. P.P.M.G.G. Brouwers RE RA en M.W. Little RA, Tabaksblat: van code naar ‘in control’ in de praktijk, Compact 2005/2.

[Bran04] K. Brand en H. Boonen, IT Governance: A pocket guide, based on COBIT, Van Haren Publishing, Zaltbommel 2004.

[Broa03a] M. Broadbent, A Clear and present Objective, CIO, St Leonards, May 2003.

[Broa03b] M. Broadbent, The Right Combination, CIO, St Leonards, April 2003.

[Dall02] S. Dallas, Six IT Governance rules to boost IT and user credibility, Oct 31, 2002, Gartner, url (20-02-2006): http://facweb.cs.depaul.edu/nsutcliffe/483readings/3-6- ITGovernanceRulesToBoostITnUserCredibility.htm

[Doug04] T.R. Dougherty, Creating stakeholder value in the information age: The case for Information Systems Governance, 2004; www.kpmg.nl/it > IT Governance > publicaties en whitepapers.

[Fijn06] R. Fijneman, IT-auditor is meer dan controleur van informatietechnologie, MAB, 2006.

[Gian06] J. Gianotten, Governance van IT en outsourcing, Kennisplatform Topmanagement & IT, 2004.

[ITGI06] ITGI, CobiT4.0 beschikbaar op: www.itgi.org

[Grem04] W. van Grembergen, S. de Haes en E. Guldentops, Structures, Processes and Relational Mechanisms for IT Governance, in: Grembergen (Ed), Strategies for Information Technology Governance, Idea Group Publishing, 2004.

[Leen06] W. Leenslag, Werkwijze ter beoordeling van IT Governance, Scriptie, Universiteit Twente, 2006.

[NORE04] NOREA, IT Governance, een verkenning, 2004; te downloaden van www.norea.nl

[NORE05] NOREA, ZekeREzorg: beoordelingskader gegevensverwerking DBC’s, 2005; te downloaden van www.norea.nl

[NORE06] NOREA, ZekeREzorg (2): beoordelingskader AWBZ productieregistratie en facturering, 2006; te downloaden van www.norea.nl

[Park04] H. Parkes, IT Governance and outsourcing, Information Systems Control Journal; Volume 5, 2004.

[Stev06] F. Stevens, W. van Grembergen en S. de Haes, ITIL en CoBiT en hun toepassing op SOX, Informatie, december 2006.

[Thia04] T. Thiadens, Sturing en organisatie van ICT-voorzieningen, Van Haren, 2004.

[Thia05] T. Thiadens, Manage IT, Springer, Dordrecht 2005.

[Webb06] P. Webb, C. Pollard en G. Ridley, Attempting to define IT Governance: Wisdom or Folly?, Proceedings of the 39th Hawaii International Conference on System Sciences, 2006.

[Weil02] P. Weill en R. Woodham, Don’t Just Lead, Govern: Implementing Effective IT Governance, MIT CISR WP No. 326, MIT Sloan School of Management, April 2002.

[Weil04a] P. Weill en J.W. Ross, IT governance: how top performers manage IT decision rights for superior results, Boston, Harvard Business School Press, 2004.

[Weil04b] P. Weill en J.W. Ross, IT Governance on one page, MIT CISR WP No. 349, MIT Sloan School of Management, November 2004.

[Weil04c] P. Weill, Don’t Just Lead, Govern: How top-performing firms Govern IT, MIT CISR WP No. 341, MIT Sloan School of Management, March 2004.

SOX IT eerste praktijkervaringen en toekomstige ontwikkelingen

In dit artikel wordt stilgestaan bij de SOX-ervaringen en -ontwikkelingen die beide auteurs waarnemen op het IT-vlak bij de grotere SOX-plichtige bedrijven, de zogenaamde ‘domestic’ en ‘foreign private issuers’. We zien dat er diverse regelgeving over de afgelopen jaren is opgesteld en bedrijven bijna voortdurend zijn geconfronteerd met veranderende interpretaties van de PCAOB-auditingstandaard nr. 2 ([PCAO04]). Dit heeft in de praktijk geleid tot een grote hoeveelheid beheersingsmaatregelen die de bedrijven hebben geïmplementeerd en die veelal niet efficiënt op elkaar zijn afgestemd. We constateren dat er een duidelijke tendens waarneembaar is om de kosten terug te brengen door slimmere scoping, combineren en vereenvoudigen van beheersingsmaatregelen, betere ondersteuning door tools en het integreren van controleraamwerken. Hier wordt nader op ingegaan in dit artikel. Ten slotte wordt kort stilgestaan bij de mogelijke impact van de concept-auditingstandaard van de PCAOB ([PCAO06]). Deze nieuwe standaard (AS-5) is aangepast naar aanleiding van de ervaringen uit de praktijk en zal de huidige (AS-2) vervangen.

Inleiding

Dit artikel bestaat grofweg uit drie onderdelen. In de eerste plaats wordt stilgestaan bij de SOX-ervaringen en -ontwikkelingen op het gebied van IT vanuit de wet- en regelgeving en gezaghebbende instanties. Hierbij wordt aangegeven welke IT in dit verband relevant is en hoe met specifieke vraagstukken moest worden omgegaan. Vervolgens worden de ontwikkelingen vanuit de praktijk, met name gericht op de kosten van compliance, besproken. Ook komen hierbij aan de orde de mogelijkheden om beter inzicht te krijgen in de kosten en het integreren van frameworks. In de derde plaats wordt richting de toekomst stilgestaan bij recente ontwikkelingen, zoals de impact van de recente voorstellen van de PCAOB en de SEC, gericht op de IT-aspecten. De indeling is als volgt:

  • Ervaringen IT en SOX vanuit wet- en regelgeving
    • Applicatie- en IT general controls
    • Guidance vanuit Cobit (2004-2006)
    • Evaluatie van tekortkomingen (framework 2004)
    • PCAOB 16 mei 2005 guidance.
  • Ervaringen vanuit de organisaties
    • Centrale versus decentrale benadering
    • Compliancekosten en control transformation
    • Framework integration
    • Ondersteunende SOX-tools.
  • Toekomstige ontwikkelingen
    • Recente guidance PCAOB en SEC.

Ervaringen IT en SOX vanuit de wet- en regelgeving

Applicatie- en IT general controls

Bij een terugblik op de SOX-ontwikkelingen is het van belang om de relevante IT hierbinnen vast te stellen. Binnen SOX staat de beheersing van de bedrijfsprocessen ten behoeve van de financiële verantwoording centraal. De IT ondersteunt deze processen en zal daarmee ook voldoende moeten worden beheerst. Voor de gehele beheersing van een organisatie wordt meestal het COSO-model[Dit model zal in dit artikel niet verder worden uitgewerkt, maar wordt als bekend verondersteld.] als beheersingsraamwerk gehanteerd; zie daarvoor ook gerelateerde artikelen in eerdere Compacts. Binnen IT zijn de relevante IT controls in een organisatie in drie categorieën te onderscheiden:

  1. organisatiebrede controls (COSO-component Control Environment);
  2. applicatiecontrols (input-outputcontrols, validation rules, toleranties, autorisaties, interfacecontrols, IT dependent controls …);
  3. algemene IT controls (Change Management, Security Management, …).

De laatste twee soorten controls hebben een (in)directe relatie met de bedrijfsprocessen en worden vanuit de geïdentificeerde risico’s in de processen geselecteerd. Hierbij worden de applicatiecontrols direct in de processen geïdentificeerd en zijn de algemene IT controls gericht op de IT-componenten (zoals databases, operating systems, netwerk, …) die de werking van deze applicatiecontrols waarborgen.

Applicatiecontrols (hierna AC) zijn op diverse plaatsen in en rondom de applicaties aanwezig, soms geheel geautomatiseerd en soms gedeeltelijk. Dit maakt het identificeren van de AC niet altijd eenvoudig. Binnen de SOX-wetgeving zijn niet alle AC relevant. Om te komen tot een juiste set van AC dienen vanuit de beweringen in de financiële verantwoording, de bedrijfsprocessen te worden geïdentificeerd die een belangrijke (significante) bijdrage leveren aan de standen en stromen in deze verantwoording. Vervolgens zal het management de risicopunten in de bedrijfsprocessen bepalen, gebaseerd op mogelijke significante onjuistheden in de verantwoording. Deze risicopunten worden beheerst door middel van zogenaamde key controls, dit kunnen AC zijn. De goede werking van de AC moet door het management worden aangetoond. Indien een AC niet goed werkt, is het risicopunt niet voldoende beheerst en volgt een proces van het identificeren/testen van compenserende controls of het herstellen van controls en/of het bepalen van de mogelijke fout in de financiële verantwoording.

C-2007-1-Francken-01

Figuur 1. Scoping van kritieke financiële rapportageapplicaties.

Het is in dit verband van belang dat de diverse onderdelen in de organisatie (business-IT-kant) nauw samenwerken. Dit geldt uiteraard ook voor de samenwerking tussen de IT-auditor en de financial auditor. Indien de samenwerking ontbreekt, is er een risico dat er te weinig relevante AC worden geïdentificeerd, maar het omgekeerde is ook mogelijk. Indien systemen geïsoleerd worden beschouwd, kan het goed zijn dat er daadwerkelijk, op het eerste gezicht belangrijke, AC aanwezig zijn in de betreffende systemen. Maar op andere plekken en in andere systemen kunnen vergelijkbare beheersingsmaatregelen aanwezig zijn, waardoor de gevonden AC niet getest hoeven te worden. Zo kan de feitelijke voorraad in depotsysteem A worden geregistreerd in hoeveelheden en wordt de financiële waarde in ERP-systeem B vastgelegd. Periodiek vindt er een inventarisatie van het depot plaats en wordt de waarde in B vastgelegd en via dit systeem verwerkt in de depotsystemen A. Met behulp van de inventarisatie en de registratie in systeem B zijn er mogelijk geen relevante AC in A. Dit systeem zit dan niet in de SOX-scope. Hetzelfde geldt voor systemen die weliswaar financiële data registreren, maar geen materieel financieel effect kunnen hebben op de financiële verantwoording.

Vervolgens zijn de aanwezige risicoanalyse en de applicatiecontrols het startpunt voor het bepalen van de IT general controls (hierna ITGC). Deze relatie is figuur 2 weergegeven.

C-2007-1-Francken-02

Figuur 2. Scoping van kritieke applicatiecontrols en IT general controls.

De ITGC in scope hebben betrekking op de betreffende applicaties en de onderliggende IT-infrastructuur, zoals de betreffende database, het operatingsysteem en het netwerk. Het is in dit verband goed te beseffen dat niet de IT-processen, veelal op ITIL gebaseerd, het vertrekpunt zijn voor de SOX-scope, maar de IT-componenten binnen de genoemde IT-infrastructuur. Deze IT-componenten ondersteunen de goede werking van de AC, die vanuit de bedrijfsprocessen zijn geselecteerd. In de praktijk zien we vaak dat organisaties starten met de implementatie van alle ITIL-processen, voor zover nog niet aanwezig, om aan SOX te kunnen voldoen. Deze aanpak heeft tot gevolg dat relatief veel procedures en standaarden worden opgesteld. Hierbij bestaat het risico dat deze onvoldoende zijn uitgewerkt in ITGC, gericht op de betreffende IT-componenten. De geïmplementeerde set van procedures is weliswaar een belangrijke randvoorwaarde voor goede beheersing, maar de procedures zijn niet of moeilijk testbaar voor het management / de auditors indien de directe relatie met de IT-componenten ontbreekt ([Korn05]).

Guidance vanuit Cobit (2004-2006)

In de praktijk is er veel discussie geweest met betrekking tot de ITGC die in scope zouden moeten zijn voor SOX. De PCAOB heeft de IT-gebieden aangegeven en vanuit de AC kunnen de IT-componenten binnen de IT-infrastructuur worden onderscheiden, zoals databases, etc., maar welke ITGC zijn hierbinnen relevant? Zijn dit alle domeinen binnen Cobit of de meest gangbare ITIL-processen? Het IT Governance Institute (ITGI) heeft hier ondersteuning aan gegeven door vanuit Cobit de specifieke controledoelstellingen voor de ITGC te identificeren ([ITGI04] en [ITGI06]), zie figuur 3.

C-2007-1-Francken-03

Figuur 3. Identificeren van controledoelstellingen en IT general controls.

Vanuit de IT-infrastructuur in scope worden de relevante ITGC geïdentificeerd binnen de relevante IT-beheerprocessen, mogelijk gebaseerd op ITIL, vanuit de twaalf aangegeven controledoelstellingen binnen de vier IT-gebieden van de PCAOB. Afhankelijk van de feitelijke omstandigheden zullen deze ITGC verschillen per organisatie. Binnen de ICOFR wordt de nadruk gelegd op de aanwezige ITGC en niet zozeer op de aanwezige IT-beheerprocessen, hoewel deze wel een randvoorwaarde kunnen zijn om de ITGC in te kunnen richten. Zonder duidelijke IT-beheerprocessen zullen de ITGC vaak niet effectief zijn. Het ‘brede’ IT-beheer kan in dit verband ook worden gezien als een onderdeel van de ‘entity level controls’. Indien IT-beheerprocessen onduidelijk zijn, is er een organisatiebrede tekortkoming.

Evaluatie van tekortkomingen (framework 2004)

Nadat de totale IT-scope langzaam helder werd vanuit de PCAOB- en Cobit-richtlijnen, kwam het vraagstuk inzake het evalueren van tekortkomingen naar voren. Hoe belangrijk is een IT-deficiency? Als specifieke ITGC niet werken, is het lastig om de impact hiervan te bepalen, indien er geen duidelijke relatie is gelegd met de businessprocessen en de daarin opgenomen AC. In overleg met de SEC hebben de grotere accountantskantoren een raamwerk opgesteld om onder andere tekortkomingen in de IT controls te kunnen evalueren ([Fram04]). De applicatiecontrols worden gelijk als de andere ‘process level controls’ beoordeeld, voor de ITGC is een specifiek model ontwikkeld. Samengevat komt dit erop neer dat indien een AC wordt aangemerkt als een ‘significant deficiency’, dit nooit kan leiden tot een ‘material weakness’ in de (algemene) IT control en daarmee tot een afkeurende ‘SOX-verklaring’. Dit onderstreept het belang van het identificeren van de relatie tussen de IT controls ten opzichte van de AC, aan de hand van de IT-componenten. Zoals eerder aangegeven zijn deze IT-componenten onderdelen uit database, netwerk en operatingsysteem die de goede werking van de AC ondersteunen. Binnen de aanwezige IT-infrastructuur zullen de relaties tussen deze IT-componenten moeten worden uitgewerkt, zodat hierop specifiek kan worden getest en tekortkomingen via bovenstaand model kunnen worden geëvalueerd. Met name in grotere IT-omgevingen zal dit een nadere inventarisatie van servers, tabellen, interfaces, etc. tot gevolg hebben. Door deze relaties vooraf gedetailleerd in kaart te brengen kan de totale SOX (en test)-scope aanzienlijk worden beperkt. Daarnaast kan weloverwogen worden besloten enkele ineffectieve IT controls niet op te lossen, bijvoorbeeld indien de betreffende applicatiecontrols wel effectief zijn of slechts een ‘deficiency’.

Bovenstaande betekent niet dat IT controls die geen directe invloed hebben op de goede werking van de applicatiecontrols, niet relevant zouden zijn, omdat zij niet direct kunnen leiden tot een ‘material weakness’. Een veelheid van eventueel kleine tekortkomingen (deficiencies) op één of meer ITGC-gebieden (bijvoorbeeld Access to Programs and Data of Program Changes) duidt op een minder goed beheerste control environment, wat op zich een ‘significant deficiency’ of ‘material weakness’ kan zijn. Deze aggregatie-evaluatie dient ook te worden meegenomen in de totale ‘deficiency evaluation’.

PCAOB 16 mei 2005 guidance

Naar aanleiding van de ervaringen bij de SOX-plichtige ondernemingen in de Verenigde Staten hebben de SEC en de PCAOB additionele richtlijnen uitgevaardigd in ‘Frequently Asked Questions’ en ‘Staff-Policy Statements’, waarvan met name die van 16 mei 2005 een relatief grote impact hadden. In het algemeen was men niet tevreden over de wijze en diepgang hoe de ondernemingen met SOX (en IT) zijn omgegaan. Dit kwam onder meer naar voren in de volgende opmerkingen ([PCAO05]):

  • ‘… for purposes of the Section 404 assessment, the staff would not expect testing of general IT controls that do not pertain to financial reporting …’
  • ‘… in establishing the scope of its IT assessment, management should apply reasonable judgment and consider how the IT systems impact internal control over financial reporting …’

In dit verband heeft de SEC specifiek aangegeven dat een top-down risicobenadering gevolgd dient te worden, waarbij uitsluitend applicaties relevant zijn waarin significante applicatiecontroles zijn opgenomen in relatie tot de financiële verantwoording.

Daarnaast heeft de PCAOB het concept van ‘Baselining – Benchmarking’ van AC verder uitgewerkt. Indien een AC eenmaal is getest op werking en de ITGC zijn solide, zoals change management en system access, dan behoeft de AC niet ieder jaar te worden getest. De PCAOB geeft in dit verband aan: ‘Entirely automated application controls, therefore, are generally not subject to breakdowns due to human failure and this feature allows the auditor to ‘benchmark,’ or ‘baseline’, these controls.’ Dit houdt in dat ‘… the auditor may conclude that the automated application control continues to be effective without repeating the prior year’s specific tests of the operation of the automated application control …’. Het moge duidelijk zijn dat er op voorhand efficiencyvoordelen zijn te behalen indien dergelijke AC niet jaarlijks behoeven te worden getest. De PCAOB heeft hierbij wel een aantal randvoorwaarden gesteld. Afhankelijk van de feitelijke omstandigheden zal de betreffende benchmark periodiek kunnen worden uitgevoerd.

Ervaringen vanuit de organisaties

Centrale versus decentrale benadering in de praktijk

Afgezien van het feit dat in de PCAOB-publicatie van mei 2005 specifiek de nadruk is gelegd op een risk based top-down benadering, is de praktische uitvoering van SOX in het eerste jaar toch vaak decentraal geweest. Een belangrijke oorzaak hiervan is het niet specifiek inzichtelijk hebben van de lokale IT-omgeving op centraal niveau. Dit kwam bij een belangrijk proces voor SOX, het scopen van de IT-applicaties en -infrastructuren, vaak al tot uitdrukking. Dit proces is door veel organisaties en externe auditfirma’s in het eerste SOX-jaar onderschat en onvoldoende concreet gedefinieerd. Niet alleen de onduidelijkheid van de SOX-regelgeving met betrekking tot IT, zoals genoemd in de vorige paragraaf, is hier debet aan, maar ook de onbekendheid met het IT-landschap in het algemeen en al helemaal die delen daarvan die impact kunnen hebben op de financiële rapportageprocessen.

Concreet zijn er twee manieren om het IT-landschap te definiëren voor SOX, namelijk de top-down en bottom-up benadering. Bij de top-down benadering is er inzicht in de key IT-applicaties en -infrastructuren en wordt de IT-scoping gecentraliseerd uitgevoerd. Aangezien op centraal niveau niet altijd bekend is hoe het exacte decentrale IT-landschap eruitziet, hebben veel organisaties het scopen van de IT overgelaten aan de lokale units. Door deze veelal decentrale benadering zijn in eerste instantie ook veel applicaties geïdentificeerd waarbij geen of slechts weinig applicatiecontrols zijn geïdentificeerd of die financieel gezien niet materieel zijn; in beide gevallen zijn deze applicaties dus niet significant. Gedurende het jaar hebben dan vaak ook herscopingen plaatsgevonden om het hoge aantal niet-significante applicaties te beperken binnen de SOX-scope. Hierbij is een aantal (compenserende) manuele controles geïdentificeerd om deze applicaties buiten de SOX-scope te houden. Deze reparatieactie neemt naast de nodige tijd ook de focus op de daadwerkelijk significante IT-applicaties en -infrastructuren weg.

Deze decentrale benadering is ook veelal tot uitdrukking gekomen in de identificatie van de applicatiecontrols. Onbekendheid met verschillende applicaties en het ontbreken van gestandaardiseerde proces-, risico- en controletemplates inclusief duidelijke IT application controls heeft ertoe geleid dat er veel verschillende AC of juist geen AC zijn geïdentificeerd binnen de bedrijfsprocessen. Hierdoor was het op het eerste gezicht ook lastiger om een geheel efficiënte en gecentraliseerde testaanpak te hanteren voor de AC. Ondanks dat de decentraal geïdentificeerde AC verschillend werden beschreven, konden ze vaak herleid worden naar een aantal key application controls per bedrijfsproces. De aanpak voor 2007 zal daardoor ook vanuit deze key application controls per bedrijfsproces ingestoken gaan worden. Niet alleen kan hierdoor meer duidelijkheid worden verschaft over wat de AC nu exact inhouden, maar ook kan een efficiëntere centrale testaanpak worden gedefinieerd en gehanteerd.

Nu na het eerste jaar het IT-landschap, de AC en de testaanpak daadwerkelijk inzichtelijk zijn gemaakt, zullen in 2007 veel organisaties in het kader van SOX een meer gecentraliseerde en top-down benadering implementeren en zo nodig intern en bij hun externe accountants afdwingen.

Compliancekosten verlagen

De meeste organisaties hebben het eerste SOX-jaar een hoge prijs moeten betalen om ‘compliant te geraken. Naast het feit dat de auditfees gestegen zijn en vaak ook een externe adviseur is gevraagd te ondersteunen, hebben de organisaties ook veel interne kosten gemaakt. Het tweede jaar staat bij de meeste organisaties dan ook in het teken om deze total cost of compliance te verlagen door zaken te optimaliseren en te verbeteren. Het probleem is echter, dat de total cost of compliance vaak niet bekend is bij organisaties, doordat het merendeel van de kosten (de interne kosten) niet wordt bijgehouden. In figuur 4 is een illustratie gegeven van de kostenstructuur van een dagelijkse controle. Naast de test- en auditkosten brengt een dergelijke control ook de kosten van de dagelijkse uitvoering met zich mee.

C-2007-1-Francken-04

Figuur 4. Overzicht total costs of compliance van een handmatige control.

De meeste organisaties hebben vaak het eerste jaar initieel de toevlucht gezocht tot manuele controls, waardoor de kosten van SOX onacceptabel hoog kunnen oplopen. Zoals al aangegeven in het artikel ‘Tool-based monitoring en auditing van ERP-systemen’ ([Brou06]) zullen organisaties de komende jaren manuele detective controls vervangen door preventieve controls (applicatiecontrols). Deze preventieve controls hoeven namelijk slechts eenmaal op het bestaan te worden getoetst. Daarnaast behoeft een preventieve controle geen correctieve acties die bij detective controls vaak wel aan de orde kunnen zijn. Verder heeft een AC een belangrijk voordeel: vele daarvan kunnen automatisch worden getest. Wijzigingen aanbrengen in de controls portfolio wordt ook wel ‘control transformation’ genoemd en zal de komende jaren bij veel SOX-organisaties in het teken van optimalisatie staan.

C-2007-1-Francken-05

Figuur 5. De trend: control transformation.

Voor het aanbrengen van wijzigingen in de controlportfolio is behalve overleg tussen het SOX-projectteam, de control owner en de IT-afdeling ook een duidelijke business case nodig. Een dergelijke business case wordt samengesteld op basis van een zogeheten controlportfolio-analyse. De uiteindelijke processen die in aanmerking komen om als eerste aangepakt te worden hebben naast een hoge bijdrage tot kostenreductie ook duidelijke procesoptimalisatiemogelijkheden.

Voordelen controlportfolio-analyse:

  • standaardiseert de classificering van controls;
  • standaardiseert de gekwantificeerde cost of compliance-analyse;
  • ondersteunt het identificeren en prioritiseren van opportunities voor procesoptimalisatie en kostenreductie.

In de markt zijn er nog niet veel generieke tools aanwezig om een dergelijke controlportfolio-analyse uit te voeren. Daarom grijpen veel organisaties naar Excel-georiënteerde tools. De ondersteunende tools die op de markt beschikbaar zijn, onderscheiden vaak een kwantitatieve scan (bottom-up) om de cost of compliance te berekenen op basis van de geïmplementeerde control frameworks in de organisatie en een kwalitatieve scan (top-down) op basis van enquêtes en interviews om de mogelijke procesoptimalisaties te bepalen. De beide aanpakken vormen de basis voor het identificeren van de mogelijke opportunities. In figuur 6 is een voorbeeld van een projectaanpak toegelicht.

C-2007-1-Francken-06

Figuur 6. Voorbeeld aanpak analyse van de controlportfolio. [Klik hier voor grotere afbeelding]

Het uiteindelijke resultaat: de controlportfolio, een onderbouwd impactanalyserapport en de implementatieroadmap.

Framework integration

Bij de organisaties die op een adequate wijze het ICOFR-raamwerk hebben ingericht, zien we dat zij duidelijke stappen zetten richting een transformatie naar een Business Control-raamwerk. Hierdoor kunnen zij de beheersing van de bedrijfsprocessen verbeteren en daarmee daadwerkelijk de vruchten plukken van hun inspanningen. Dit begint bij het uitvoeren van een analyse naar bedrijfsrisico’s, zowel op strategisch als op procesniveau. Centraal daarbij staan alle ‘businessrisico’s’ (van strategische tot operationele risico’s), aangezien de financiële risico’s al in kaart zijn gebracht. Op basis van deze risico’s worden vervolgens Business Controls geïdentificeerd en gedocumenteerd, die daarna kunnen worden ingebed en geoptimaliseerd. Het is raadzaam om na de implementatie van het ICOFR-raamwerk direct door te pakken door niet alleen de financiële beheersingsmaatregelen, maar ook de Business Controls gestructureerd in te richten. SOX heeft immers binnen de organisatie een schat aan kennis, ervaring, tools en draagvlak opgeleverd. Het zou zonde zijn om dat momentum verloren te laten gaan. Deze fase noemen we ook wel Framework integration, waarbij de verschillende control frameworks, gebaseerd op verschillende wet- en regelgeving, worden geïntegreerd en gezocht wordt naar controledoelstellingen en beheersingsmaatregelen die meerdere frameworks afdekken.

C-2007-1-Francken-07

Figuur 7. Control framework integration.

De volgende overwegingen kunnen hierbij een rol spelen:

  • hergebruik van al het verzameld controlebewijs, efficiënter testen van controls;
  • verlaging van de kosten van separate audits;
  • geïntegreerd overzicht van controls en analyse, en efficiëntere monitoring;
  • onderhoudbare (sustainable) compliance.

Ondersteunende SOX-tools

Het eerste SOX-jaar hebben veel organisaties en auditfirma’s nog hun toevlucht genomen tot de ‘flexibele’ wereld van Excel voor de ondersteuning van de SOX-opdracht. Indien echter de organisatie een omvang heeft van meerdere landen en organisatieonderdelen voldoet Excel niet meer. Beperkingen zoals het slechts ten dele kunnen afdwingen van versiebeheer, het werken in een template, het niet met één druk op de knop kunnen monitoren van de voortgang, etc. hebben geleid tot nadenken over ondersteunende SOX-tooling. Maar wat houdt ondersteunende SOX-tooling nu precies in?

Bij de term ondersteunende SOX-tools wordt in eerste instantie gedacht aan de ondersteuning bij de SOX-opdrachtmanaging zelf, namelijk ondersteuning bij SOX-scoping; vastlegging van de procesbeschrijvingen, risico’s en key controls; vastlegging en monitoren van de voortgang van het testwerk; en vastlegging en evaluatie van de deficiencies.

Er zijn echter meerdere typen tooling op verschillende niveaus mogelijk die de organisatie kunnen ondersteunen ([Brou06]). Voor SOX hebben de Operational Risk Management Tools de meeste directe toegevoegde waarde. Binnen dit niveau worden twee typen tools onderscheiden. Op de eerste plaats het monitoren van de key controls (al dan niet IT controls) door de ‘control executors’ binnen de lokale organisaties in een centrale database. Hierdoor is in één oogopslag duidelijk welke controls in scope zijn, welke getest zijn en wat de resultaten hiervan zijn vanuit alle mogelijke invalshoeken. Het tweede type tool faciliteert het automatisch verkrijgen van fact-findings van de werking van applicatie-, autorisatie- en reporting controls uit de systemen. Dit laatste type tools zal mede door de control transformation (de transitie van manuele controls naar applicatiecontrols) en framework integration de komende jaren een grote vlucht gaan nemen. Vooral het op elk moment efficiënt en automatisch met behulp van deze tools kunnen monitoren van de bedrijfsprocessen en hierover kunnen rapporteren zal veel organisaties aanspreken. Indien deze fact-finding tool is dan wel wordt geïntegreerd met de hiervoor genoemde tool ten behoeve van de monitoring van key controls, ontstaat een krachtig en effectief instrument voor de organisatie om enerzijds de financiële reportingprocessen maar anderzijds ook de bedrijfsprocessen te beheersen.

Toekomstige ontwikkelingen

Recente guidance PCAOB en SEC

Op 19 december 2006 heeft de PCAOB een voorstel gepubliceerd om de huidige auditstandaard (AS2) te vervangen ([PCAO06]). De SEC heeft een dag later een ‘guidance paper’ voor het management voorgesteld ([SEC06]). De belangrijkste wijzigingen die van invloed kunnen zijn op de aard en omvang van de IT controls en de hoeveelheid testwerk zijn[Het voorstel van de PCAOB en het guidance paper van de SEC zijn nog in concept en zijn aan review en eventuele aanpassingen onderhevig. De in dit artikel beschreven interpretaties van deze conceptvoorstellen zijn een mening van de schrijvers op persoonlijke titel.]:

  • Er zal een duidelijke focus moeten worden aangebracht op een risico- en top-down gerichte aanpak:
    • Focus op materiële risico’s en het testwerk hierop afstemmen. De audit moet niet gericht zijn op het identificeren van mogelijke ‘significant deficiencies’, maar op de mogelijke ‘material weaknesses’.
    • In dit verband is het begrip susceptibiliteit geïntroduceerd. Er zal meer focus moeten zijn op de relatief zwakke plekken van jaarrekeningposten, transacties en onderbouwingen. Deze plekken kennen een grotere subjectiviteit, complexiteit en fraudegevoeligheid.
  • De auditor hoeft geen verklaring meer te geven bij het ‘management process’. Veelal ontbrak het bij de organisatie aan IT-technische deskundigen om alle IT controls goed te kunnen beoordelen. Hierover hoeft de auditor niet te rapporteren, indien de IT controls effectief zijn.
  • Er kan meer worden gesteund op verricht werk en ervaringen uit het verleden, waardoor het testwerk kan worden verminderd. Maar het roteren van tests, met andere woorden het spreiden van de testwerkzaamheden over meerdere jaren (bijvoorbeeld elk jaar eenderde van de totale hoeveelheid), blijft niet toegestaan (met uitzondering van benchmarking van entire automated controls). Ieder jaar moet nog steeds op zichzelf worden beoordeeld. Afhankelijk van de risico-inschatting kan wel minder worden getest.
  • Er kan meer gebruik worden gemaakt van het testwerk van ‘anderen’ (bijvoorbeeld een IAD), mits zij competent en objectief zijn. In dit verband kan worden samengewerkt bij het uitvoeren van walkthroughs. Daarnaast behoeft de auditor geen ‘principal evidence’ meer te verzamelen, maar ‘sufficient competent evidence’. Dit is vager, maar maakt een duidelijke inschatting van de verrichte werkzaamheden door die ‘anderen’ noodzakelijk.
  • Significant deficiencies, die voor IT veelvuldig voorkwamen, kunnen blijven bestaan. Zij hoeven niet binnen een redelijke termijn te zijn opgelost, mits er een goede onderbouwing en afweging van risico’s aanwezig is. Deze afweging is dan een onderdeel van de control environment.

Verder zijn de belangrijkste uitgangspunten van de ’16 mei guidance’ duidelijk herhaald.

Daarnaast geeft de PCAOB voor kleinere en minder complexe omgevingen aan dat ‘… in the areas in which off-the-shelf software is used, the auditor’s testing of information technology controls should focus on the application controls built into the pre-packaged software that management relies on to achieve its control objectives and the IT general controls that are important to the effective operation of those application controls …’.

Conclusie

Het moge duidelijk zijn dat er de afgelopen jaren veel is gebeurd op het gebied van de SOX-regelgeving in relatie tot de scoping en testing van de IT controls binnen de grote US-beursgenoteerde ondernemingen. Dit heeft geleid tot aanzienlijke inefficiënties waar ondernemingen op hebben gereageerd met slimmere scoping, combineren en vereenvoudigen van beheersingsmaatregelen, betere ondersteuning door tools en het integreren van controleraamwerken. Vervolgens zien we dat zij, in hun efficiencypogingen, worden gesteund door de voorgestelde aanpassingen in de auditingstandaard: meer gebaseerd op risico’s, geen afzonderlijke beoordeling van management assessment, meer gebruikmaken van IAD’s, etc. Hopelijk zijn er nu voldoende bouwstenen aanwezig voor een ‘sustainable and efficient compliance’ in de toekomst en kan er worden gedacht aan ‘return on compliance’, ofwel de toegevoegde waarde van een beter beheersbare omgeving.

Literatuur

[Brou06] Drs. P.P.M.G.G. Brouwers RE RA, drs. M.A.P. op het Veld RE en drs. A. Lissone, Tool based monitoring en auditing van ERP-systemen, van hebbeding naar noodzaak, Compact 2006/2.

[Fram04] A Framework for Evaluating Control Exceptions and Deficiencies, Version 3, December 20, 2004. The framework was developed by representatives of the following nine firms: BDO Seidman LLP, Crowe Chizek and Company LLC, Deloitte & Touche LLP, Ernst & Young LLP, Grant Thornton LLP, Harbinger PLC, KPMG LLP, McGladrey & Pullen LLP, PricewaterhouseCoopers LLP, In addition, William F. Messier, Jr., Professor, Georgia State University, also contributed to the development of the framework.

[ITGI04] ITGI, IT Control Objectives for Sarbanes-Oxley, April 2004.

[ITGI06] ITGI, IT Control Objectives for Sarbanes-Oxley, second edition, September 2006.

[John05] Everett C. Johnson, CPA, IT Governance: new players, challenges and opportunities, Information Systems Control Journal, Volume 2, 2005.

[Korn05] Ir. P. Kornelisse RE CISA, R.J.P. van den Berg RA en A.A. van Dijke, SOX – Scoping van de relevante ICT, Compact 2005/3.

[PCAO04] An Audit Of Internal Control Over Financial Reporting Performed In Conjunction With An Audit Of Financial Statements, PCAOB Release No. 2004-001, March 9, 2004.

[PCAO05] Policy statement regarding implementation of auditing standard no. 2, An Audit Of Internal Control Over Financial Reporting Performed In Conjunction With An Audit Of Financial Statements, PCAOB Release No. 2005-009, May 16, 2005.

[PCAO06] An Audit Of Internal Control Over Financial Reporting Performed In Conjunction With An Audit Of Financial Statements, PCAOB Release No. 2007-001, December 19, 2006.

[SEC06] Securities And Exchange Commission, Release Nos. 33-8762; 34-54976, Management’s Report On Internal Control Over Financial Reporting, December 20, 2006.

Innovatie in control – ook bij u?

Het positieve nieuws is dat Nederland bij de top-10 hoort in de ‘competitiveness Index-2006’ van het World Economic Forum (WEF). Echter wie Het Financieele Dagblad bijhoudt (alsook de vele andere bladen) zal al snel concluderen dat Europa en Nederland in het bijzonder voor een spannende uitdaging staan. Een rondje Het Financieele Dagblad leidt tot de kopjes ‘Managers durven niet te investeren’ (22-9-2006) ‘Concurrentiekracht Europese industrie in gevaar’ (07-10-2005), ‘Europa verliest R&D-race met China’ (12-10-2005) en zo zijn er meer voorbeelden. Geheel in lijn met wetenschappers is de noodzakelijke en tevens spannende uitdaging onderzocht. In samenwerking met Atos Consulting, www.managementsite.net en www.bita-center.com heeft het Business & IT Trends Institute[Het Business & IT Trends Institute (www.ITTI.nl) is een samenwerkingsverband tussen diverse vakgenoten van diverse organisaties onder leiding van Barry Derksen, Peter Noordam en Aart van der Vlist.] een grootschalig onderzoek gedaan naar de ‘innovativiteit’ van Nederlandse organisaties, waarvan de resultaten zijn gepubliceerd in het ITSMF-jaarboek 2006 ([ITSM06]). Hieraan heeft de auteur in dit artikel tevens het controlvraagstuk toegevoegd.

Inleiding

Innovatie in control is een vraagstuk dat is onderzocht op basis van een onderzoek en literatuuranalyse. De resultaten van dit onderzoek worden in dit artikel gepubliceerd, vervolgens wordt onderzocht of ‘innovatie in control realiseerbaar is’ en hoe dan wel. Er wordt ingegaan op de vraag wat er in Nederlandse organisaties dient te gebeuren om Nederland weer innovatief te krijgen terwijl de organisatie in control blijft. Over één ding waren namelijk de geënquêteerden en onderzoekers het absoluut eens: zonder innovatie zal Nederland de aansluiting met de rest van de wereld verliezen.

Uit het gehouden onderzoek blijkt dat Nederlandse organisaties genoodzaakt zijn om in een hoger tempo te innoveren. Ook in de European Innovation Scoreboard blijkt Nederland momentum te verliezen en alhoewel Nederland in de competitiveness index nog op de negende plaats (2006) is terug te vinden, is de algemene conclusie dat Nederland niet innovatief genoeg is. Hiervoor wordt een aantal oorzaken regelmatig genoemd:

  1. Nederland heeft een gebrekkig vermogen om nieuwe kennis te absorberen en toe te passen.
  2. Nederland is onvoldoende in staat kennis te vercommercialiseren.
  3. De mate van control belemmert het ondernemerschap.
  4. Nederland stuurt te veel op kosten.
  5. Hoogwaardige activiteiten worden steeds makkelijker verplaatst naar andere landen.

Aan de andere kant blijkt uit het WEF-onderzoek 2006 dat het succes van Zwitserland en de Noordelijke landen volgens de hoofdeconoom van het forum verschillende oorzaken heeft: er is sprake van goed functionerende overheidsinstellingen, een hoogstaand onderwijssysteem en de rol van innovatie en technologische vernieuwing is groot. In de toekomst zal het belang van goed onderwijs als motor van de economie volgens deze econoom steeds sterker toenemen.

Nederland kwam jarenlang niet in de top-10 voor. Zwitserland is nummer 1 vanwege de gedegen institutionele omgeving, excellente infrastructuur voor wetenschappelijk onderzoek, investeringen in R&D door bedrijven, efficiënte markten en hoog niveau technologische innovaties. Noord-Europese landen waaronder Nederland scoren hoog vanwege de lage schuldenlast, en hoge investeringen in opleiding, infrastructuur en sociale dienstverlening. Duitsland en Groot-Brittannië worden geroemd vanwege hun bescherming van eigendomsrechten en juridische systeem. Maar beide landen scoren slecht op macro-economische omstandigheden en hoge schuldenlast.

Het meest verontrustende dat uit het onderzoek naar voren komt, is volgens een aantal bedrijfskundigen het gebrekkige vermogen van Nederlandse ondernemingen om nieuwe kennis te absorberen en toe te passen. ‘Dit zien we al een aantal jaren en er zit geen vooruitgang in, integendeel. Niet dat we slecht zijn in technologie. We scoren bijvoorbeeld goed op het aantal patenten en wetenschappelijke publicaties. Maar we slagen er niet in om deze kennis te commercialiseren.’ Nederland werkt aan het systeem conform het Finse model. Een uit Finland afkomstige deskundige heeft hierop aangegeven: ‘Het Finse model kun je niet zomaar kopiëren. Het gaat om een hele keten van onderzoek en ontwikkeling en hoge opleidingen met innovatie als eindpunt. Daarin schiet Nederland tekort.’

Echter, als wij kijken naar de Nederlandse capaciteiten op het vlak van Administratieve Organisatie (AO) en Interne Controle (IC), dan kan worden gesteld dat wij op deze gebieden vooroplopen in de wereld. Maar dit pluspunt wordt veelal ook als belemmerend ervaren voor ondernemerschap en innovatie. Zo getuige ook een artikel in Het Financieele Dagblad van 22 september jongstleden:

Managers durven niet te investeren

Een kwart van de managers over de hele wereld zegt niet te hebben geïnvesteerd in innovatie vanwege de complexe regelgeving. Dit blijkt uit een internationaal onderzoek door financieel interim-managementbureau Robert Half Management. Organisaties betalen de tol voor de komst van nieuwe wet- en regelgeving zoals IFRS en SOX. Ook op het gebied van internationale investeringen worden bedrijven beperkt vanwege de nieuwe wetgeving. (Bron: Financieel Management).

De vervolgvragen zijn daarmee voor de hand liggend: ‘Hoe ernstig is het probleem?’ , ‘Wat moet er dan gebeuren?’ en ‘Hoe kan ik of mijn organisatie bijdragen aan de oplossingen?’. Om dit te onderzoeken heeft het Business & IT Trends Institute de volgende vragen geformuleerd voor verder onderzoek:

  1. Hoe kan innovatie worden gestimuleerd met behulp van nieuwe technologie?
  2. Kan er voldoende worden geïnnoveerd in balans met in control zijn?
  3. Is innovatie te managen?
  4. Wat is het belang van ICT voor innovatie?

In dit artikel wordt ingegaan op een deel van deze vragen. Dit betreft de vraagstukken ‘Is innovatie te managen?’, ‘Wat is het belang van ICT voor innovatie?’ en ‘Kan er voldoende worden geïnnoveerd in balans met in control zijn?’. Het artikel is zo ingedeeld dat eerst het begrip innovatie nader wordt toegelicht, gevolgd door een toelichting op het onderzoek. Na deze introducerende delen wordt ingegaan op innovatie in control. Vervolgens worden aan de hand van het klaverbladmodel[Het klaverbladmodel is een overzichtsmodel voor organisaties van KPMG bestaand uit de ‘klaverbladen’ Management & organisatie, Producten & processen, Mens & cultuur en ICT & middelen. Zie ook [Noor04].] de onderzoeksresultaten nader toegelicht. Met behulp van de bevindingen en de onderzoeksgegevens worden de gevolgen voor de financieel managers, CIO’s, IT-managers, auditors en adviseurs besproken, om te eindigen met een ‘to do’-lijst.

Van product- naar businessconceptinnovatie

Om antwoord te kunnen geven op de vragen zal eerst het begrip innovatie goed moeten worden uitgelegd. Wat is innovatie binnen organisaties? En wat is het verschil tussen innoveren en gewoon de dingen die je al deed iets slimmer doen? Om antwoord te krijgen op de vraag wat innovatie is, is in het onderzoek de theorie over innovatie bestudeerd en al gauw blijkt innovatie veel verschillende gezichten te hebben.

Innovatie kan op verschillende gebieden plaatsvinden ([Jaco01]).[Dit deel is ook beschreven in Compact 2006/1 pagina 15, maar wordt hier herhaald aangezien dit de basis voor het verdere betoog vormt.] Vanuit de theorie worden vijf verschillende gebieden genoemd:

  • Productinnovatie. Dit betreft verbeteringen aan bestaande producten, diensten of radicaal nieuwe producten en diensten.
  • Procesinnovatie. Dit zijn verbeteringen in het totstandkomingsproces van deze producten of diensten. Het productieproces van een auto, maar ook het ‘schadeafhandelingsproces’ bij een verzekeringsmaatschappij.
  • Transactie-innovatie. Procesinnovaties beperken zich tot innovaties binnen de organisatiegrenzen. Transactie-innovaties gaan verder, hierbij wordt de gehele ‘bedrijfskolom’ of organisatieomgeving betrokken. Vaak heeft deze vorm betrekking op de relatie met leveranciers en afnemers.
  • Organisatie-innovatie. Deze vorm van innovatie richt zich op de structuur van de organisatie; nieuwe manieren van samenwerking binnen afdelingen of nieuwe structuren zijn het onderzoeksgebied.
  • Innovatie in businessconcepten. Deze vorm lijkt op de voorgaande, maar hier wordt (vaak onder invloed van veranderende technologische mogelijkheden) verder gekeken dan de organisatiegrenzen. Shared service centers en uitbesteding zijn onderwerpen die bij deze vorm van innovatie een rol spelen.

Een tweede manier van kijken naar innovatie betreft de ‘radicaliteit’ of diepgang van de innovatie. Om deze vorm te doorgronden zetten we innovatie tegenover optimalisatie.

Kenmerken van optimalisatie zijn: rekening houden met de bestaande organisatie, ICT en kaders, terwijl bij radicale innovatie juist buiten de bestaande kaders wordt gewerkt. Bij innovatie worden de vrijheidsgraden bepaald door de mogelijkheden om de innovatieve gedachte te realiseren. De vrijheidsgraden van optimalisatie worden in grote lijnen bepaald door de wijze waarop de organisatie op dat moment is ingericht, de mensen die er werkzaam zijn, de mate van automatisering en de cultuur en veranderingsbereidheid van de organisatie. Optimalisatie is dus beperkter dan innovatie.

Als klanten fundamenteel andere eisen aan de producten of diensten stellen, dan is de organisatie verplicht om haar processen, structuur, besturing en ICT-ondersteuning ingrijpend aan te passen om aan die eisen tegemoet te komen; dit noemen we dan weer innovatie.

Jacobs ([Jaco01]) onderscheidt incrementele en radicale innovatie. Incrementele innovatie (of optimalisatie) is het voortdurend verbeteren van bestaande producten en processen (‘making things better’). Japanners spreken in dit kader over ‘Kaizen’, dat staat voor ‘continue verbetering’. Jacobs spreekt in dit verband van single loop learning, wat inhoudt dat de werkwijze hetzelfde blijft maar steeds beter wordt.

De tweede vorm van innovatie betreft de radicale innovatie. Hierbij worden nieuwe concepten toegepast om dezelfde dan wel geheel nieuwe producten en diensten tot stand te brengen (om in de terminologie van Philips te blijven: ‘making things better … other things’). Jacobs spreekt hier over double loop learning. In figuur 1 wordt dit weergegeven door het starten van een nieuwe curve. De gedachte hierachter is dat incrementele innovatie op enig moment tegen de grenzen aanloopt en er geen nieuwe verbetermogelijkheden zijn, op dat moment, liefst iets eerder.

C-2006-4-Derksen-01

Figuur 1. Vormen van innovatie.

Het is natuurlijk de kunst om binnen organisaties met de single loop en double loop te balanceren zodat innovatie en resultaat optimaal worden toegepast. Dit balanceervermogen noemt Jacobs deutero-leren. Indien de Nederlandse organisaties innovatief willen zijn, is het van belang dat zij de balans leren te managen. Dit betekent dat op bestaande producten en processen de incrementele innovatietechnieken van toepassing zijn en op de radicale innovatie nieuwe concepten worden toegepast. Het vinden van deze balans is een belangrijk element van ons onderzoek.

In het double loop leren zit volgens enkelen een belangrijk vraagstuk voor Nederland. Een analyse van Jagersma ([Jage]) leidt tot de volgende conclusie:

‘De BV Nederland is in veel zwaarder weer terechtgekomen dan we vermoeden. Recent door mij uitgevoerd onderzoek heeft aangetoond dat de BV Nederland als geheel afhankelijk is van volwassen bedrijfstakken waarin het tegen de achtergrond van het opkomende Aziatische geweld in de toekomst bepaald niet goed toeven is. Juist in deze dikwijls mondiale dan wel mondialiserende kapitaals- en arbeidsintensieve bedrijfstakken als de metaal-, transport- en kapitaalgoederenindustrie wordt op de kostencomponent van de marge geconcurreerd en daar zijn de Aziaten vanwege hun comparatieve kostenvoordelen nu eenmaal beter in. De ‘opbrengstendimensie’ van de marge waarin bijvoorbeeld innovativiteit en creativiteit tot uitdrukking komen is in dergelijke bedrijfstakken veel minder relevant.’

De reikwijdte en diepte van verandering gaat vaak niet verder dan het innoveren en/of optimaliseren van bedrijfsprocessen. Dit ondanks de mogelijkheden van ICT.

Naast radicaliteit en balans speelt het belang van ICT of nieuwe technologische mogelijkheden bij innovatie een rol. Immers, de claim wordt vaak gelegd dat nieuwe technologische mogelijkheden de belangrijkste drijfveer voor innovaties zijn. Om die reden is de volgende definitie van innovatie in het onderzoek toegepast:

Innovatie is het ontwikkelen van nieuwe producten en diensten en het verregaand verbeteren van bestaande processen, producten/diensten en organisaties, al dan niet met behulp van ICT-middelen.

Innovatie onderzocht

Het innovatieonderzoek is gehouden onder bijna 400 Nederlandse organisaties gevolgd door een client study bij ongeveer twaalf organisaties door medewerkers van Atos Consulting (voor de gegevens van dit onderzoek wordt naar Atos Consulting verwezen alsmede de publicatie in [ITSM06]). De verdelingen met betrekking tot aantallen werknemers en branches zijn weergegeven in de figuren 2 en 3.

C-2006-4-Derksen-02

Figuur 2. Verdeling respondenten over branches (bron: Atos Consulting & Business & IT Trends Institute).

C-2006-4-Derksen-03

Figuur 3. Verdeling respondenten over aantal medewerkers per onderzochte organisatie (bron: Atos Consulting & Business & IT Trends Institute).

Uit de figuren 2 en 3 kan worden geconcludeerd dat het onderzoek een redelijke verdeling kent tussen kleine en middelgrote organisaties (39%) en grote (meer dan 500 medewerkers) organisaties (61%). De resultaten kunnen algemeen geldend worden verklaard vanuit het aantal medewerkers-perspectief. Ook de verdeling privaat/publiek is representatief te noemen (privaat 69%, publiek 31%). Gezien het aantal deelnemende organisaties (bijna 400) en de verdeling over de branches en aantallen medewerkers zijn de resultaten algemeen geldend te noemen. Er zijn dan ook geen verdere aanpassingen geweest. Wel is er een extra onderzoek gehouden bij gemeenten en onderwijsinstellingen met dezelfde vragenlijst in november/december 2005. Reden hiervan was dat het aantal deelnemers uit deze branches te beperkt was. Naar aanleiding van dit aanvullende onderzoek is de verdeling privaat/publiek veranderd van 80%/20% naar 69%/31%.

Nederlandse innovatiearrogantie

Dat BV Nederland geen innovatieland is blijkt wel uit de woorden van Jagersma. Hij geeft aan dat Nederland te veel afhankelijk is van volwassen bedrijfstakken. Dit blijkt ook uit een onderzoek van het EIM[Ranglijst van MKB-sectoren naar innovativiteit (periode 2002-2005), augustus 2005, EIM.] waarin naar voren komt dat de innovativiteit vooral uit de bestaande branches moet komen.

Uit het onderzoek komt in eerste instantie een maatschappelijk geaccepteerd antwoord. De eigen organisatie is wel innovatief, maar de branchegenoten zijn dat een stuk minder. Nederland als geheel (en de politiek in het bijzonder) kan niet innovatief worden genoemd. Ruim 25% van de onderzochte organisaties beschouwt zichzelf als innovator. Dit is een positief beeld en lijkt irrealistisch. Wanneer hier de Technology Adoption Life Cycle[Hoewel het van origine uit de agrarische branche komt, is dit model succesvol toegepast voor IT door Geoffrey A. Moore in Crossing the chasm, marketing and selling disruptive products to mainstream customers, April 2002.] van Geoffrey A. Moore bij wordt geplaatst, is de voorzichtige conclusie dat Nederland aan innovatiearrogantie lijdt het resultaat. Figuur 4 is de uitkomst wanneer wordt gevraagd naar het innovativiteitsgehalte van de organisatie.

C-2006-4-Derksen-04

Figuur 4. Nederland lijdt aan innovatiearrogantie (bron: Innovatie werkteam / Business & IT Trends Institute).

Volgens figuur 4 is ruim 28% van de Nederlandse privaatrechtelijke organisaties een innovator gevolgd door 24% early adopters. Dit zou inhouden dat ruim 52% van de organisaties de leading edge vormt binnen de branches waarin zij opereren. De huidige WEF-positie van Nederland gaf reeds aan dat dit niet klopt. Wanneer gekeken wordt naar innovatie binnen de branche dan wordt het beeld al snel minder rooskleurig. Dit is weergegeven in figuur 5.

C-2006-4-Derksen-05

Figuur 5. Een lagere economische groei wordt verwacht (bron: Innovatie werkteam / Business & IT Trends Institute).

Deze figuur gaat in op de vraag of Nederland inderdaad een lage economische groei heeft als gevolg van gebrek aan innovatie. Deze vraag is gesteld voor de eigen organisatie, de branche, de overheid, en de maatschappij.

De geënquêteerden zijn ronduit positief over de innovatiekracht van hun eigen organisatie. Zoals aangegeven wordt het beeld somberder wanneer buiten de eigen organisatie wordt gekeken. Een ruime meerderheid van de organisaties heeft een negatief beeld over de voorsprong van Nederland door de economische hervormingen. Wel wordt het bezuinigingsbeleid van de overheid door een ruime meerderheid toegejuicht.

In tegenstelling tot de inschatting van innovativiteit van de eigen organisatie is het beeld over het algemeen vrij negatief. De indicatoren staan er niet goed voor en dat vraagt om een nadere analyse.

Meer innovatie is noodzakelijk, waarbij duidelijk onderscheid moet worden gemaakt tussen incrementele innovatie (wat reeds veelal gebeurt) en radicale innovatie (wat veel minder gebeurt).

Als één van de hoofdoorzaken van de geconstateerde innovatiearrogantie werd door de deelnemers de Nederlandse houding ten opzichte van het durven nemen van risico genoemd. In Nederland telt het adagium ‘Doe maar gewoon, dan doe je al gek genoeg’. Dit komt ook terug in de cijfers. 70% van de onderzochte organisaties ziet het belang van innovatie maar we blijken hier nog niet naar te acteren, waarbij mentaliteit en het durven nemen van de risicovolle route als vraagstukken worden genoemd.

De aandachtsgebieden van innovatie

Het eerdergenoemde klaverbladmodel (zie figuur 6) is een model waarmee de belangrijkste aandachtsgebieden worden weergegeven. Hierin is tevens opgenomen wat de vraagstukken met betrekking tot innovatie zijn. In het midden van het model wordt het resultaat weergegeven. Dit resultaat betreft de balans tussen de vrijgemaakte middelen en het rendement van innovatieve stappen (zowel incrementeel als radicaal). Binnen een organisatie zijn vier aandachtsgebieden te onderscheiden:

  • Management & organisatie;
  • Producten & processen;
  • ICT & middelen;
  • Mens & cultuur.

Bij innovatie met uitsluitend ICT is het binnen automatiseringsprojecten een klassieke fout om alleen aandacht te schenken aan het inrichtingselement technologie, zonder de impact op management, processen en cultuur mee te nemen. Bij proces- en productinnovatie wordt de klassieke fout gemaakt door alleen aandacht te hebben voor het aspect procesinnovatie en procesoptimalisatie. Men besteedt veel aandacht aan het optimaliseren van de procesgang (incrementele procesinnovatie) zonder rekening te houden met de andere drie inrichtingselementen van het klaverblad.

Uitgangspunt is in ieder geval dat de inrichtingselementen in balans moeten zijn voor succesvolle organisatie-inrichting. Door rekening te houden met alle vier de belangrijkste aspecten en deze in verband met elkaar te brengen kunnen veel radicalere innovaties worden gerealiseerd.

C-2006-4-Derksen-06

Figuur 6. Het klaverbladmodel voor innovatievraagstukken ([Noor04]).

Uit figuur 6 kan worden herleid dat op elk van de vlakken diverse vragen zijn te beantwoorden. Aangezien al geconstateerd is dat er op het gebied van innovatie veel moet gebeuren, is het vooral de vraag op welke van bovenstaande vlakken en in welke mate innovatie moet plaatsvinden. De resultaten van het innovatieonderzoek behandelen deze vraag (onderzoeksvragen 3 en 4).

Aandachtsgebied Management & organisatie

Allereerst is gevraagd aan de organisaties of en zo ja, hoe innovatie gemanaged wordt. De resultaten zijn in figuur 7 weergegeven. Om te beginnen is onderzocht of innovatie een organisatie- en inrichtingsvraagstuk is. Hoewel innovatie vaak ontstaat vanuit een idee of onderzoek door wetenschappers is het merendeel van de organisaties van mening dat innovatie te managen is. Slechts 4% van de onderzochte organisaties is een andere mening toegedaan. 77% geeft aan dat innovatie te managen is. Deze mening komt overeen met het ‘funnel’management van Clark en Wheelwright ([Clar93]), die met de ‘funnel’ een managementmethodiek introduceren waarmee organisaties idealiter een proces doorlopen om zo uit de vele ideeën die met de gunstige perspectieven te selecteren en deze vervolgens te ontwikkelen en te realiseren. Innovatie is dus te managen.

C-2006-4-Derksen-07

Figuur 7. Innovatie is te managen (bron: Business & IT Trends Institute).

Aangezien innovatie te managen is, ligt het in de lijn der verwachting dat innovatie een onderdeel van de strategie is of dat er zelfs een innovatiestrategie is. 51% van de onderzochte organisaties heeft innovatie opgenomen in de bedrijfsstrategie. Een behoorlijk percentage, dat echter tegelijkertijd inhoudt dat bijna de helft van alle Nederlandse organisaties innovatie niet heeft opgenomen in haar strategie. Het belangrijkste vraagstuk zit in de managementagenda. De dag tot dag beslommeringen blijken keer op keer een hogere prioriteit te hebben, met als gevolg dat innovatie niet voldoende op de agenda staat. Bij slechts 1% van de organisaties staat innovatie hoog op de managementagenda. Bij ruim 63% van de organisaties komt innovatie niet of nauwelijks op de managementagenda naar voren.

Een extra impuls voor innovatie blijkt noodzakelijk te zijn om verdere groei of verbetering van de concurrentiepositie te realiseren. Circa 70% van de onderzochte organisaties erkent deze noodzaak. Aan het stoplicht te zien zetten wij de balans vanuit management- & organisatieperspectief dan ook op oranje. De noodzaak wordt gezien, innovatie is volgens de meeste organisaties te managen, maar het is van belang dat de noodzaak hiertoe ook op de managementagenda terugkeert. Een kleine hint voor het ‘innovatiebeslissingsproces’ geven wij hieronder weer:

  • Inventarisatie van de drivers van innovatie. Aan de hand van innovaties uit het verleden onderzoeken wat de veroorzakers zijn geweest van de innovatie en deze voor de toekomst extra koesteren. Als bij een aantal medewerkers altijd vernieuwende ideeën komen, dan zou voor deze groep extra aandacht en innovatiestimulans gecreëerd moeten worden.
  • Inventarisatie van dilemma’s en trade-offs tussen creatie van stakeholderwaarde en andere belangen (bijvoorbeeld van medewerkers en maatschappij).
  • Inventarisatie van bottlenecks bij processen inzake het effect vanuit de afnemer op de productfuncties.
  • Inventarisatie van risico’s bij het realiseren van ontwikkelplannen (vicious reinforcing loops). Van belang om de ‘time to market’ van innovaties te kunnen voorspellen. Wat zorgt ervoor dat innovatieve ideeën in korte tijd gerealiseerd kunnen worden.
  • Inrichten en plannen van het ontwikkelproces (innovatieprojecten).

Een andere manier om innovatie beter te managen is om hier een aparte functie voor te organiseren binnen de eigen organisatie. De innovation office, of ook wel de midoffice, is de plaats in de organisatie waar de kennis van de organisatie wordt beheerd. Ingewikkelde vragen vanuit de frontoffice (tweedelijnsvragen) worden hier afgehandeld. Daarnaast heeft de midoffice in zijn functie van innovation office de taak om nieuwe ontwikkelingen of mogelijkheden snel te signaleren, te beoordelen op passendheid en risico’s, en te realiseren in de bestaande organisatie. Processen die hier plaatsvinden worden gekenmerkt door een hoge mate van flexibiliteit. De backoffice voert met name standaardprocessen uit.

Recente inzichten laten zien dat structuur niet zo belangrijk is, als deze maar eenvoudig is en in lijn is met de strategie (en omgekeerd). Meer innovativiteit in de organisatie ontstaat in onze ogen dan ook vooral door de organisatie te beschouwen als een doos legoblokken. Deze hoeven zeker niet elk dezelfde vorm en ook niet dezelfde besturing te kennen. Daarnaast kan worden geconstateerd dat ook steeds vaker gebruik wordt gemaakt van business process outsourcing en de vorming van shared service centers. Belangrijk is dat de structuur meebeweegt met een besturing die gericht is op de balans tussen korte en lange termijn.

Aandachtsgebied Producten & processen

Het tweede perspectief is Producten & processen. Het innoveren van producten levert voor vele organisaties nieuwe markten en verbeterde klanttevredenheid op. Hiervoor is het veelal wel noodzakelijk dat de processen geheel of gedeeltelijk worden herzien dan wel dat compleet nieuwe processen ontstaan (procesinnovatie). Er zijn diverse methoden om processen te optimaliseren (incrementele procesinnovatie), zoals Six Sigma en Root Cause Analysis (RCA). Daarnaast zijn er diverse methoden om radicale procesinnovatie door te voeren, zoals Business Process Redesign en Business Performance Improvement[Business Performance Improvement is een methodiek van KPMG om organisaties op het gehele klaverblad te verbeteren of radicaal te veranderen. Zie [Noor05].]. Uit het onderzoek blijkt hier één van de kernen van het probleem te zitten. Ook innovatie is een businessproces, maar de meeste Nederlandse organisaties hebben het innovatieproces niet ingericht.

C-2006-4-Derksen-08

Figuur 8. Processen op orde (bron: Business & IT Trends Institute).

Tevens maken de meeste organisaties geen gebruik van de geijkte methoden en technieken om innovatie te realiseren en te implementeren binnen de organisatie. Slechts 30% van de Nederlandse organisaties maakt gebruik van methoden en technieken om procesinnovatie te realiseren. Dit beeld is nog sterker bij incrementele procesinnovatie dan bij radicale procesinnovatie. Dit lijkt overeen te komen met de bevindingen bij Management & organisatie. Daar waar het management innovatie hoger op de agenda heeft wordt radicale product- en procesinnovatie gestimuleerd, maar bij de meeste organisaties ontbreekt het aan tijd of aan prioriteit om incrementele of radicale procesinnovatie te realiseren. Het gebruik van beproefde methoden en technieken op het gebied van product- en procesinnovatie lijkt een aanbeveling voor vele Nederlandse organisaties.

Het structureren van innovatie begint met:

  • Opbouwen en uitbouwen van relaties met leveranciers/klanten (ketengericht).
  • Stimuleren constructieve samenwerking binnen de eigen organisatie (procesgericht).
  • Vaststellen en autonomie van projectteams (binnen de innovation office).
  • Vrijgeven van (financiële) middelen voor innovativiteit.

Aandachtsgebied Mens & cultuur

Het derde belangrijke perspectief van innovatie is Mens & cultuur. Een veelgehoorde kreet is dat de mentaliteit in Nederland ongeschikt is om innovatie te realiseren. Dit blijkt deels waar te zijn. Nederlandse werknemers verkiezen de gemakkelijke route boven de meer risicovolle route met een hoger lonkend perspectief, blijkt uit het eerdergenoemde onderzoek. Dit geldt voor meer dan 50% van de Nederlandse werknemers. Daar staat tegenover dat het merendeel van de onderzochte organisaties de klant en culturele trends nauwlettend volgt om daarmee beter in te spelen op de klantwensen. Tevens stimuleert ruim 53% van de organisaties het benutten van kansen voor innovatie.

C-2006-4-Derksen-09

Figuur 9. Mens als spil voor innovatie (bron: Business & IT Trends Institute).

Het percentage organisaties waarbij foutvermijdend gedrag (42%) en de keuze voor het bewandelen van de gemakkelijkste route (52%) vaak voorkomen, is aan de hoge kant. Zij vormen een belangrijke barrière voor innovatie. Acties hierop zijn noodzakelijk te noemen om zo innovaties te stimuleren en te versnellen. Er zijn diverse mechanismen om een innovatietraject te stimuleren en te versnellen:

  • HR-focus en beloning voor innovatie-initiatieven in de organisatie.
  • Organiseren van interne concurrentie tussen units, afdelingen en medewerkers.
  • Concurrent engineering / concurrent research, een vaker gebruikte manier in researchlaboratoria, waarbij parallel door verschillende teams aan hetzelfde probleem wordt gewerkt.
  • ICT en internet een onuitputtelijke bron van inspiratie (mits goed gebruikt).

Ook O’Reilly en Tushman ([O’Rei]) geven diverse hints met betrekking tot normen en waarden van de innovatieve organisatie: creativiteit (ondersteunen risicozoekend gedrag en acceptatie van fouten), implementatie (effectieve samenwerking, gezamenlijke doelstellingen, gedeelde informatie) en snelheid (snelle besluitvorming, flexibiliteit en persoonlijke autonomiteit).

In de stoplichtenscorecard zetten wij het licht dan ook op oranje. Dit omdat een belangrijk deel van de organisaties hier goed mee omgaat en we voor een redelijk deel kunnen stellen dat Nederlandse organisaties een stimulerende omgeving bieden. De keuze valt echter nog te vaak op de gemakkelijke route.

Aandachtsgebied ICT & middelen[Het aandachtsgebied ICT & middelen is ook in Compact 2006/1 pagina 17 beschreven. In lijn met dit innovatieartikel is deze tekst hier opnieuw opgenomen.]

Ook ICT heeft een belangrijke toegevoegde waarde voor de diverse vormen van innovatie, zo geeft 54% van de onderzochte organisaties aan. 57% geeft zelfs aan dat ICT essentieel is bij het incrementeel of radicaal innoveren van de processen. Helaas zet deze trend zich niet door als het gaat over het profiteren van de ICT-mogelijkheden, gebruik van innovatiesoftware en het bij innovatie betrekken van de ICT-functie.

C-2006-4-Derksen-10

Figuur 10. De ICT’er staat buitenspel (bron: Business & IT Trends Institute).

De ICT-afdeling wordt, gek genoeg, niet of nauwelijks ingeschakeld als het gaat over innovatie. Dit is vreemd te noemen als we kijken naar de ontwikkelingen van de afgelopen vijf jaar op ICT-gebied en de recent toegevoegde topbedrijven aan de diverse beurzen (Google, TomTom, Marktplaats.nl, Alex en Binck). Dit zijn allemaal bedrijven die juist innovatie met behulp van ICT hebben gerealiseerd. In lijn met de enorme groei die deze organisaties hebben doorgemaakt, mag worden verwacht dat de ICT-functie en ICT-trendwatchers meer worden betrokken bij de innovatiestrategie en -plannen van organisaties. Uit het onderzoek blijkt echter dat in ruim 72% van de gevallen de ICT-functie niet of nauwelijks bij innovatie wordt betrokken, laat staan dat innovatie mede vanuit de ICT-functie wordt geïnitieerd. Dit is enerzijds in lijn met de golf die bij de grote ICT-dienstverleners plaatsvindt: ‘ICT van de tap’. De ICT-leveranciers stimuleren dat ICT een faciliteit is net als stroom en water. Enerzijds is dit van toepassing op bestaande processen. Hier is ICT net als gebouwen een faciliteit die efficiënt gemanaged dient te worden. Echter, ICT dient veelal ook te worden toegepast voor proces- en productinnovatie. Hierbij dient uiteraard te worden gedacht aan de productiviteitsparadox en het innovator’s dilemma ([Chri97]), maar gelet op de nieuwkomers op de beurzen en hun groei kan worden gesteld dat ICT een belangrijke functie heeft voor productinnovatie.

Dat de ICT-functie nog een behoorlijke uitdaging heeft laten we terugkeren in de stoplichtenscorecard, hiervoor zetten wij het licht op rood. Dit omdat de ICT-functie te weinig wordt betrokken bij innovatievraagstukken. Hierbij heeft de ICT’er de uitdaging om dit zowel aan de vraag- als aan de aanbodzijde te veranderen.

Innovatie in control

Het in control zijn wordt door veel ondernemers gezien als belemmerend, getuige ook het onderzoek waaraan in het begin van dit artikel wordt gerefereerd. Om dit te analyseren zijn in figuur 11 de beursontwikkelingen en de tijdigheid van de controlaspecten SOX en Tabaksblat gecombineerd. Alhoewel de neer- en opgang van de beurs (in dit geval de AEX) natuurlijk van vele factoren afhankelijk is, kunnen we in elk geval stellen dat het voldoen aan de controlmaatregelen nauwelijks negatieve invloed heeft op de beurskoersen. Integendeel, misschien kunnen we wel stellen dat het in control zijn een positief effect heeft omdat het de belegger meer vertrouwen geeft. Gezien de koersontwikkelingen kan worden gesteld dat er ruimte voor verdere ontwikkeling, omzetgroei en innovatie ontstaat.

C-2006-4-Derksen-11

Figuur 11. Ontwikkeling koers AEX als reactie op markante feiten.

Echter, één van de vele ‘klachten’ van de regelgeving komt tot uiting in de bevinding van het Robert Half Management inzake het terugschrikken voor investeren in innovatie in verband met de complexe wet- en regelgeving. Die maakt innoveren een stuk moeilijker. Hierdoor is innoveren in control een paradox waarin nog een balans moet worden gevonden. De organisaties die deze kunst beheersen lijken daarmee echter een voordeel te verkrijgen. Deze vorm van balans kan worden weergegeven als in figuur 12.

C-2006-4-Derksen-12

Figuur 12. Innoveren in control: op zoek naar balans.

Wanneer gekeken wordt naar innovatie en control, kan vanuit historisch perspectief worden gesteld dat organisaties als geheel zich meer gericht hebben op bedrijfsverbetering en innovatie (x-as) of op risicomanagement of control (y-as). Meestal niet op beide in balans. Recente gebeurtenissen als Y2K, SOX, IFRS en andere hebben organisaties genoodzaakt om meer aandacht te besteden aan het in control zijn alsmede de integriteit van de controls. Als een resultante van de Sarbanes-Oxley (SOX) wetgeving heeft de focus zich grotendeels verplaatst van bedrijfsverbetering en innovatie naar compliance en control. Om nu in control te kunnen innoveren is een gebalanceerde aanpak noodzakelijk.

Lerend uit het verleden bleek Y2K vooral investeringen in risicomanagement teweeg te brengen, waarbij grote hoeveelheden menselijke resources werden ingehuurd om op zoek te gaan naar mogelijk verouderde stukken code in de programmatuur en deze te verbeteren. In korte tijd ontstonden diverse technologische mogelijkheden waarbij rekening werd gehouden met het detecteren en oplossen van dit ‘probleem’. In korte tijd werd het oplossen goedkoper en sneller.

Daarna werd grootschalig geïnvesteerd in nieuwe technologie voor bedrijfsverbetering en innovatie. De nieuwe wet- en regelgeving als SOX en IFRS gaat echter verder dan fouten in de programmatuur; zij betreft ook de processen, het handelen van management en medewerkers, et cetera. Hierdoor wordt innovatie ook een proces dat zich dient te houden aan dergelijke spelregels. Wel kan worden gesteld dat deze wet- en regelgeving steeds beter bekend is en dat er ruimte ontstaat waarbinnen gehandeld kan worden. Het managen van innovatie wordt daarmee een vakgebied waarbij professionals en wetenschappers zich vrij kunnen bewegen binnen de geschetste kaders die een innovatiemanager kan aangeven en binnen de lijnen van de wet- en regelgeving. Indien hier binnen organisaties specifieke aandacht voor ontstaat, is er sprake van innovatie in control. Een goed voorbeeld hiervan is de (product)innovatie bij medicijnen. Voordat een medicijn op de markt komt is een leverancier verplicht zich te houden aan strikte regels van onderzoek om er zo vrijwel zeker van te zijn een betrouwbaar en niet schadelijk product op de markt te brengen. Hierdoor is de ‘time to market’ weliswaar langer, maar dat is een nadeel dat al deze organisaties hebben. Wellicht is innovatie in organisaties hiermee vergelijkbaar geworden en bestaat de kunst van het innoveren in control niet alleen uit het innoveren zelf maar ook uit het innoveren in de controlaspecten om zo concurrentievoordeel te bemachtigen. Dit sluit tevens aan bij een eerder schrijven van mij in Compact 2006/1, namelijk dat innovatie vooral op de I van Informatietechnologie zal gaan plaatsvinden. Immers, het goed beheersen van deze I(nformatie) rondom control en innovatie geeft de kennis en macht om als organisatie te kunnen innoveren.

En nu?

Waarom deze aandacht voor innovatie in control, wat levert het eigenlijk op? Allereerst blijken innovatieve organisaties tweemaal zo winstgevend te zijn als andere organisaties en groeien zij bovengemiddeld snel. Recente voorbeelden uit de Nederlandse markt zijn Alex, Marktplaats, TomTom en de Nederlandse Google. Daarnaast ondergraaft het nalaten van innovaties de toekomstige prestaties en onze concurrentiepositie. De Aziaten kunnen immers hetzelfde werk goedkoper verrichten dan wij. Maar innoveren is natuurlijk ook gewoon een spannende uitdaging en het is leuk om succes te hebben met een innovatief product, proces of bedrijfsconcept. Dat dit in control moet gebeuren is een spelregel geworden waaraan vrijwel alle organisaties zich dienen te houden.

Innovatie in control is gewenst, maar gezien de resultaten van het onderzoek is een groeipad van toepassing. Zeker op de gebieden Producten & processen en ICT & middelen zijn acties om innovatie te realiseren gewenst. De volgende uitdagingen kunnen organisaties helpen de innovatie in control te verhogen:

  • invoeren van ‘world class’-methoden en -technieken om innovatie in control in processen te structureren;
  • lef om veranderingen binnen de bestaande processen door te voeren en deze vooraf getoetst te hebben aan de regels van onder meer SOX;
  • de auditfunctie laten groeien van ‘controleur’ naar ‘innovation partnership’;
  • investeren in experimenteren en invoeren van innovatieve ICT-mogelijkheden;
  • invoeren van een ‘innovatie in control’-strategie en bepalen van structurele prioriteit op de managementagenda.

Gebaseerd op bovenstaande bevindingen heb ik de vrijheid genomen om een algemene plateauplanning te maken die organisaties ondersteunt bij het verbeteren van de innovativiteit. De plateauplanning geldt voor alle vier de aandachtsgebieden van het klaverblad. Hierbij wordt onderscheid gemaakt in drie plateaus die elk drie tot zes maanden in beslag nemen.

Plateau 1. Tooling voor innovatie in control op orde

Om het eerste plateau te realiseren adviseer ik de randvoorwaardelijke zaken op orde te stellen. Dit betreft het professionaliseren van innovatie binnen de organisatie door het opzetten van innovatieprocessen in control. Tevens wordt in dit plateau gekozen voor en geïnvesteerd in ICT en innovatieontwikkelingen.

Plateau 2. Innovatieve attitude

Het tweede plateau richt zich op de aandachtsgebieden Management & organisatie en Mensen & cultuur. Het doorbreken van de focus op de dagelijkse beslommeringen alsmede het creëren van een stimulerende omgeving voor innovatie in combinatie met de gegeven spelregels vanuit wet- en regelgeving vormen de belangrijkste vraagstukken in dit plateau. Hierboven was reeds een aantal stappen weergegeven ten aanzien van deze twee aandachtsgebieden. Maar ook het toepassen van ‘funnel’management of de satellietaanpak waarmee organisaties – meestal naast de staande organisatie – een aantal initiatieven ontplooien en deze nauwlettend volgen en daarbij accepteren dat een aantal initiatieven nooit succesvol zal worden, zijn elementen van dit tweede plateau. Ter vergelijking, venture capitalists accepteren een hitrate van 30% (dus 7 op de 10 investeringen mislukken …).

Plateau 3. Excellentie in innovatie in control

Wellicht dat dit plateau ambitieus is neergezet. Doelstelling is natuurlijk Nederlandse organisaties aan de WEF 1-positie te helpen! Innovatie moet dan bij het merendeel van de organisaties in de haarvaten zitten. Op alle vlakken van het eerdergenoemde klaverbladmodel is innovativiteit en samenwerking op dit vlak ingevoerd. Ook vormen de diverse organisaties verschillende allianties voor verdere innovatie en betrekken zij de markt en klant hier nauw bij.

Tot slot

De vormen van innovatie (product, proces, transactie, organisatie en bedrijfsconcept) worden in Nederland nog beperkt toegepast. We kunnen echter leren van recente Nederlandse successen zoals TomTom, Marktplaats en andere. Momenteel haalt ruim 54% van de onderzochte organisaties niet voldoende rendement uit investeringen in innovatie. Nog eens 29% van de onderzochte organisaties behaalt slechts een gedeelte van het verwachte rendement uit innovatie. Hieruit kan geconcludeerd worden dat het initiëren van verbeteringen in de diverse onderdelen van innovatie gewenst is. Het introduceren van control kan hierbij juist helpen. Aan de hand van het hier behandelde innovatieonderzoek wordt een aantal aandachtsgebieden toegelicht waarop verbeteringen mogelijk zijn. Het realiseren van deze verbeteringen (incrementeel of radicaal) zal de betreffende organisaties helpen hun concurrentiepositie te verbeteren alsmede hun rendement op innovatie te vergroten.

Literatuur

[Chri97] Clayton M. Christensen, The innovator’s dilemma, when new technologies cause great firms to fail, 1997.

[Clar93] Kim B. Clark en Steven C. Wheelwright, Managing new product en process development, Harvard Business School Press, 1993.

[ITSM06] ITSMF, IT Service Management, best practices, ISBN 90-772-1217-5, 2006.

[Jaco01] Prof. dr. Dany Jacobs, Van kenniseconomie naar wild kapitalisme en terug, Scriptum, 2001.

[Jage] Prof. dr. Pieter-Klaas Jagersma, BV Nederland verstrikt in economische zone des doods, www.managementsite.net.

[Noor04] P. Noordam, B. Derksen en A. van der Vlist, Trends in IT 2004-2005, Op tijd investeren in de juiste technologie, Business & IT Trends Institute, 2004.

[Noor05] P. Noordam, Inrichten en optimaliseren van organisaties: ICT-gedreven organisatieverbetering, 2005.

[O’Rei] O’Reilly en Tushman, Norms and Values for the Innovative organization.

Integriteitmanagement globaal gemeten

De globalisering van de economie brengt veel voordelen met zich mee. Internationaal opererende bedrijven krijgen echter ook te maken met uiteenlopende lastige beheersingsvraagstukken. In dit artikel wordt ingegaan op één van deze beheersingsvraagstukken: het managen van de organisatie-integriteit. Om dit aspect te kunnen managen is het ook belangrijk om te kunnen meten hoe het staat met de integriteit van een organisatie. De integriteitthermometer is een instrument om het ethische klimaat binnen een organisatie te meten.

Inleiding

Een goede reputatie wordt door veel ondernemers als belangrijke bestaansvoorwaarde gezien. Het is lastig om een goede reputatie te verkrijgen, en soms nog lastiger om die goede reputatie te behouden en te gelde te maken. Bovendien verlegt de markt voortdurend zijn grenzen. Maar al te vaak leiden ambitieuze internationale groeiscenario’s en rigoureuze kostenbesparingen door bijvoorbeeld outsourcing aan lagelonenlanden tot aantasting van de goede reputatie van een onderneming.

Dit artikel probeert uit te leggen dat het verankeren van integriteitsbesef in een organisatiecultuur een belangrijk wapen is in het managen van internationaal opererende ondernemingen. Hoewel de definitie van integriteit moeilijk te geven is en ook zeer cultureel gebonden is, zijn het juist deze verschillen binnen een onderneming die de bron kunnen vormen van incidenten. Daarom is het belangrijk om ook dit cultuurelement van de organisatie meetbaar te maken om op die manier inzichtelijk te hebben waar mogelijke spanningsvelden zich bevinden.

Vervolgens gaan we in op de vraag hoe het ethische klimaat binnen een organisatie kan worden gemeten en welke elementen van belang zijn om integriteit te beheersen.

Integriteit, verschillende invalshoeken

Wat is nu precies integriteit? Het beantwoorden van deze zo simpel ogende vraag blijkt behoorlijk lastig te zijn. Naast een formele definitiekwestie willen wij hier graag inzoomen op de culturele verschillen van het integriteitsbegrip.

Integriteit is in de praktijk een subjectief begrip: het wordt door ieder anders ervaren en ingevuld. Iedereen heeft er een beeld bij maar dit beeld is niet voor iedereen gelijk. Vaak worden keuzen op het gebied van integriteit gedaan op basis van intuïtie en gevoelens: vanuit verschillende individuele percepties van wat integer gedrag is.

C-2006-3-Kloosterman-01

Figuur 1. Wat is integer gedrag?

Wat is nu het juiste integere gedrag? Het antwoord op deze vraag kan voor elk individu over de gehele wereld verschillend zijn (figuur 1). Een voorbeeld is het geven van relatiegeschenken. In onze westerse bedrijfscultuur is het geven van persoonlijke cadeaus vaak iets wat de integriteit kan bedreigen, terwijl het in andere bedrijfsculturen als onbeleefd wordt ervaren als men dit niet doet. Voor een multinationale onderneming kan het daarmee dus lastig zijn om algemene, globaal geldende regels aan alle managers en medewerkers voor te schrijven.

Organisatiecultuur

Integriteit is dus niet slechts de afwezigheid van corruptie, fraude, diefstal en andere vormen van ongewenst gedrag. Het beoordelen van wat nu echt het ongewenste gedrag is, kan voor een multinationale onderneming wel eens per locatie verschillen. Integriteit behelst dan ook het zorgvuldig beoordelen van die lokale context. Integriteit wordt dan niet langer gezien als een fait accompli: als louter een kwestie van goed- of kwaadwillende mensen waarover een organisatie nu eenmaal wel of niet beschikt. Aan integriteit moet je als organisatie dus werken om continu in beeld te houden wat men met elkaar onder integriteit verstaat binnen de eigen ‘organisatiecultuur’.

Vanuit de cultuur van een organisatie valt op te maken wat het niveau van de organisatie-integriteit is. Het gaat hierbij om vragen als: vertoont het management het juiste voorbeeldgedrag, zijn doelen realistisch geformuleerd opdat deze zonder manipulatie te halen zijn, en spreken medewerkers elkaar aan op vermeend ongewenst gedrag?

De organisatiecultuur en -structuur worden vervolgens als belangrijke aanknopingspunten beschouwd om medewerkers tot integer gedrag te stimuleren. De organisatiecultuur kan daarbij worden gezien als het fundament op basis waarvan regels, procedures en afspraken worden nageleefd (zie figuur 2).

C-2006-3-Kloosterman-02

Figuur 2. Organisatiecultuur als fundament van integer gedrag.

Zoals hiervoor al aangegeven is het in de huidige globale economie voor multinationale ondernemingen belangrijk om zich te realiseren dat er niet één organisatiecultuur bestaat binnen de onderneming, maar dat deze verschillend kan zijn binnen de onderdelen van de organisatie. Dit komt doordat verschillende groepen mensen vanuit verschillende culturen deel uitmaken van dezelfde organisatie. Belangrijk voor de organisatie is dat de randvoorwaarden (de kaders) wel duidelijk zijn aangegeven. Een belangrijk beheersingsinstrument hierbij is dan om actief op de organisatiecultuur te sturen. Wanneer we dit specifiek richten op integriteit, dan spreken we over integriteitmanagement.

Normen en waarden als fundament voor het handelen

Om de verschillende internationale percepties van integer handelen te kunnen beheersen is het de kunst om het kwaliteitsaspect integriteit in te kaderen en in te vullen met iets tastbaars: waarden en normen. Deze waarden en normen vormen het kader waarin gedrag kan worden getoetst, beloond en beoordeeld. Het is hierbij de uitdaging om de optelsom van individuele normen en waarden te laten aansluiten op hetgeen een organisatie als wenselijk beschouwt. Op basis van deze waarden en normen kunnen regels worden afgesproken over welk gedrag gewenst en ongewenst is (figuur 3).

C-2006-3-Kloosterman-03

Figuur 3. Gewenst en ongewenst gedrag.

Hierbij dient onderkend te worden dat gedrag voor een groot deel wordt ingevuld door de normen en waarden die zijn ingebed in de cultuur waarbinnen mensen gewend zijn te opereren. In een onderneming in Azië zijn culturele aspecten als respect voor hiërarchie, voor leeftijd en voor de groepsharmonie veelvuldig aanwezig in de organisatiecultuur. Zo zal elk continent, land of streek een andere interpretatie geven aan de benodigde regels die voortvloeien uit ‘gemeenschappelijke’ waarden en normen. Een ander voorbeeld is ‘gelijke carrièrekansen’ voor iedereen. Als waarde zal iedereen hiermee direct kunnen instemmen, alleen de uitwerking van het begrip in bijvoorbeeld Saoedi-Arabië zal ten aanzien van de carrièrekansen van vrouwen een heel andere zijn dan in West-Europa. Deze contextafhankelijke zaken zijn belangrijk om zich te realiseren wanneer er gedacht wordt aan het managen van integriteit binnen een multinationale onderneming.

Wanneer een organisatie actief wil gaan sturen op de organisatiecultuur met het oog op integriteitmanagement, dan is het van belang inzichtelijk te hebben hoe het ethische klimaat er binnen de organisatie uitziet.

De integriteitthermometer als meetinstrument voor de integriteitcultuur binnen een organisatie

De organisatiecultuur is een belangrijk onderdeel van de beheersingsomgeving. Zij is een fundament voor een effectieve interne beheersing en beïnvloedt het integriteitsbewustzijn van de medewerkers. Maar op welke wijze kan de effectieve werking hiervan worden vastgesteld? Hoe kan de daadwerkelijke werking van een gedragscode worden bepaald? Hoe kan de effectiviteit van een klokkenluiderregeling worden vastgesteld? En wanneer is er sprake van een goede ‘tone at the top’? Zijn de beheersingsmaatregelen bekend bij alle medewerkers? Worden de maatregelen ook gedragen én uitgedragen?

Om dit goed te kunnen meten is het van cruciaal belang om medewerkers actief bij dit onderwerp te betrekken. Hun percepties en ervaringen van de gang van zaken binnen de organisatie zijn immers bepalend voor hun gedrag. Bovendien zijn medewerkers, gegeven hun dagelijkse praktijkervaringen, veelal goed in staat het integriteitklimaat te beoordelen.

Een mogelijk meetinstrument om dit ethische klimaat in kaart te brengen is de integriteitthermometer. De integriteitthermometer is een hard-copy of digitale enquête die wordt uitgezet binnen een organisatie. Het model van deze thermometer is weergegeven in figuur 4.

C-2006-3-Kloosterman-04

Figuur 4. Model van de integriteitthermometer.

Enerzijds kijkt de integriteitthermometer naar het formele beleid, de regelgeving en de beheersingsmaatregelen die er getroffen zijn, anderzijds meet de thermometer ook de acht aspecten van de ethische organisatiecultuur. Deze worden in kader 1 nader beschreven.

Kader 1. Acht dimensies van het ethische klimaat.

Helderheid

De mate van helderheid refereert aan de accuraatheid, concreetheid en volledigheid van de verwachtingen van de organisatie omtrent het integer gedrag van de medewerkers. Is het voor medewerkers helder hoe zij zich dienen te gedragen? Hoe meer medewerkers moeten handelen vanuit hun eigen discretie en morele intuïtie, zonder hierbij een richtlijn als referentiekader te ervaren, hoe hoger het risico op ongewenst gedrag.

Voorbeeldgedrag

De mate van voorbeeldgedrag refereert aan de mate waarin het management een goed voorbeeld vormt voor de organisatie en medewerkers. Medewerkers neigen het gedrag van hun leidinggevende te kopiëren. Het is om deze reden dan ook van belang dat het gedrag van leidinggevenden in lijn is met wat er organisatiebreed is afgesproken. Consistent voorbeeldgedrag vermindert de kans op ongewenst gedrag.

Uitvoerbaarheid

Uitvoerbaarheid verwijst naar de manier waarop de organisatie de medewerkers de mogelijkheid biedt om integer gedrag te vertonen. Hebben medewerkers voldoende tijd, middelen, zeggenschap en informatie om hun verantwoordelijkheden te realiseren? Indien medewerkers weinig ruimte hebben om hun verantwoordelijkheden te organiseren, is het risico op ongewenst gedrag hoger.

Betrokkenheid

De mate van betrokkenheid verwijst naar de mate waarin medewerkers zich geroepen voelen om op actieve wijze de belangen van de organisatie hoog te houden. Wanneer medewerkers het gevoel hebben dat zij niet serieus worden genomen of onrechtvaardig worden behandeld, kan dit ten koste gaan van hun loyaliteit richting de organisatie. Dit gaat gepaard met de intenties van medewerkers om ongewenst gedrag te vertonen.

Transparantie

Transparantie verwijst naar de mate waarin gedrag van medewerkers bekend is binnen de organisatie. Medewerkers die het gevoel hebben dat de pakkans erg klein is, zullen eerder in de verleiding komen zich te misdragen. In een context met een hoge mate van zichtbaarheid zullen medewerkers zich eerder geroepen voelen hun eigen gedrag en dat van hun medewerkers te corrigeren. Een lage mate van zichtbaarheid of transparantie maakt dat de controlemogelijkheden verminderen. Dit schept ruimte voor ongewenst gedrag.

Bespreekbaarheid van dilemma’s

De mate van bespreekbaarheid is af te leiden uit de mate waarin medewerkers hun dilemma’s en ongewenst gedrag bespreekbaar kunnen maken binnen de organisatie. Een slecht voorbeeld vormen organisaties waar kritiek niet wordt gestimuleerd of zelfs niet wordt getolereerd. Medewerkers worden niet ter verantwoording geroepen voor hun gedrag en medewerkers worden gemotiveerd hun oren en ogen gesloten te houden. Dergelijke culturen worden gekenmerkt door een negatieve houding tegenover kritische medewerkers.

Aanspreekbaarheid op schendingen

Aanspreekbaarheid is de mate waarin medewerkers ter verantwoording kunnen worden geroepen voor het vertonen van ongewenst gedrag en de mate waarin dit ook feitelijk gebeurt.

Handhaving

Handhaving is de wijze waarop medewerkers kunnen worden gestraft voor niet-integer gedrag en worden beloond voor integer gedrag. Sancties bevatten belangrijke gedragsstimulansen en zijn hierdoor een relevante dimensie voor de organisatiecontext. Mensen hebben – over het algemeen – de neiging om te doen waarvoor ze worden beloond en te vermijden waarvoor ze worden gestraft. Discipline voor overtreders heeft een belangrijke symbolische rol binnen organisaties; het houdt de normen hoog en behoudt de perceptie van medewerkers dat hun organisatie een plek is waar ongewenst gedrag wordt gestraft en niet wordt beloond. Wanneer de normen niet worden gehandhaafd, zal het effect van dergelijke gedragsnormen verminderen.

De integriteitthermometer is een vragenlijst die medewerkers digitaal of schriftelijk kunnen invullen. Wanneer de integriteitthermometer wordt uitgezet in een grotere organisatie is het van belang om ook vooraf een onderverdeling aan te brengen naar de verschillende locaties, business units, afdelingen, etc. Op die manier kan een vergelijking worden gemaakt tussen de verschillende onderdelen van de organisatie om zo te bezien of er niet te grote verschillen bestaan in het integriteitklimaat. Belangrijk is dan om oog te hebben voor de vertaling van de vragen in de eigen taal van medewerkers (zie ook figuur 5).

C-2006-3-Kloosterman-05

Figuur 5. Vragenlijst in de eigen taal.

De onderverdeling binnen een grote organisatie maakt het ook mogelijk een benchmark te maken met het gemiddelde voor de sector of tussen de verschillende afdelingen. In figuur 6 is een dergelijk benchmarkresultaat weergegeven. In dit voorbeeld valt er een onderscheid te constateren tussen de Europese Unie en de Verenigde Staten. Zoals we hiervoor hebben gezien is het opereren in een internationale omgeving gebonden aan de lokale culturen. Dit zou dan ook een verklaring kunnen zijn voor de kleine verschillen in de scoring tussen de twee regio’s.

C-2006-3-Kloosterman-06

Figuur 6. Benchmark van thermometerresultaten.

De uiteindelijke resultaten van de integriteitthermometer bieden het management de mogelijkheid om te sturen op die zaken die van belang zijn voor het creëren van een goed ethisch klimaat. Wanneer er bijvoorbeeld laag gescoord wordt op ‘helderheid’, dan betekent dit dat de eigen regels onduidelijk zijn of de gedragscode niet duidelijk is voor de medewerkers. Het actief sturen op het creëren van een beter ethisch klimaat noemen wij integriteitmanagement. Hierbij kan bijvoorbeeld gedacht worden aan het opstellen van een gedragscode, het trainen van medewerkers en het instellen van een vangnetregeling.

Casus: De integriteitthermometer als sleutel tot inzicht

Een gerenommeerd beveiligingsbedrijf had moeite met het in kaart brengen van het ‘ethisch gehalte’ van de organisatie. Men had voornamelijk twijfels in hoeverre het bedrijf zelf een voedingsbodem leverde voor het ontstaan van ongewenste gedragingen. KPMG heeft hierbij aan de hand van de integriteitthermometer, met een respons van meer dan vijftig procent, het organisatieklimaat op een aantal punten geschetst en de risicogebieden benoemd. Op basis van de resultaten van de integriteitthermometer konden er concrete acties worden ondernomen door het management, die passend waren bij de praktijk van medewerkers. Uit de tweede meting met de integriteitthermometer bleek dat de moeilijkheden in het werk tegenwoordig beter worden erkend door het management, waardoor medewerkers zich meer ondersteund voelen in hun dagelijkse werkzaamheden.

Casus: De integriteitthermometer als start van een gedragscodetraject

Binnen een grote gemeente werd er een gedragscodetraject opgestart. Voordat men een code met de medewerkers wilde ontwikkelen, wilde men weten welke integriteitonderwerpen er binnen de gemeente speelden. De resultaten van de integriteitthermometer lieten duidelijk zien dat er behoefte was aan meer heldere regelgeving en dat er op een aantal afdelingen minder goed werd omgegaan met ongewenst gedrag.

Het daaropvolgende integriteittraject werd zo opgesteld dat de onderwerpen die naar boven waren gekomen met de integriteitthermometer, werden vertaald naar heldere regelgeving. Daarnaast werden leidinggevenden en medewerkers van de afdelingen getraind in het vertonen van aansprekend gedrag.

Casus: De integriteitthermometer als verantwoordingsinstrument

Een grote bank wilde graag inzicht in de ‘compliancecultuur’ binnen de organisatie. Dit wil zeggen dat men wilde weten of het voldoen aan wet- en regelgeving ook doorgedrongen was in de cultuur van de organisatie. De afgelopen periode was er veel inspanning geleverd op het gebied van AO/IC, maar ook ten aanzien van het bewust maken van medewerkers waarom compliance belangrijk was.

De integriteitthermometer gaf inzicht in de organisatiecultuur binnen de bank. Hiermee kon aan de externe omgeving worden getoond dat naast de formele regelgeving ook de cultuur binnen de bank er een was die aansloot op de verwachtingen van die externe omgeving.

Resumé

In dit artikel is uiteengezet dat voor grote organisaties waar mensen uit verschillende culturen deel van uitmaken, het managen van integriteit een kritische succesfactor is. Om te kunnen managen is het noodzakelijk om te weten wat het integriteitklimaat is. De integriteitthermometer is een instrument om het ethische klimaat binnen een organisatie te meten. Dit kan een goede manier zijn om inzichtelijk te maken op welke gebieden integriteitmanagement moet worden ingezet. Tevens kan de integriteitthermometer dienen als monitoringmodel.

Literatuur

Mr. J.M. Pleunes-Caljouw en drs. M. de Kiewit, Monitoren en auditen van softcontrols als sluitstuk van de compliancecyclus, Tijdschrift voor compliance, 2006, nummer 2.

NOREA Code of Ethics globaal toepasbaar?

In juli 2006 is de vernieuwde Code of Ethics ingevoerd voor alle register EDP-auditors. De Code of Ethics vervangt de gedrags- en beroepsregels voor EDP-auditors. Integriteit, onafhankelijkheid en objectiviteit zijn belangrijke waarden voor auditors. Dit artikel gaat na hoe deze code kan bijdragen aan het vasthouden van het integriteitsniveau van de IT-auditors. Daarnaast komt aan de orde hoe een goede implementatie van de Code of Ethics nog verder kan bijdragen tot een groter integriteitsbesef binnen de beroepsgroep van register EDP-auditors.

Inleiding

Een integere reputatie wordt door veel ondernemers als belangrijke bestaansvoorwaarde gezien. Desondanks zijn er diverse voorbeelden van ondernemingen die zich toch te buiten gaan aan fraudes, boekhoudschandalen, witwasoperaties, corruptie en dergelijke. Een standaardreactie op dit soort incidenten is om over te gaan tot het instellen van nieuwe interne en externe regelgeving. Binnen een bedrijf worden dan bijvoorbeeld naar aanleiding van een incident de AO-beschrijvingen uitgebreid met extra controles en regels. Een vorm van uitbreidende externe regelgeving is de Sarbanes-Oxley wet. Als reactie op de geruchtmakende boekhoudfraudes in de Verenigde Staten werd deze wet geïntroduceerd. De Sarbanes-Oxley wet stelt vele verplichtingen aan bedrijven die beursgenoteerd zijn.

Een andere reactie op incidenten is dat er gedragscodes worden ingesteld. Een voorbeeld hiervan is de NOREA Code of Ethics voor register EDP-auditors. Deze code sloot aan bij de internationale IFAC Code of Ethics. Voor de NOREA waren het dus niet zozeer incidenten in Nederland die de aanleiding vormden voor het opstellen van een gedragscode, maar het zoeken van aansluiting bij een internationaal aanvaarde code. Door het uitvaardigen van deze code weten register EDP-auditors wat er van hen verwacht wordt op basis van een internationaal breed geaccepteerde standaard. Een code schept op deze manier dus duidelijkheid voor de beroepsbeoefenaren maar ook voor de externe omgeving. Alhoewel een gedragscode een goed instrument is om integriteit te bevorderen zijn hier ook wel wat opmerkingen bij te plaatsen. Een code is natuurlijk alleen nog maar een stuk papier, het gaat om de toepassing in de praktijk. Daarnaast is het de vraag of regels wel zo uniform toegepast kunnen worden als op het eerste gezicht lijkt. In de praktijk blijkt namelijk keer op keer dat mensen binnen organisaties zich niet zozeer door regels laten leiden, maar door hun eigen morele oordeel, of het morele oordeel van hun leidinggevende. Het zou natuurlijk ideaal zijn als de nieuwe code de auditors kan helpen om die morele afweging beter te maken.

In juli 2006 is de nieuwe Code of Ethics ingevoerd voor alle register EDP-auditors. Dit artikel gaat na hoe deze code kan bijdragen aan de integriteit van de IT-auditors. Hoe een goede implementatie van de Code of Ethics kan stimuleren tot een groter integriteitsbesef binnen de beroepsgroep van register EDP-auditors, komt eveneens aan de orde.

Integriteit als kwaliteitsbegrip en als ethisch uitgangspunt

Integriteit is als begrip lastig te definiëren. Het begrip integriteit is afgeleid van het Latijnse woord ‘in-tangere’, dat kan worden vertaald als ‘niet aanraken’ of ‘niet aangeraakt zijn’. Het verwijst met andere woorden naar iets wat, of iemand die, onbesmet, onaangetast en ongekreukt is. Het woordenboek spreekt van ‘rechtschapenheid’, ‘onomkoopbaarheid’ en ‘ongeschondenheid’. Integriteit wordt vaak in één adem genoemd met voorbeelden van wat het niet is: fraude, corruptie. Dit maakt van integriteit al snel een beladen onderwerp. Integriteit is echter juist ook een positief begrip omdat het gaat om zaken als authenticiteit, oprechtheid en heelheid.

EDP-auditors kennen integriteit vaak als kwaliteitsbegrip. Hierbij gaat het om een aspect waaraan toetsing kan plaatsvinden. Met het kwaliteitsaspect (data-) integriteit wordt de consistentie en juistheid van gegevens bedoeld. Integriteit wordt dan gedefinieerd als de mate waarin het object (gegevens en informatie-, technische en processystemen) in overeenstemming is met de afgebeelde werkelijkheid.

Binnen de beroepsgroep van EDP-auditors is er natuurlijk ook aandacht voor integriteit als ethisch uitgangspunt. Dit is zelfs opgenomen in de Code of Ethics voor EDP-auditors (zie kader 1).

Kader 1. De Code of Ethics in Nederland aanvaard.

Algemene Vergadering NOREA stemt in met Code of Ethics

Tijdens de extra Algemene Vergadering op 13 juli 2006 is ingestemd met de aanvaarding van de Code of Ethics voor IT-auditors ter vervanging van het Reglement Gedrags- en Beroepsregels Register EDP-Auditors (GBRE). Daarnaast heeft het bestuur een mandaat gekregen om de statuten en overige reglementen overeenkomstig aan te passen, d.w.z. verwijzingen naar de GBRE worden vervangen door verwijzingen naar de Code of Ethics. De Code of Ethics geldt derhalve met ingang van 14 juli 2006.

In deze code staat het begrip integriteit als apart artikel vermeld (Section 110). Het is zeer toe te juichen dat er binnen de beroepsgroep van register EDP-auditors wordt gestreefd naar uniforme, breed gedragen ethische uitgangspunten. Toch is het belangrijk om zich te realiseren dat de wereldwijde toepasbaarheid van een code gebonden is aan de specifieke context van elke auditor.

De context als bepalende factor voor het handelen

Het begrip integriteit als ethisch richtsnoer is zeer bewonderenswaardig, het is echter belangrijk te bedenken dat integriteit tegelijkertijd toch een wat subjectief begrip is. Wat de ene persoon volstrekt integer vindt zal voor iemand anders ‘not done’ zijn. Het begrip wordt dus door personen anders ervaren en ingevuld. Iedereen heeft er een beeld bij maar dit beeld is niet voor iedereen gelijk. Daar komt nog eens bij dat wanneer mensen geconfronteerd worden met een lastige beslissing, zij die keuze vaak maken op basis van intuïtie en gevoel, en niet zozeer op basis van regelgeving. Het meest treffende voorbeeld hiervan is het experiment van de psycholoog Milgram. Hij liet zien dat wanneer mensen in een bepaalde context geplaatst worden ze dingen doen die volstrekt niet-integer zijn (zie kader 2). Het stellen van regels wil dus geenszins zeggen dat daarmee er voldoende waarborgen zijn voor ethisch gedrag.

Kader 2. Het experiment van Milgram.

Vanuit de psychologie is op verschillende manieren onderzoek gedaan naar het volgen van autoriteit. Het beste en misschien wel meest extreme voorbeeld is het experiment van Milgram. In dit experiment werd de bereidheid van deelnemers gemeten om aanwijzingen op te volgen van een autoriteit, zelfs als die aanwijzing in strijd was met het eigen geweten.

Milgram vroeg proefpersonen om mee te werken aan een onderzoek naar het effect van elektrische shocks op het geheugen. De proefpersoon moest daarbij stroomschokken toedienen aan een andere proefpersoon (die in werkelijkheid een acteur was: er werden helemaal geen stroomschokken toegediend). Het onderzoek wilde bekijken tot op welk niveau mensen hun eigen geweten ondergeschikt maakten aan de autoriteit van de onderzoeker die het experiment leidde. De proefpersoon werd dus door de onderzoeker verteld wat de proefpersoon moest doen. Het experiment onderzocht dus in werkelijkheid de relatie tussen gehoorzaamheid en autoriteit en tot welk niveau men het eigen morele geweten boven de autoriteit zou stellen.

Verbazingwekkend veel mensen zouden de proefpersoon blootstellen aan zeer hoge, gevaarlijke en zelfs dodelijke stroomschokken.1 Alhoewel andere psychologen vooraf dachten dat slechts een paar sadisten bereid zouden zijn om het maximumvoltage van 450 volt te geven, waren de resultaten zeer schokkend. Bij de eerste reeks experimenten gaf 65 procent van deelnemers de maximumschok van 450 volt, hoewel velen zich er zeer ongemakkelijk bij voelden. Geen deelnemer hield op vóór het 300 volt-niveau!2

Het onderzoek toonde daarmee aan dat wanneer een autoriteit geaccepteerd wordt, het persoonlijke geweten daarbij ondergeschikt wordt. Belangrijk om zich te realiseren is dat de context dus zeer bepalend is voor het handelen van mensen. Dit betekent dus ook dat regels (gij zult niet doden!) in bepaalde situaties niet worden opgevolgd. Het experiment toonde daarmee meteen de beperking aan van ‘regels’.

Bronnen:

  1. Milgram, S., Obedience to authority, New York, Harper and Row, 1974.
  2. Blass, T., The Milgram paradigm after 35 years: Some things we now know about obedience to authority, in: Journal of Applied Social Psychology, 29, 1999, p. 955-978.

Het hebben van een gezamenlijke Code of Ethics is derhalve een mooi uitgangspunt, maar de toepassing ervan kan per context verschillen. Wanneer we naar de IFAC Code of Ethics kijken, zien we hier bijvoorbeeld in staan dat integriteit belangrijk is als waarde voor accountants en auditors. Letterlijk staat er: ‘The principle of integrity imposes an obligation on all professional accountants to be straightforward and honest in professional and business relationships. Integrity also implies fair dealing and truthfulness.’[IFAC Code of Ethics, , section integrity, p. 9, versie 2005 (p .9 verwijst naar de versie waarin de oorspronkelijke IFAC-tekst staat naast de NOREA-vertaling).] Een mooie uitspraak en niemand zal het hiermee oneens kunnen zijn. Wie is er immers tegen eerlijkheid? Moeilijkheden ontstaan er echter pas wanneer iemand in de dagelijkse praktijk tegen een probleem aanloopt. Want wat is ‘honest business relationships’? Hoeveel marge mag je nog ‘eerlijk’ maken? Daar hebben mensen toch vaak heel uiteenlopende ideeën over. Dit is natuurlijk al in Nederland zo, maar wanneer we ‘eerlijk zakendoen’ over de grens nemen, dan zullen we zien dat in andere landen er andere normen gelden ten aanzien van het zakendoen. Kortom: wat is ‘eerlijk’? Dit wordt bepaald door de specifieke omstandigheden die er op dat moment gelden, ofwel: de ‘context’.

Een ander voorbeeld vanuit de internationale context is de manier waarop medewerkers omgaan met de hiërarchie binnen hun eigen organisatie. Wanneer Nederlandse medewerkers het bijvoorbeeld niet eens zijn met het oordeel van hun baas zullen zij dit over het algemeen makkelijker kenbaar maken dan medewerkers in Angelsaksische of Aziatische landen. Voor IT-auditors is het altijd erg belangrijk om hun eigen objectiviteit te blijven waarborgen. De hiërarchische context zoals die hiervoor werd geschetst, geeft al aan dat dit in bepaalde landen misschien moeilijker is dan in andere landen. In de NOREA-code staat daarom ook geschreven: ‘De IT-auditor accepteert niet dat zijn professioneel of zakelijk oordeel wordt aangetast door een vooroordeel, belangentegenstelling of ongepaste beïnvloeding door een derde.’[NOREA Code of Ethics, Hoofdstuk A-120 Objectiviteit, p. 10, versie 2006.] Tegelijkertijd heeft de code er oog voor dat dit vooral in de praktijk op de proef zal worden gesteld: ‘De IT-auditor kan in een situatie komen te verkeren waarin zijn objectiviteit in het gedrang komt. Het is onmogelijk al deze situaties te beschrijven.’[NOREA Code of Ethics, Hoofdstuk A-120 Objectiviteit, p. 10, versie 2006.] De NOREA Code of Ethics geeft dus nadrukkelijk het uitgangspunt weer (objectiviteit) maar heeft tegelijkertijd oog voor het feit dat dit altijd in de context van de praktijk dient te worden vormgegeven. De verantwoordelijkheid om de objectiviteit te waarborgen wordt daarmee neergelegd bij de individuele IT-auditor.

Het belang van een goede implementatie van de NOREA Code of Ethics

De Code of Ethics laat duidelijk een eigen verantwoordelijkheid bestaan bij de IT-auditor zelf en dit is goed. We kunnen immers niet vooraf alle mogelijke zaken beschrijven in een code. Dit zou de code enorm omvangrijk maken. Bovendien hebben we gezien dat de context soms zeer bepalend kan zijn voor het handelen van mensen. Integriteit kan dus niet worden gezien als een fait accompli: als louter een kwestie van goed- of kwaadwillende mensen waarover een organisatie nu eenmaal wel of niet beschikt. Zoals het experiment van Milgram al liet zien kunnen goede mensen bijvoorbeeld heel slechte dingen doen als ze in een bepaalde context worden geplaatst. Ook ‘goede’, nette IT-auditors kunnen dus heel verkeerde dingen gaan doen als zij in een bepaalde context komen te staan.

Bij het uitvaardigen van regels dient er daarom ook rekening te worden gehouden met de context. De NOREA heeft hier nadrukkelijk ook oog voor gehad en heeft een belangrijke stap gezet door de vertaling van de IFAC Code of Ethics naar de Nederlandse IT-auditcontext en in de Nederlandse taal.

Desondanks liet het voorbeeld van objectiviteit al zien dat de NOREA ook erkent dat de code nooit vooraf alle antwoorden zal kunnen geven. De NOREA Code of Ethics is daarmee dus geen wet van Meden en Perzen geworden! De eigen verantwoordelijkheid van IT-auditors staat centraal. Bij de implementatie van de code dient dit kenmerkende aspect duidelijk te worden benadrukt. Het enkel communiceren van een document is niet voldoende! Het vragen naar de eigen verantwoordelijkheid van IT-auditors vereist ook dat er wat gedaan wordt aan bewustwording en training van de beroepsgroep.

Het op schrift stellen van een mooi document met goed geformuleerde uitgangspunten is slechts het begin. Zonder een goede implementatie kan een code zelfs schade toebrengen aan de geloofwaardigheid en het imago van de beroepsgroep. Als de code een eendagsvlinder blijft, niet meer dan een lege huls of slechts window-dressing, kan hij namelijk zelfs averechts werken. De code verdwijnt dan onder in de bureaula of in het ronde archief ([Kapt02]). Daarom is het van belang dat er structureel aandacht, toelichting en training wordt gegeven over de code.

‘Maar IT-auditors zijn mensen met een post-doctorale opleiding! Daarvan zou toch verwacht kunnen worden dat zij verstandig genoeg zijn om zelf in te schatten hoe zij kunnen werken met een code?’ Dit is slechts ten dele waar. De kracht van een code ligt juist in het bespreken van ethische vraagstukken uit de praktijk en het van daaruit werken aan verbeteringen. Op die manier zullen IT-auditors getraind worden in hun bewustwording wat het juiste ethische handelingsalternatief is en wat mooie termen als ‘integriteit’ en ‘objectiviteit’ voor hun dagelijkse praktijk betekenen. De werkgevers van de IT-auditors zouden hierin een leidende rol moeten spelen, een goed ethisch klimaat is immers ook en vooral voor hen van belang.

Daarnaast dient de code het begin te zijn van maatregelen die de integriteit van de beroepsgroep bevorderen (zie ook kader 3). Naast het hebben van een code is het bijvoorbeeld ook van belang dat:

  • leiderschap wordt getoond;
  • er aandacht is voor de organisatieculturen waarin IT-auditors hun werk moeten doen;
  • de borging van integriteit binnen de organisaties waarin IT-auditors werkzaam zijn en binnen de NOREA is vormgegeven;
  • er een vangnet voor ongewenst gedrag is;
  • er een toets op naleving plaatsvindt;
  • er monitoring plaatsvindt.

Kader 3. Inrichting van integriteitmanagement.

Integriteitmanagement: inrichting

Er bestaat niet een eenduidige methodiek op basis waarvan inrichting van integriteitmanagement kan plaatsvinden. Voor elke organisatie is integriteitmanagement verschillend. Wel zijn er basiselementen die van belang zijn bij de inrichting van integriteitmanagement. Deze elementen zijn bijvoorbeeld:

  • Gedragscode en regelingen. Zoals reeds aangegeven is het bepalen van gemeenschappelijke waarden en normen in een internationale context niet eenvoudig, maar wel zeer belangrijk. Een succesvolle code komt vanuit de organisatie zelf waarbij nationale en regionale verschillen inzichtelijk worden en bespreekbaar zijn.
  • Leiderschap. Wie integer handelen verlangt, zal zelf een goed voorbeeld moeten zijn. De integriteit van een internationaal opererend bedrijf begint bij de integriteit van de top.
  • Organisatiecultuur. Zoals eerder in dit artikel uiteengezet kan de organisatiecultuur worden gezien als het fundament waarop procedures en maatregelen kunnen bouwen. In deze visie kan organisatiecultuur als resultante worden gezien van integriteitmanagement.
  • Borging van integriteit. Om een gewenste organisatiecultuur te bereiken en te behouden is het van belang gewenst gedrag te verankeren in de bedrijfsprocessen. Belangrijke elementen hierbij zijn bijvoorbeeld de beloningssystematiek en wervings- en selectieprocedures.
  • Vangnet. Goed integriteitbeleid en verantwoord bestuur bieden mensen ruimte om ongewenst gedrag en dilemma’s te melden en bespreekbaar te maken. De meest gewenste situatie is dat medewerkers dilemma’s of schendingen melden in de eerste lijn, bij de eigen leidinggevende. Een organisatie waarin integriteit bespreekbaar is, leert continu van de integriteitsbeleving van medewerkers, in alle lagen van de organisatie, in binnen- en buitenland. Als medewerkers om een bepaalde reden niet in de eerste lijn willen of kunnen melden, is de implementatie van een meldstructuur voor incidenten en vragen over integriteit is van groot belang.
  • Naleving. Geloofwaardige aandacht voor integriteit kan niet zonder een toets op de naleving van gestelde normen en correctie op ongewenst gedrag. Hiertoe dient sanctiebeleid te worden ontwikkeld.
  • Monitoring. Meten is weten. Een veelheid aan initiatieven om een bepaalde organisatiecultuur te bereiken biedt organisaties nog geen inzicht in de mate waarin ze ‘in control’ zijn. Het wordt steeds belangrijker om verantwoording af te kunnen leggen over maatregelen ten aanzien van organisatie-integriteit. Er zijn inmiddels beproefde methodieken om deze zogenaamde ‘soft controls’ in kaart te brengen en zodoende periodiek verantwoording over integriteit te kunnen afleggen.

Concrete acties vanuit de NOREA voor een goede implementatie van de Code of Ethics

De NOREA heeft ook oog voor het belang van een goede implementatie. Daarom zijn er al enkele acties ontplooid. Allereerst is de NOREA-code verplichte stof in de opleiding voor toekomstige RE’s. De bestaande RE’s zijn via de eis van permanente educatie ook formeel verplicht om kennis te nemen van de inhoud van de vernieuwde code. De NOREA faciliteert dit ook door het uitgeven van een boekje dat alle RE’s zullen ontvangen. Belangrijk is ook dat de NOREA het belang inziet dat informeren alleen niet voldoende is. Men moet ook met elkaar spreken over de inhoud van de code en wat die voor eenieder betekent in het dagelijks werk. Hiervoor organiseert de NOREA voorlichtingssessies in alle regio’s.

Resumé

De vernieuwde NOREA Code of Ethics is in juli 2006 ingevoerd voor alle register EDP-auditors ter vervanging van de bestaande gedrags- en beroepsregels. Het is belangrijk zich te realiseren dat de code vooral in de context van de praktijk zal worden geïnterpreteerd en dat regels niet zo eenduidig zijn als ze vooraf lijken. De NOREA heeft zich dit vooraf ook gerealiseerd door de code naar de Nederlandse context te vertalen en ook iedereen te informeren via opleiding en regiobijeenkomsten. Daarnaast geeft de NOREA ook expliciet aan dat de code een sterke nadruk legt op de eigen verantwoordelijkheid. Het zou goed zijn als deze eerste stap van het formuleren van een goede code en het informeren een vervolg krijgt door een goede implementatie in samenhang met andere integriteitbevorderende maatregelen. Hierbij is ook een belangrijke taak weggelegd voor de werkgevers van de IT-auditors.

Literatuur

[IFAC05] IFAC Code of Ethics, versie 2005.

[Kapt01] Kaptein, M., De integriteitbarometer voor organisaties, Bedrijfskunde, jaargang 73, 2001, nummer 3.

[Kapt02] Kaptein, M., H. Klamer en A. Wieringa, De Bedrijfscode, Stichting NCW, Ethicon, Stichting Beroepsmoraal en Misdaadpreventie, Den Haag.

[NORE06] NOREA Code of Ethics, versie 2006.

[Pleu06] Pleunes-Caljouw, J. en M. de Kiewit, Monitoren en auditen van softcontrols als sluitstuk van de compliancecyclus, Tijdschrift voor compliance, 2006, nummer 2.

Verified by MonsterInsights