Skip to main content

Blog Archives

Older posts
Newer posts

Assurance in de cloud

Inleiding

Cloud computing is zonder twijfel hét fenomeen in de IT van vandaag. IT-diensten als basisvoorziening vanuit het internet, wat cloud computing in essentie behelst, is anno 2010 het hypestadium ontgroeid. Een recent onderzoek van KPMG wijst uit dat bijna zestig procent van de Nederlandse bedrijven al gebruikmaakt van cloud computing voor één of meer onderdelen van hun IT of voornemens is om binnen twaalf maanden over te stappen naar een oplossing in de cloud. In hetzelfde onderzoek geeft voorts het leeuwendeel van de respondenten aan in cloud computing het toekomstig IT-model te zien ([KPMG10]).

Terwijl de gevestigde pioniers van cloud computing, waarvan Salesforce.com, Amazon en Google de bekendste zijn, hun dienstenportfolio gestaag uitbreiden, hebben vrijwel alle grote IT-leveranciers hun propositie in de cloud gereed om tegemoet te komen aan de snel stijgende vraag naar cloud computing. Microsoft, Cisco en IBM bieden, al dan niet in samenwerking met andere softwarebedrijven en IT-integrators, steeds meer clouddiensten aan voor complete bedrijfsprocessen. Ook andere grote spelers zoals SAP en Oracle investeren fors in hun cloudomgevingen, deels als vervanging/opvolging van en deels als toevoeging aan hun bestaande producten.

Te midden van de euforie rond de cloud is inmiddels ook het besef doorgedrongen dat cloud computing verregaande invloed heeft op de mate van assurance voor jaarrekeningcontroles. Aspecten die van belang zijn voor met name de financiële bedrijfsprocessen – toegangsbeheer & autorisaties, wijzigingsbeheer en backup & recovery – hebben in de cloud andere risicoprofielen dan op traditionele systemen. In vrijwel alle gevallen impliceert cloud computing namelijk een externe dataopslag bij de leverancier en het delen van IT-resources.

Met de gestaag voortschrijdende verschuiving van de lokaal geïnstalleerde en onderhouden IT, ook wel on-premise IT genoemd, naar de cloud dienen potentiële afnemers derhalve adequaat te zijn ingelicht. Hierbij staan de volgende hoofdvragen vanuit het perspectief van de afnemer centraal:

  • Wat is cloud computing?
  • Wat zijn de voordelen van cloud computing?
  • Wat is de impact van cloud computing op de mate van assurance?

Dit artikel geeft antwoord op deze drie vragen.

Wat is cloud computing?

Een zoekopdracht op Google of op Bing levert niet minder dan honderd verschillende definities, kenmerken en meningen op van cloud computing. Sommigen spreken van ‘applicaties op het internet’ of ‘computationele stijl waarbij IT schaalbare en elastische mogelijkheden biedt die worden geleverd als dienst aan externe klanten via het gebruik van internettechnologie’, terwijl anderen het fenomeen nuanceren met aanduidingen als ‘oude wijn in nieuwe zakken’. Er ontbreekt klaarblijkelijk een consensus over wat cloud computing nu precies is.

Simpel geredeneerd houdt cloud computing het aanbod van IT-toepassingen in waarbij gebruik wordt gemaakt van het internet. Het internet wordt vaak metaforisch afgebeeld als een wolk (‘cloud’), vandaar de term cloud computing. Bekende voorbeelden van clouddiensten zijn Gmail, Hotmail en Apple MobileMe.

De reden dat dit ogenschijnlijk eenvoudige concept niet eenduidig wordt uitgelegd door leveranciers, IT-analisten en academici, ligt in het feit dat cloud computing niet alleen een technologische component kent, maar tevens een belangrijke businesscomponent.

Technisch bezien is cloud computing gebaseerd op reeds bestaande technologieën zoals virtualisatie, web services, shared data caches, network computing en grid computing. En ook het aanbieden van IT-toepassingen over het internet was als ASP (Application Service Provider) al een decennium beschikbaar. Oude wijn in nieuwe zakken dus.

Het commercieel aanbieden van IT-toepassingen over het internet is echter economisch levensvatbaar geworden door drie recente ontwikkelingen. Ten eerste zijn de eerdergenoemde technologieën, waarvan de virtualisatie en web services de belangrijkste zijn, de laatste vijf jaren verfijnd en breder toegepast. Ten tweede zijn publieke breedbandnetwerken beschikbaar gekomen. Ten derde heeft er een enorme schaalvergroting van IT-resources plaatsgevonden bij enkele leveranciers, die anno 2010 de voornaamste spelers zijn in de cloud computing-markt.

De businesscomponent van cloud computing ligt in het principe dat het bezit en eigenaarschap van IT-resources, zoals applicatie of infrastructuur, wordt gescheiden van het gebruik. Dit heet ook wel on-demand IT. De IT-resource blijft bij on-demand toepassingen eigendom van de leverancier: de afnemer betaalt dus alleen voor het gebruik van de dienst en heeft geen lokale installatie van de software en/of hardware, dit in tegenstelling tot het traditionele on-premise model. De afnemer behoeft dus met cloud computing geen lokale IT-resources: een toegang tot het internet is voldoende (zie figuur 1).

C-2010-3-Chung-01

Figuur 1. On-premise vs. cloud computing.

Daarbij heeft cloud computing de volgende kenmerken:

  • Externe dataopslag. In tegenstelling tot on-premise IT zijn de bedrijfsdata bij cloud computing doorgaans opgeslagen op de locatie van de leverancier.
  • Multi-tenancy. IT-resources worden zoveel mogelijk gedeeld met verschillende afnemers.
  • Huur van diensten. Afnemers betalen voor de dienst (pay-as-you-go of als abonnement) in plaats van voor licenties en/of hardware.
  • Elasticiteit. Clouddiensten kunnen vrijwel terstond worden gebruikt en kunnen eenvoudig worden opgeschaald en afgebouwd.

Het is mogelijk om de mate van multi-tenancy te beperken tot één afnemer of een selecte groep van afnemers. Deze vorm van cloud computing heet private of dedicated cloud computing als alternatief op de gangbare public cloud computing. Voor beide vormen geldt evenwel dat de data van de afnemer zijn opgeslagen op de locatie van de leverancier.

C-2010-3-Chung-02

Figuur 2. Private cloud en public cloud.

Clouddiensten kunnen worden aangeboden op verschillende lagen van de IT. Op de softwarelaag wordt dit Software-as-a-Service (SaaS) genoemd. Platform-as-a-Service (PaaS) levert IT-diensten op de platformlaag, zoals een besturingssysteem of een applicatieraamwerk; additionele software moet dan wel door afnemers worden ontwikkeld of worden geïnstalleerd. Infrastructure-as-a-Service (IaaS) levert technische infrastructuurcomponenten zoals opslag, memory, CPU en netwerk. Additionele platforms en software dienen te worden geïnstalleerd door de afnemer (zie figuur 3).

C-2010-3-Chung-03

Figuur 3. Verschillende lagen van cloud computing.

Enkele leveranciers bieden interne cloudoplossingen aan waarbij de interne IT gebruikmaakt van cloud computing-technologieën. Aangezien deze interne vorm van cloud computing volledig afhankelijk is van interne, on-premise IT, is het zeer de vraag of deze vorm wel cloud computing genoemd kan worden. Interne cloud zal derhalve in dit artikel buiten beschouwing blijven.

Wat zijn de voordelen van cloud computing?

Het succes van cloud computing hangt deels samen met het feit dat de bestaande, on-premise IT, tegen steeds meer technische beperkingen aanloopt terwijl de kosten voor implementatie en onderhoud van IT-systemen nauwelijks meer in de hand te houden zijn. Outsourcing en offshoring hebben de problematiek slechts ten dele opgelost en de beloofde kostenbesparing bleek in de praktijk zelden haalbaar. Cloud computing biedt in dit perspectief dé ideale oplossing: de IT in delen of in haar geheel inclusief alle hard- en software kan de deur uit, het beheer wordt opgeheven, alle benodigde IT-diensten worden afgenomen via het internet en de kosten zijn transparant en relatief eenvoudig te beheersen.

Meer flexibiliteit

Uit een recent onderzoek van KPMG komt naar voren dat bijna zestig procent van de afnemers van cloud computing meer flexibiliteit als het belangrijkste voordeel ervaart. IT-diensten vanuit de cloud kunnen snel worden ingekocht en gebruikt aangezien de installatie reeds is gedaan door de leverancier met alle bijbehorende elementen zoals beheer, fysieke faciliteit en beveiliging. Dit staat in schril contrast met langdurige en riskante implementatietrajecten die zo kenmerkend zijn voor traditionele on-premise oplossingen ([KPMG10]).

Cloud computing kent ook het voordeel dat ontwikkeling en aanpassing grotendeels uit het zicht van de afnemer blijven. Idealiter levert de afnemer alleen de specificaties en eisen aan waarna de leverancier de vernieuwingen/veranderingen doorvoert op zijn eigen IT-omgeving. De enige verplichtingen van de afnemer zijn functionele tests en acceptatie. Hinderlijke updates op IT-systemen behoren daarmee tot het verleden.

C-2010-3-Chung-04

Figuur 4. Baten van cloud computing (bron: KPMG’s Cloud Computing Survey).

Kostenbesparing

Operationele IT-kosten kunnen met cloud computing significant worden verlaagd aangezien dit model geen grootschalige, kostbare en risicovolle implementaties van IT-resources kent aan de kant van de afnemer – alle installaties staan immers op de servers van de leverancier. Daarbij komen ook alle beheerkosten om de diensten continu beschikbaar te stellen voor rekening van de leverancier. Bovendien kan er flink worden bespaard op hardware en de kostbare benodigdheden zoals serverruimten, koelinstallaties en elektriciteit. De kosten die aan de klanten worden doorberekend zijn relatief laag dankzij het verkregen schaalvoordeel en centralisatie van (beheer)kennis en ervaring.

Lagere kosten voor gebruik kunnen tot stand komen doordat er niet meer wordt gewerkt met vaste kosten bij aanschaf gevolgd door jaarlijkse onderhoudskosten, die meestal het meervoudige van de aanschafprijs van de betreffende IT-resource bedragen. Bij cloud computing wordt namelijk alleen het gebruik van de dienst in rekening gebracht aangezien de IT-resource in bezit van de leverancier blijft. Gebruiksabonnementen zijn nog steeds de regel al raakt ‘pay-as-you-go’ de laatste jaren in zwang, waarbij de klant betaalt per keer dat de dienst wordt aangeroepen. Het voordeel van ‘pay-as-you-go’ is dat er alleen wordt betaald voor diensten die daadwerkelijk worden gebruikt en onnodige vaste kosten worden voorkomen.

Wel moet worden opgemerkt dat ofschoon de initiële kosten van cloud computing aanmerkelijk lager zijn dan bij on-premise IT, de kosten van cloud computing door de hele lifecycle van de betreffende IT-resource constant blijven bij onveranderde vraag. De kosten bij lokale installaties zullen daarentegen geleidelijk afnemen na afschrijvingen. Kostenbesparing met cloud computing is dus sterk afhankelijk van de duur van de product lifecycle. Hoe langer een IT-resource wordt gebruikt, hoe lager het relatieve voordeel van cloud computing is ten opzichte van on-premise IT ([Dube07]).

Betere schaalbaarheid

Cloud computing biedt ook het voordeel dat het gebruik van de IT-resources zowel opwaarts als neerwaarts kan worden bijgesteld, hetgeen de schaalbaarheid van de IT verbetert.

Door het gebruik van verschillende vormen van virtualisatie en load-balancing, kunnen cloud computing-diensten zowel snel worden opgeschaald als afgebouwd. In tegenstelling tot bij on-premise IT is capaciteit nooit overbodig/inactief en nooit schaars.

C-2010-3-Chung-05

Figuur 5. Schaalbaarheid van cloud computing.

Wat is de impact van cloud computing?

Cloud computing is niet gevrijwaard van implicaties en gevaren. Ofschoon anno 2010 het aantal grote incidenten met betrekking tot veelgebruikte cloud computing-oplossingen in verhouding tot het aantal klanten relatief gering is, hebben Google, Amazon en Microsoft de laatste jaren meerdere kritieke lekken in hun cloud moeten dichten. Onlangs werden zwakheden in Hotmail blootgelegd door hackers waarbij illegale toegang tot duizenden accounts kon worden verkregen. Amazon’s Elastic Cloud viel ten prooi aan botnets en door lekken in Google’s Web Service konden onbevoegden zich toegang verschaffen tot accounts en wachtwoorden.

Ofschoon deze incidenten werden veroorzaakt door verschillende zwakheden van technische en procesmatige aard, in alle gevallen werden de data van de afnemer bij de cloud computing-leverancier opgeslagen en gecompromitteerd. Hierbij werd in ieder geval één belangrijk punt naar voren gebracht: de afnemer is bij cloud computing in zeer sterke mate afhankelijk van de volwassenheid van de leverancier.

In de navolgende subparagrafen zullen de specifieke gevolgen van cloud computing op de mate van assurance in het kader van jaarrekeningcontroles worden bekeken voor de belangrijkste IT-aspecten, te weten:

  • toegangsbeheer en autorisaties;
  • wijzigingsbeheer; en
  • backup & recovery.

Toegangsbeheer en autorisaties

Ten aanzien van toegangsbeheer en autorisaties is de afnemer enerzijds afhankelijk van het niveau van technische inrichting en processen van de leverancier en anderzijds kunnen interne maatregelen van de afnemer in de regel niet worden geïntegreerd met die van de leverancier.

Clouddiensten hebben hun eigen inrichting voor toegangsbeheer en autorisaties die niet per definitie aansluiten met de eisen en wensen van de afnemer. Bovendien zijn standaarden voor autorisaties op computersystemen nog lang niet uitgekristalliseerd en bieden protocollen zoals SAML 2.0 voldoende ruimte voor uiteenlopende interpretaties, hetgeen integratie tussen verschillende oplossingen niet bevordert.

In de praktijk lopen afnemers tegen drie issues aan:

  1. afwijkende authenticatiesterktes en -vormen;
  2. complexiteit van integratie van beheerprocessen; en
  3. complexiteit van technische integratie van autorisatiemechanismen.

Vrijwel alle clouddiensten bieden hun eigen vormen van authenticatie aan. Dit kan variëren van een combinatie van account plus wachtwoord (2-factor) tot sterkere vormen zoals een combinatie van account plus wachtwoord aangevuld met een token (3-factor). De sterkte van authenticatie ligt veelal vast en mogelijkheden tot aanvullende authenticaties zoals specifieke tokens en/of authenticatie op basis van biometrische kenmerken zijn beperkt, met name voor publieke clouddiensten. Er zijn specifieke oplossingen beschikbaar, ook als clouddiensten, die het interne authenticatiemechanisme (meestal de Active Directory) verbinden met het externe authenticatiemechanisme van de leverancier. Dit vergt uiteraard extra investeringen en beheerlasten.

Afwijkende authenticatiesterkte, zeker als deze zwakker is dan de eis van de afnemer, kan leiden tot zwakke plekken in het IT-landschap met als gevolg dat de integriteit en vertrouwelijkheid van data worden geschaad.

Wanneer de geëiste/gewenste authenticatievorm, zoals een account op basis van een bepaalde conventie in combinatie met een wachtwoord, niet wordt toegepast voor clouddiensten, is het risico op additionele kosten en beheerlasten groot. Immers, er moeten twee of meer authentiecatievormen worden ingekocht en beheerd. Hierbij mag de gebruiker niet uit het oog worden verloren. Zij moeten zich nu met extra en mogelijk met andere authentiecatiemiddelen aanmelden om toegang te krijgen tot de IT-diensten. Meerdere keren inloggen met meerdere tokens en/of smartcards kan als zeer hinderlijk worden ervaren, nog los van de beheerlasten voor de organisatie.

Single-Sign-On technologie kan in enkele gevallen worden toegepast om een consistente authenticatiesterkte en -vorm te realiseren, maar doorgaans is zij lastig te implementeren, zelden voor alle IT-resources bruikbaar en vaak, zeker voor clouddiensten, eenvoudig te omzeilen.

De processen voor gebruikersbeheer (aanmaken, wijzigen en afvoeren van accounts) en autorisaties (wie en/of welke rol heeft welke premissies tot welke data) is bij de meeste grote (> 5.000 computergebruikers) afnemende organisaties complex en voor verbetering vatbaar. Niet zelden kent dit proces zwakke plekken zoals verouderde, maar nog steeds geactiveerde accounts, die het beveiligingsniveau aantasten. Dikwijls worden autorisaties bij functiewijzigingen vermeerderd met nieuwe permissies terwijl de oude permissies niet verdwijnen. Deze complexiteit wordt vergroot bij clouddiensten die afwijkende procedures hanteren en/of andere technologieën gebruiken die deze processen faciliteren. Onvoldoende geïntegreerde processen kunnen leiden tot nog meer zwakke plekken met negatieve gevolgen voor de mate van assurance.

Autorisatiemechanismen bij afnemende organisaties zijn voor ruim negentig procent gebaseerd op de Security Groups en Group Policy Objects in Active Directory, al dan niet aangevuld met een RBAC-tool. Zowel Active Directory als de RBAC-tools zijn ontworpen voor een on-premise IT-omgeving. Integratie tussen verschillende IT-omgevingen is derhalve ingewikkeld en nog volop in ontwikkeling. Zo levert Microsoft Active Directory Federation Services om verschillende Active Directories te kunnen integreren over meerdere organisaties. Maar ook deze technologie is relatief nieuw en nog nauwelijks toegepast in de markt.

In de praktijk betekent dit dat autorisatiemechanismen van clouddiensten losstaan van die van de interne IT-omgeving. Dit vergroot dan ook het risico op extra beheerlasten, inconsistente processen en hogere complexiteit.

Integratie met bestaande, interne IT-diensten evenals tussen verschillende leveranciers van cloud computing kan grote integratieproblemen met zich meebrengen en de complexiteit vergroten.

Deze complexiteit geldt ook voor de overige beveiligingsmechanismen. Niet alleen zal er sprake zijn van meerdere oplossingen waarvoor geldt dat de keten net zo sterk is als de zwakste schakel, de integratie van beveiliging leidt vaak tot compatibiliteitsissues en onduidelijke verantwoordelijkheden.

Gezien de in ontwikkeling zijnde technologie liggen de mitigaties voor de genoemde risico’s met name op het terrein van procesintegratie. Hierbij wordt gestreefd naar een maximale harmonisatie van processen inzake toegangsbeheer en autorisaties tussen de afnemer en de leverancier. Voor private clouddiensten kan dit dan ook een uitkomst zijn. In geval van publieke clouddiensten zal de afnemer zich moeten schikken naar de processen van de leverancier. In ieder geval dient dit aspect meegenomen te worden in de businesscase.

Het is dan ook aan te bevelen om de volgende stappen te nemen alvorens er wordt besloten over te gaan naar de cloud:

  • Breng de huidige processen voor toegangsbeheer en autorisaties in kaart.
  • Definieer heldere requirements ten aanzien van beheerprocessen.
  • Definieer heldere technische requirements, met name op het gebied van (open) standaarden.
  • Werk voorafgaand aan de keuze een toekomstige integratie architectuurtechnisch uit.
  • Voer technische pilots uit voorafgaand aan de keuze.
  • Zorg voor een exit/migratie-strategie.

Wijzigingsbeheer

IT-resources bij de leverancier betekent in de eerste plaats dat de controle op wijzigingen anders dan op de data niet meer plaatsvindt door de afnemer, maar door de leverancier. Anders dan bij on-premise IT is wijzigingsbeheer niet meer de verantwoordelijkheid van de afnemer, maar van de cloud computing-leverancier.

In de tweede plaats betekent dit ook dat de afnemer slechts beperkte invloed heeft op de wijzigingen op de clouddiensten die hij afneemt. In principe is het de leverancier die voor de patches en nieuwe versies zorgt en de IT-omgeving beschikbaar houdt.

Dit brengt het grote voordeel met zich mee dat wijzigingsbeheer ten aanzien van het deel dat in de cloud zit is uitbesteed aan een gespecialiseerde partij. Het nadeel is evenwel dat de afnemer afhankelijk is van de bereidwilligheid en capaciteit van de leverancier om de geëiste/gewenste wijzigingen door te voeren. Bovendien kunnen voor een enkele afnemer ongewenste wijzigingen in de regel niet teruggedraaid worden. Dit is met name het geval bij publieke clouddiensten, maar ook de meeste private clouds zijn in hoge mate gestandaardiseerd.

In de praktijk blijkt dat niet zozeer de geringe controle en grip op wijzigingen invloed heeft op de mate van assurance, maar de vraag in hoeverre de cloud computing-leverancier inzage geeft in zijn wijzigingsbeheer. Slechts weinig leveranciers geven openheid betreffende hun wijzigingsbeheer anders dan op het niveau van toekomstige releases. Doorgaans blijft onduidelijk hoe de wijzigingen worden geïnitieerd op welke gronden, hoe de impactanalyse verloopt, hoe er wordt getest en hoe er wordt geaccordeerd.

Goede SAS70-rapporten lijken een uitkomst te bieden, maar slechts een minderheid van de leveranciers laat op regelmatige basis een audit uitvoeren door een onafhankelijke partij. Bovendien zijn de gekozen IT-controls gebaseerd op single-tenant structuur en niet de multi-tenancy die kenmerkend is voor publieke clouddiensten. Veel controls die noodzakelijk zijn om de scheiding van data en gebruik van resources tussen verschillende afnemers te waarborgen, worden niet gekozen en dientengevolge niet geaudit. Hierbij loopt de auditor tegen het probleem aan dat de huidige raamwerken zoals ISO27001/2 nauwelijks handvatten bieden voor multi-tenant omgevingen. Nieuwe raamwerken met nieuwe IT-controls worden op dit moment opgesteld, maar het aantal initiatieven is groot terwijl geen van de raamwerken nochtans breed is geaccepteerd in de markt.

Een right-to-audit is in deze gevallen aan te bevelen, maar dit is weggelegd voor de meest kapitaalkrachtige en/of invloedrijke afnemers. Slechts weinig aanvragen voor audits worden gehonoreerd en veel auditors ontberen de architectuurtechnische kennis en ervaring om clouddiensten op hun merites te beoordelen.

Onvoldoende assurance van de leverancier kan daarom reden zijn om (voorlopig) af te zien van clouddiensten.

Het is dan ook aan te bevelen om de volgende stappen te nemen alvorens er wordt besloten over te gaan naar de cloud:

  • Eis inzage in het wijzigingsbeheer van de leverancier, bij voorkeur beoordeeld door een onafhankelijke derde partij met kennis van cloud computing.
  • Zorg voor goede SLA’s en OLA’s voor met name communicatie en acceptatie van wijzigingen.
  • Verzoek indien mogelijk om een right-to-audit op wijzigingsbeheer en laat de audit uitvoeren door auditors met kennis van cloud computing.

Backup & recovery

Backup & recovery is in de cloud eveneens afhankelijk van de getroffen maatregelen bij de leverancier. Afgezien van de rapportages over de gebackupte data moet de afnemer vertrouwen op de leverancier dat zijn data daadwerkelijk zijn gebackupt en op een veilige plek onder goede omstandigheden worden bewaard. Daarnaast moet de afnemer erop vertrouwen dat de gebackupte data bij calamiteiten ook tijdig kunnen worden teruggezet en beschikbaar gesteld.

Enkele grote incidenten hebben evenwel aangetoond dat lang niet alle data in de cloud worden gebackupt. Duizenden klanten verloren hun data in de cloud door de beruchte ‘Sidekick Disaster’ van Microsoft en T-Mobile in 2009. Tegen de afspraken in bleken Microsoft en T-Mobile de data van hun klanten niet volledig te hebben gebackupt. Bovendien kwam het deel dat wél was veiliggesteld pas na enkele dagen beschikbaar.

Naast het probleem van falende of ontbrekende backups doet zich in de cloud ook het probleem van onderaannemers voor. Vaak is een deel van de clouddiensten namelijk op zijn beurt door de leverancier uitbesteed aan andere cloud computing-leveranciers. Het is niet ongebruikelijk dat backups en archivering door andere (gespecialiseerde) leveranciers worden uitgevoerd.

Zo bleek een belangrijk deel van de data van een Amerikaans ziekenhuis dat een clouddienst van een Amerikaanse leverancier afnam, gearchiveerd te zijn in India. De betreffende Amerikaanse leverancier had namelijk haar archiveringsactiviteiten uitbesteed aan een Indiaase partij.

Urgent wordt de problematiek als de betreffende cloud computing-leverancier niet meer in staat is of niet meer wenst om de data van de afnemer te ontsluiten richting de afnemer. Escrowmogelijkheden bestaan, maar naast de technische implicaties zoals het op het juiste formaat en medium terugkrijgen van data, zijn de juridische implicaties nog verre van uitgewerkt binnen de markt.

Een right-to-audit is ook ten aanzien van backup & recovery aan te bevelen, maar ook geldt dat slechts weinig aanvragen voor audits zullen worden gehonoreerd. Het is daarom beter om voorafgaand aan de aankoop transparantie te eisen van de leverancier.

De volgende stappen dienen dan ook te worden genomen alvorens er wordt besloten over te gaan naar de cloud:

  • Zorg voor goede SLA’s en afspraken met duidelijke thresholds zoals recoverytijden.
  • Zorg voor een volledig overzicht van alle partijen in het ecosysteem van de cloud (welke partijen zijn erbij betrokken?).
  • Zorg voor een escrow.
  • Zorg voor een exit/migratie-strategie.
  • Zorg voor een risicoanalyse vooraf.

Conclusie

Cloud computing heeft als een verregaande vorm van uitbesteding grote impact op de belangrijkste aspecten in het kader van assurance. Niet alleen verschuiven de IT-resources en daarmee de controle van de afnemer naar de cloud computing-leverancier, de mate en de complexiteit van integratie kunnen aanzienlijke risico’s tot gevolg hebben.

Discrepanties tussen toegangsbeheervereisten en autorisaties tussen de afnemer en de leverancier van clouddiensten op technische en procesmatige gebieden kunnen de mate van assurance sterk beïnvloeden. Dat geldt evenzeer voor het wijzigingsbeheer dat vrijwel uit het zicht en buiten controle van de afnemer plaatsvindt. Ten aanzien van backup & recovery dient de afnemer zich er onder andere bewust van te zijn dat zijn data niet noodzakelijkerwijs alleen bij de primaire leverancier zijn opgeslagen en dat datarecovery onderhevig kan zijn aan verregaande technische en juridische complicaties.

Mitigatie van de beschreven risico’s door middel van een right-to-audit van de kant van de afnemer dan wel het bieden van voldoende mate van zekerheid van de kant van de leverancier, zal in veel gevallen onhaalbaar dan wel ontoereikend zijn. Bovendien zijn goede IT-controls voor clouddiensten nauwelijks beschikbaar en nog lang niet uitgekristalliseerd. In ieder geval dient de afnemer een exit/migratie-strategie paraat te hebben om op elk gewenst ogenblik over te kunnen schakelen op alternatieven. Uiteraard dient de afnemer voorafgaand aan de adoptie van cloud computing een gedegen risicoanalyse uit te voeren als onderdeel van de businesscase.

De opmars van cloud computing lijkt onstuitbaar, ook voor het domein van financiële bedrijfsprocessen. Steeds meer organisaties zullen in de komende jaren overstappen van hun aloude on-premise IT naar oplossingen in de cloud. Adequate risicobeheersing is hierbij een kritieke succesfactor.

Literatuur

[Chun09] Mike Chung, Cloud computing als panacee, KPMG, 2009.

[Chun10] Mike Chung, Audit in the Cloud, KPMG, 2010.

[Dube07] Abhijit Dubey & Dilip Wagle, Delivering Software as a Service, McKinsey Quarterly, mei 2007.

[Isac09] Cloud Computing: Business Benefits With Security, Governance and Assurance Perspective, ISACA, 2009.

[KPMG10] From Hype to Future, KPMG’s 2010 Cloud Computing Survey, KPMG, 2010.

[Schn09] Bruce Schneier, Schneier on Security, 2008.

[Shaz10] Shay Uzery & Joep Ruiter, Privacywetgeving belemmert cloud computing, Automatisering Gids, maart 2010.

In control? Walk Along!

Het implementeren van nieuwe of gewijzigde bedrijfsprocessen, eventueel ondersteund door een nieuw (ERP-) pakket, vraagt veel inzet van een organisatie. De investering in dergelijke projecten is vaak groot. In de businesscase wordt deze investering vaak onderbouwd met bepaalde baten voor ogen, zoals bijvoorbeeld het realiseren van efficiency door standaardisatie van processen, het realiseren van ‘operational excellence’, het verbeteren van de service aan klanten, het verbeteren van de (management) informatie door het integreren van verschillende processen en applicaties, etc. De lat ligt vaak heel hoog voor dergelijke trajecten, aangezien een forse investering uiteindelijk ook kan leiden tot een aanzienlijke kostenpost/verlies, mocht het traject om wat voor reden dan ook niet slagen. In dit artikel wordt de ‘Walk Along’-aanpak behandeld, die auditor, adviseur en klant een waardevol instrument in handen geeft om tijdig te voldoen aan de eisen voor een betrouwbare informatievoorziening en financiële verslaglegging tijdens en na de implementatie van nieuwe door ICT ondersteunde processen.

Inleiding

Na implementatie wordt het succes van een project afgemeten aan het feit of de doelstellingen wel of niet (gedeeltelijk) zijn gehaald. Het succes wordt gedeeld met alle betrokkenen en ook de accountant wordt ingelicht over het succes van het project. Deze zal tijdens de interimactiviteiten of gedurende de jaareindecontrole diverse vragen gaan stellen omtrent de maatregelen die zijn geïmplementeerd om de betrouwbaarheid van de informatievoorziening, en met name de betrouwbaarheid van de financiële verslaglegging, te waarborgen.

Ervaring leert dat het antwoord op deze vraag vaak wordt afgedaan met de opmerking dat het projectteam daar ongetwijfeld aandacht voor heeft gehad. Totdat blijkt dat de aandacht voor het ontwerp en de implementatie van controlemaatregelen niet heel hoog op de projectagenda heeft gestaan en management onvoldoende inzicht heeft in de (financiële) prestaties van de nieuw geïmplementeerde processen. Vervolgens dient de organisatie extra kosten te maken om de noodzakelijke reparatiewerkzaamheden te verrichten om de betrouwbaarheid van de (financiële) verslaglegging te waarborgen.

Met de ingebruikname van het nieuwe pakket en de hiermee gepaard gaande toenemende afhankelijkheid worden ook steeds hogere eisen gesteld aan de betrouwbaarheid van de informatievoorziening. Niet alleen om adequaat invulling te kunnen geven aan de interne beheersing, maar ook om aantoonbaar te kunnen voldoen aan (toenemende) wet- en regelgeving.

In de visie van KPMG kan de betrouwbaarheid van informatie ook vlak na implementatie worden gewaarborgd indien een geïntegreerd controleraamwerk wordt ontwikkeld gedurende de implementatie. In dit raamwerk komen geïdentificeerde risico’s en mitigerende maatregelen tot uitdrukking. En wel door gebruik te maken van een ‘Walk Along’-aanpak, waarbij IT-auditors als onafhankelijke partij reviews uitvoeren op de geïdentificeerde, geïmplementeerde en geteste controlemaatregelen, zodat proactief kan worden gestuurd op het realiseren van een systeem dat een betrouwbare financiële verslaglegging op efficiënte en maximale wijze ondersteunt.

Nieuwe processen, nieuwe controlemaatregelen

De implementatie van een ERP-pakket leidt veelal tot het herontwerpen van bestaande processen. Waar processen veranderen zullen bestaande controlemaatregelen in oude processen moeten worden aangepast. Daarnaast dient de controlefilosofie te worden geëvalueerd en zo nodig herzien. Beide elementen kunnen direct bijdragen aan het realiseren van de veelal met het ERP-systeem beoogde efficiencyvoordelen.

Aanpassing controleraamwerk

De implementatie van een nieuw (ERP-) pakket kent over het algemeen verschillende uitgangssituaties. Indien het te implementeren pakket meerdere pakketten gaat vervangen en diverse processen gaat integreren of centraliseren, dan zal de implementatie tevens leiden tot het herontwerpen van processen. Ook spelen de mogelijkheden en onmogelijkheden van het geselecteerde pakket mee bij het ontwerpen van de nieuwe processen en de wijze waarop activiteiten worden ingericht. Denk bijvoorbeeld aan het centraliseren van het beheer van stamgegevens. In een situatie waarbij een bestaand pakket wordt vervangen, zal de nadruk vooral komen te liggen op het aansluiten van de bestaande processen bij de mogelijkheden en beperkingen die het nieuwe ERP-pakket heeft (de gap-fit-analyse).

Herinrichting van processen en activiteiten betekent dan ook dat bestaande controlemaatregelen niet meer in lijn liggen met de herontworpen processen. Herontwerp van controlemaatregelen is noodzakelijk! Het is mogelijk dat de organisatie voor de implementatie beschikte over een gedocumenteerd controleraamwerk waarin alle relevante controlemaatregelen zijn uitgewerkt. Dit bestaande controleraamwerk zal tijdens de implementatie tegen het licht gehouden dienen te worden om te bepalen of en zo ja, in hoeverre de bestaande controlemaatregelen aangepast moeten worden. Indien de organisatie niet beschikte over een gedocumenteerd controleraamwerk dienen de relevante controlemaatregelen tijdig geïdentificeerd, ontworpen en geïmplementeerd te worden. Er kan meer gebruikgemaakt worden van de geprogrammeerde controles uit het ERP-systeem. Dit levert een reductie op van kostbare handmatige controles.

Aanpassing controlefilosofie

Het ontwerp en de implementatie van controlemaatregelen moeten door de organisatie niet direct gezien worden als een verplicht nummer. Het ontwerpen en implementeren van een controleraamwerk gedurende het implementatieproject biedt de mogelijkheid om de tot op heden gehanteerde controlefilosofie kritisch tegen het licht te houden. Veel organisaties hebben de afgelopen jaren als gevolg van toenemende wet- en regelgeving controlemaatregelen ingericht. Dit kan geleid hebben tot het inrichten van handmatige en/of correctieve controles (achteraf) omdat de gebruikte applicaties beperkingen kennen in het implementeren van application controls.

Moderne pakketten beschikken vaak over een uitgebreid scala aan mogelijkheden voor het inrichten van applicatieve controlemaatregelen. Het implementatieproject biedt de organisatie een uitgelezen mogelijkheid om haar controlefilosofie te wijzigen en een meer preventief karakter te geven door gebruik te maken van de mogelijkheden van het nieuwe pakket door middel van applicatiecontroles zoals:

  • controletechnische functiescheiding in de applicatie;
  • fiattering met behulp van de applicatie op basis van three way match;
  • geprogrammeerde controles in de applicatie zoals:
    • formaatcontroles (datum, elfproef op bankrekeningnummers),
    • verbandscontroles (evenwicht in journaalpost, three way match controle),
    • verplichte velden,
    • limietcontroles op aantallen en bedragen,
    • automatische nummering;
  • het inrichten van signaleringslijsten, verwerkingslijsten en rapportages;
  • logging op relevante beheer- en/of gebruikersactiviteiten.

Uitgangspunt bij het ontwerpen van een (vernieuwd) controleraamwerk dient te zijn dat zoveel mogelijk controlemaatregelen in de applicatie worden ondergebracht. Figuur 1 laat zien dat het implementeren van controlemaatregelen in de applicatie kan leiden tot een meer preventieve controlefilosofie, waarbij komt dat het implementeren van applicatiecontroles ook leidt tot een efficiënter controleraamwerk: minder handmatige controles versus applicatiecontroles.

C-2010-3-Bijl-01

Figuur 1. Van handmatige controles naar geautomatiseerde controles.

Bij het uitwerken van de controlemaatregelen dient duidelijk onderscheid te worden gemaakt tussen de applicatieve maatregelen en de aanvullende organisatorische maatregelen, zodat het geheel aan maatregelen, het controleraamwerk, duidelijk inzichtelijk maakt in hoeverre de geïdentificeerde risico’s worden gemitigeerd.

De praktijk laat zien dat in implementatieprojecten beperkt aandacht wordt besteed aan tijdige identificatie en implementatie van applicatieve controlemaatregelen. Projecten worden uitgevoerd door processpecialisten, technisch specialisten en applicatiespecialisten; het ontwerpen en implementeren van controlemaatregelen is niet een dermate sexy onderwerp dat projectleden zich geroepen voelen het ontwerpen van controlemaatregelen gelijk mee te nemen in het maken van de proces- en applicatieontwerpen.

De relatie met de jaarrekening

Voor het vaststellen van de getrouwheid van de jaarrekening dient de accountant te steunen op de door de organisatie geïmplementeerde controlemaatregelen. De accountant zal na de implementatie van de nieuwe applicatie moeten inventariseren welke applicatieve controles en welke gebruikerscontroles na implementatie zijn geëffectueerd om zich zodoende een beeld te vormen van de mate waarin voor de jaarrekening kan worden gesteund op de geïmplementeerde controlemaatregelen. Naast de controlemaatregelen in de processen zal de accountant voor de jaarrekening eveneens dienen vast te stellen in hoeverre de juistheid en de volledigheid van de conversie aantoonbaar zijn gewaarborgd.

Zoals al eerder aangegeven is de praktijk dat het ontwerp en de implementatie van controlemaatregelen niet door de projectorganisatie worden opgepakt. De prioriteiten liggen vaak meer op de functionaliteit en minder op de controlemaatregelen in en rondom de processen.

Op het moment dat de accountant zijn werkzaamheden in het kader van de jaarrekening na de implementatie start, wordt de IT-auditor ingeschakeld om zich een beeld te vormen van de mate waarin kan worden gesteund op de geïmplementeerde controlemaatregelen in en om de applicatie. Vaak wordt dan in overleg met de klant een post implementation audit uitgevoerd om te bepalen in hoeverre toereikende controlemaatregelen daadwerkelijk zijn geïmplementeerd. De uitkomsten laten zien dat niet in alle gevallen toereikende maatregelen zijn geïmplementeerd, hetgeen leidt tot reparatie achteraf (extra inspanning voor configuratie van toereikende applicatiecontroles) en dus extra kosten met zich meebrengt. Behalve extra inrichtingskosten dient de accountant extra inspanningen te verrichten om zich een beeld te kunnen vormen over de getrouwheid van de jaarrekening. Extra werk is vaak noodzakelijk om te komen tot een goedkeurende verklaring bij de jaarrekening. Behalve de accountant dient een organisatie ook aan andere toezichthoudende instanties aan te kunnen tonen dat zij ‘in control’ is over haar processen.

Om op een efficiënte wijze zorg te dragen voor een betrouwbaar proces en systeem, is het noodzakelijk om het ontwerp en de implementatie van controlemaatregelen vroegtijdig te onderkennen en onderdeel te maken van de projectactiviteiten. Hiermee kan dan ook voldaan worden aan de eisen vanuit de accountant en de wet- en regelgeving.

Maar passen het ontwerp en de implementatie van controlemaatregelen in een vaak al overvolle projectplanning?

‘Walk Along’-aanpak

De ‘Walk Along’-aanpak geeft op effectieve wijze invulling aan de noodzaak reeds tijdens het project aandacht te besteden aan interne beheersing. Kern van een succesvolle aanpak is het hebben van een methode welke de mogelijkheid biedt om op efficiënte wijze in te haken op de projectplanning. KPMG heeft een methode ontwikkeld om tijdens de uitvoering van het project in haar rol als onafhankelijk IT-auditor reviews uit te voeren om te komen tot verbetervoorstellen ten aanzien van de door de klant geïdentificeerde risico’s en het ontwerp en de implementatie van de bijbehorende controlemaatregelen. De methode is erop gericht alle relevante onderwerpen waarvoor controlemaatregelen ontworpen en geïmplementeerd moeten worden, te onderkennen en geeft concrete handvatten om gedurende het project te borgen dat alle relevante aspecten van controlemaatregelen voor de interne beheersing worden afgedekt, ontworpen, geconfigureerd, getest en geïmplementeerd gedurende de cyclus van een implementatietraject.

Daarbij wordt niet alleen aandacht geschonken aan de controlemaatregelen in de (nieuw te implementeren) bedrijfsprocessen, maar ook aan de maatregelen die getroffen kunnen worden om juistheid, volledigheid en tijdigheid van de overdracht van gegevens via interfaces te borgen. Tevens schenkt de methode expliciet aandacht aan het onderwerp dataconversie. In de praktijk blijkt vaak dat één van de factoren die bijdraagt aan een succesvolle implementatie van een ERP-systeem, het tijdig inrichten is van de noodzakelijke maatregelen om juistheid en volledigheid van te converteren gegevens te borgen. De methode ondersteunt in dit proces en kent een aantal aandachtsgebieden.

C-2010-3-Bijl-02

Figuur 2. KPMG’s Business Integrated Controls-aanpak.

De methode maakt onderscheid tussen vier typen internecontrolemaatregelen, die ieder voor zich aandacht vereisen bij de implementatie van een nieuw ERP-systeem (zie figuur 2).

Businessprocessen

Daarbij gaat het om de controlemaatregelen die zijn ingericht als integraal onderdeel van de businessprocessen. Op deze wijze wordt de kwaliteit van de informatievoorziening geborgd, waarbij het gaat om aspecten als vertrouwelijkheid, integriteit, beschikbaarheid en efficiëntie. Zoals eerder aangegeven, worden dergelijke maatregelen vaak achteraf (tegen extra inspanning) ingebouwd. De methodiek biedt handvatten om vanuit de rol als onafhankelijk auditor aanbevelingen te doen zodat deze maatregelen gedurende het project als integraal onderdeel van het ERP-systeem door het projectteam zelf kunnen worden geïmplementeerd.

De eerste stap betreft het identificeren van de risico’s en de bijbehorende controlemaatregelen. Het is van groot belang om samen met de accountant de belangrijkste risico’s per proces te identificeren in het kader van de jaarrekeningcontrole. Op basis van deze risico’s dient gesproken te worden over de controlemaatregelen die de gesignaleerde risico’s mitigeren. Ook gedurende het project dient de accountant betrokken te blijven bij de identificatie en implementatie van controlemaatregelen zodat de controleaanpak kan worden aangepast op basis van de door de organisatie geïmplementeerde controlemaatregelen.

Data-integriteit

Onder data-integriteit worden zowel de interfaces met andere systemen als de conversie van gegevens naar het nieuw in te richten ERP-systeem verstaan. Veelal worden vanuit en naar een ERP-systeem diverse interfaces ingericht. Denk bijvoorbeeld aan interfaces met andere systemen, systemen van leveranciers, etc. De methode biedt concrete handvatten om reeds tijdens de inrichting en het testen van de interfaces zeker te stellen dat maatregelen worden genomen welke een juiste, volledige en tijdige overdracht van de gegevens borgen.

Dataconversie en -schoning is het tweede aspect dat in de methode onder data-integriteit wordt gevat. Vastgesteld dient te worden welke maatregelen door de organisatie zijn getroffen om de volledigheid en juistheid van de te converteren gegevens te waarborgen. Van belang, ook in het kader van de jaarrekening, is dat de organisatie achteraf kan aantonen dat conversie juist en volledig is verlopen en dat inzichtelijk is welke acties zijn ondernomen om eventuele uitval te corrigeren.

Veelvoorkomende issues hierbij zijn dat gegevens uit meerdere systemen samengebracht moeten worden in één nieuw ERP-systeem, dat de kwaliteit van deze gegevens niet overeenkomstig de eisen van het nieuwe systeem is en dat in de oude systemen nog processen lopen (bijvoorbeeld bestellingen die nog niet zijn afgerond). Dergelijke issues vragen een gedegen strategie en aanpak waarin zowel de controlemaatregelen als de procesaspecten gecombineerd worden. In de praktijk wordt schoning en conversie van stamgegevens (bijvoorbeeld klanten, leveranciers, materiaallijsten) overigens vaak als een eenmalige activiteit gezien. Het is zaak juist in deze fase ook aandacht te besteden aan het inrichten van een proces om deze stamgegevens ook na de conversie ‘schoon’ te houden, aangezien deze gegevens de basis vormen voor betrouwbare managementinformatie.

IT Security

Onder IT Security worden de controlemaatregelen gericht op beveiliging van de ERP-oplossing gevat. Daarbij gaat het ten eerste om de beveiliging van de applicatie zelf. Het verwerken van de vereiste controletechnische functiescheiding in de applicatie vormt daarbij een belangrijk onderdeel van de werkzaamheden. Eisen ten aanzien van functiescheiding moeten worden vertaald in profielen en rollen die vervolgens aan de verschillende gebruikers kunnen worden toegekend. De methode ondersteunt bij het tijdig en op effectieve wijze inrichten van beheersingsmaatregelen, waarmee de in de praktijk veelvoorkomende situatie dat autorisaties achteraf nog moeten worden ingericht, voorkomen kan worden. Naast de implementatie van functiescheiding komen ook de beveiligingsconcepten van de applicatie zelf aan bod. Daarbij kan worden gedacht aan maatregelen zoals het instellen van single sign-on, het vaststellen van de wachtwoordlengte en -complexiteit, etc. Ten tweede gaat het om het nemen van maatregelen ten aanzien van de beveiliging van de technische infrastructuur (netwerkinfrastructuur, het databasemanagementsysteem en het operatingsysteem). Een belangrijk aandachtspunt hierbij is de situatie waarbij het (technisch) beheer van de servers is uitbesteed. Zijn bijvoorbeeld de beoogde maatregelen niet alleen geïmplementeerd bij de organisatie zelf, maar heeft ook de externe partij rekening gehouden met de specifieke eisen die vanuit de business worden gesteld aan beschikbaarheid, vertrouwelijkheid en integriteit.

IT Operational

Een laatste aspect dat aandacht verdient bij de implementatie van een ERP-systeem is de aanpassing van algemene ICT-beheerprocessen (wijzigingsbeheer, autorisatiebeheer, continuïteit en beschikbaarheid). De methodologie ondersteunt hierin door een aantal concrete handreikingen te doen waarmee rekening moet worden gehouden bij het implementeren van een nieuw ERP-pakket. Te denken valt aan de situatie waarbij het ERP-pakket meerdere landen ondersteunt, terwijl in het verleden een aanpak werd gehanteerd waarbij een systeem per land werd onderhouden. In een dergelijke situatie dient de organisatie zorg te dragen voor het inrichten van nieuwe ICT-beheerprocessen die aansluiten bij de complexiteit van de nieuwe ERP-applicatie. Het aansluiten van de beheerprocessen op de complexiteit van het systeem draagt op deze wijze bij aan een betrouwbaar systeem waar de organisatie en haar accountant op kunnen steunen.

Integratie van de methode in het project

De hiervoor beschreven methode biedt het gereedschap om de organisatie reeds tijdens de uitvoering van het project concrete aanbevelingen te geven opdat de benodigde maatregelen kunnen worden genomen gericht op het borgen van een betrouwbare informatievoorziening. Door de werkzaamheden als integraal onderdeel op te nemen in de projectplanning, kan door de klant proactief worden gewerkt aan het ontwerpen, inbouwen en testen van die controlemaatregelen die van belang zijn om de betrouwbaarheid van de financiële informatievoorziening te borgen. Tegelijkertijd worden deze controlemaatregelen, omdat ze als integraal onderdeel van het project worden ingericht, tegen de laagst mogelijke kosten gerealiseerd.

De ‘Walk Along’-aanpak dient te worden afgestemd op de fasering die wordt gehanteerd door de projectorganisatie. Op basis van de projectplanning, de door de projectorganisatie gehanteerde fasering en de mijlpalen dienen de activiteiten voor ontwerp en inrichting van controlemaatregelen zodanig ingepland te worden, dat tijdig rapportages naar aanleiding van de reviews aan de stuurgroep/projectgroep opgeleverd worden. Figuur 3 laat zien op welke wijze de activiteiten samenhangen met de projectactiviteiten.

C-2010-3-Bijl-03

Figuur 3. Aanpak en fasering werkzaamheden in een ‘Walk Along’-project. [Klik hier voor grotere afbeelding]

De oplevering van deze rapportages zorgt ervoor dat tijdig kan worden bijgestuurd indien blijkt dat relevante controlemaatregelen binnen de processen en/of de conversie ontbreken of niet toereikend zijn.

Zoals eerder aangegeven, betekent het implementeren van nieuwe bedrijfsprocessen ondersteund door een ERP-systeem vaak een flinke investering, die bij mislukking kan leiden tot grote afschrijvingen. Door de ‘Walk Along’-aanpak op internecontrolemaatregelen te combineren met periodieke reviews kan de stuurgroep van een project tijdig actie nemen naar aanleiding van eventuele issues die tijdens de implementatie naar voren komen.

Risicoanalyse als uitgangspunt

Bij het ontwerpen en implementeren van controlemaatregelen staat de vraag centraal welke controlemaatregelen van belang zijn voor een betrouwbare informatievoorziening. Tegelijkertijd is het van belang ervoor te zorgen dat een ‘Walk Along’-aanpak waarde blijft toevoegen aan het project en dat niet onnodig wordt geïnvesteerd in controlemaatregelen die niet in verhouding staan tot de aan processen verbonden risico’s. Het vinden van een optimale mix tussen de wijze waarop controlemaatregelen worden ingericht (geautomatiseerd, handmatig of een combinatie van beide) en de zwaarte van de in te richten controlemaatregelen is dus van belang.

Door bij aanvang van een ‘Walk Along’-traject een risicoanalyse uit te voeren op de processen die het project gaat implementeren, kan de juiste balans worden bepaald. Idealiter wordt deze risicoanalyse in een workshop vormgegeven. Daarbij dienen zowel projectleden als vertegenwoordigers van de business samen de risico’s per proces(stap) vast te stellen. Op deze wijze wordt de betrokkenheid van de medewerkers bij het inrichten van controlemaatregelen vergroot, terwijl tegelijkertijd die risico’s worden onderkend die voor de business en de financiële verslaglegging van belang zijn. Tevens dienen in overleg met de controlerend accountant de belangrijkste risico’s vanuit de jaarrekening te worden vastgesteld zodat deze risico’s gedurende werkzaamheden eveneens worden afgedekt. Met deze risicoanalyse als uitgangspunt is de basis gelegd voor de ‘Walk Along’-activiteiten.

Toegevoegde waarde ‘Walk Along’-aanpak

De implementatie van een ERP-project vraagt een flinke investering en brengt tegelijkertijd een aantal, voor veel organisaties niet alledaagse, risico’s met zich mee. In een dergelijke situatie levert een investering in een ‘Walk Along’-aanpak concrete voordelen. Benadrukt moet worden dat de ‘Walk Along’-aanpak zich kenmerkt doordat gebruik wordt gemaakt van de kracht van interactie tussen adviseur, accountant en de organisatie. Hierdoor kan op zeer efficiënte wijze gewerkt worden aan de implementatie van die controls die van belang zijn voor de financiële verslaglegging, beheersing van bedrijfsprocessen, etc. Het primaire doel van een investering in een ‘Walk Along’-aanpak is dan ook dat de organisatie na implementatie van het ERP-pakket greep houdt op de (financiële) processen. Tegelijkertijd kunnen ongewenste ‘verrassingen’ die tijdens de jaarrekeningcontrole mogelijk kunnen leiden tot een niet positief oordeel van de accountant, tijdig worden gesignaleerd. Hierdoor wordt de stuurgroep van het ERP-project in staat gesteld direct in te grijpen en bij te sturen waar nodig.

De toegevoegde waarde voor de organisatie ligt dus op het vlak van interne beheersing van de organisatie en op de mogelijkheden die ERP-systemen hiervoor bieden. De belangrijkste voordelen die hieruit voortvloeien zijn in het kort:

  • Het management (en het audit committee) en het projectteam verkrijgen, naast de reguliere projectvoortgangsrapportages, onafhankelijke feedback op hun activiteiten om een controleraamwerk op te zetten en te implementeren.
  • Door vroegtijdige identificatie van (financiële) risico’s is het mogelijk tijdig bij te sturen waar het gaat om het implementeren van controlemaatregelen in en rondom de applicatie. Tegelijkertijd wordt bijgedragen aan het vergroten van het bewustzijn bij betrokkenen dat controlemaatregelen essentieel zijn om processen te beheersen.
  • De betrokkenheid van de accountant draagt ertoe bij dat hij/zij gedurende het implementatietraject kennis verkrijgt over de impact van de geïmplementeerde controlemaatregelen in relatie tot de risico’s voor de financiële verslaglegging. De kans op ‘verrassingen’, voor zowel de klant als de accountant, wordt hiermee verkleind. Tevens kan de controleaanpak voor de jaarrekening efficiënt worden afgestemd op de nieuw ingerichte processen en systemen.
  • Juist in situaties waarin naar een nieuw systeem wordt overgestapt, is het risico op problemen met de integriteit van financiële gegevens groot. Dit vormt veelal een specifiek aandachtspunt tijdens de jaarrekeningcontrole. In veel gevallen blijken aanvullende controles van de accountant noodzakelijk om inzicht te krijgen in de kwaliteit van de gegevens in het nieuwe systeem. Investeren in een ‘Walk Along’-aanpak draagt bij aan een vergroot inzicht in de integriteit van de financiële gegevens. Tegelijkertijd kunnen maatregelen (conversiedossier) worden genomen die ertoe bijdragen dat het benodigde inzicht voor de jaarrekeningcontrole als vanzelf wordt opgebouwd. Hierdoor kan de accountant het niveau van meer diepgaande testwerkzaamheden in het systeem beperken.
  • Kritische reviews tijdens een ‘Walk Along’-aanpak dragen ertoe bij dat efficiëntere methoden van interne beheersing kunnen worden geïdentificeerd en geïmplementeerd. Tijdrovende handmatige controles kunnen worden vervangen door geautomatiseerde controles. Hierdoor ontstaat ruimte voor de medewerkers van de financiële administratie om de aandacht van de vaak vele tijdrovende controles te verleggen naar het uitvoeren van financiële analyses en procesverbetering, terwijl het niveau van interne beheersing gelijk blijft of zelfs verbeterd wordt.

De ‘Walk Along’-aanpak in de praktijk

Het ontwerpen en implementeren van controlemaatregelen gedurende de uitvoering van het project staat soms op gespannen voet met het implementeren van de nieuwe applicatie. Projectmedewerkers hebben primair de doelstelling om het pakket zodanig te configureren dat het systeem de gebruikers optimaal ondersteunt. In de praktijk blijkt dat de projectplanning over het algemeen weinig ruimte laat om diezelfde projectmedewerkers ook nog te belasten met het ontwerp en de implementatie van controlemaatregelen.

Zo blijkt bij een handelsbedrijf dat zijn processen optimaliseerde door onder andere een nieuw ERP-pakket te implementeren, dat het projectteam is samengesteld uit medewerkers die een uitstekende kennis hebben van de wijze waarop de nieuwe bedrijfsprocessen moeten worden geconfigureerd in het systeem. Kerngebruikers die vanuit de business het systeem moeten accepteren, hebben een sterk procesinhoudelijke inbreng veelal vanuit hun eigen expertise. Tegelijkertijd is het zien van de samenhang tussen processen van belang. Betrokkenen die verantwoordelijk worden gesteld voor het ontwerpen en implementeren van beheermaatregelen dienen eveneens over deze capaciteiten te beschikken. Oftewel: er wordt (vaak) een beroep gedaan op een beperkt aantal personen binnen het project. Gegeven de opleverdatum, de beperkte ruimte in de planning voor uitloop en de beperkte beschikbaarheid van de juiste kennis en personen hebben ‘Walk Along’-opdrachten de ultieme uitdaging in zich om alle werkzaamheden binnen de tijdlijnen zoals vastgesteld door het project, uitgevoerd te krijgen. Uit praktijkervaring bij dit handelsbedrijf en ook bij andere bedrijven blijkt dat het van groot belang is om nauw contact te onderhouden met de projectleiding die goed zicht heeft op de projectplanning, en om regelmatig de inzet en benodigde capaciteit van de klant met het project te bespreken. Bij het handelsbedrijf bijvoorbeeld leek het project uit te gaan lopen. Vanuit het project werd vervolgens getracht ruimte in de planning te creëren door het implementeren en testen van de controls een lagere prioriteit toe te kennen. De rol van de onafhankelijke externe reviewer is dan in gesprekken met de klant ook het belang van het tijdig implementeren en testen van de controlemaatregelen te benadrukken. Juist door continue communicatie met de projectgroep over de betrokkenheid van de IT-auditor en de aandacht voor de controlemaatregelen kon het handelsbedrijf op tijd bijsturen, zodat het bedrijf vanaf dag één dat het met het nieuwe bedrijfsproces ‘live’ ging, een betrouwbaar systeem had.

Een factor die bij het handelsbedrijf belangrijk was voor het succes van de uitvoering van de ‘Walk Along’-opdracht, is het hebben van een sponsor op directieniveau. Implementatie van controlemaatregelen staat niet altijd hoog op de projectagenda. Door regelmatige verslaglegging van het KPMG-projectteam aan de stuurgroep die het belang van controlemaatregelen onderkende, stond het onderwerp interne beheersing ook echt op de agenda bij het handelsbedrijf. Specifiek van belang was dat het onderwerp bij dit bedrijf niet als een onderwerp van de auditor, maar als bedrijfsbelang werd gezien. Doordat het bedrijf nut en noodzaak onderkende, konden de beoogde voordelen die in de businesscase voor het project stonden ook echt gehaald worden en was het niet noodzakelijk om alsnog allerlei handmatige controles of crash-acties uit te voeren om bijvoorbeeld klantvragen te beantwoorden als gevolg van slechte datakwaliteit. Het is dan ook essentieel om de klant te wijzen op de voordelen voor zijn organisatie indien gesproken wordt over een ‘Walk Along’-opdracht.

Conclusie

In dit artikel is de aanpak geschetst op basis waarvan een organisatie ondersteund kan worden bij het tijdig ontwikkelen en implementeren van relevante controlemaatregelen om een betrouwbare informatievoorziening te waarborgen.

De aanpak dient aan te sluiten op de projectplanning en heeft inbreng nodig van projectleden met (overstijgende) proceskennis. De IT-auditor en het projectteam hebben niet hetzelfde belang. Het projectteam zal zo spoedig mogelijk de implementatie af willen ronden; de IT-auditor bewaakt de tijdige implementatie van controlemaatregelen door de (project)organisatie. Het onderwerp controlemaatregelen wordt door het projectteam ervaren als ‘oponthoud’. Veel en open communicatie met de projectplanning is derhalve essentieel.

Indien succesvol, dan beschikt de organisatie na de implementatie over een geschikt controleraamwerk om vanaf dag één na implementatie een betrouwbare informatievoorziening te waarborgen. Achteraf zijn geen omvangrijke werkzaamheden meer noodzakelijk om alsnog toereikende controlemaatregelen te implementeren en de controlerend accountant kan vanaf dag één steunen op toereikende controlemaatregelen.

Risico’s in het betaalproces en betaalpakketten

Dit artikel is deels gebaseerd op het referaat van Lodewijk Benjaminse dat hij onlangs in het kader van de opleiding EMITA aan de Universiteit van Amsterdam heeft geschreven. Het referaat is gebaseerd op een onderzoek naar het betaalproces en de betaalpakketten van de banken die daarbij worden ingezet. De inrichting van het betaalproces wordt behandeld aan de hand van een korte procesanalyse en een beschrijving van de zeer beperkte wet- en regelgeving op het gebied van het betaalproces. Data-analyse kan een bijdrage leveren aan het inzichtelijk maken van het betaalproces inclusief de momenten in dat proces waarop uitval en/of handmatig ingrijpen in het proces heeft plaatsgevonden.

Inleiding

Het betaalproces kent diverse risico’s waarvan velen zich te weinig bewust zijn. Mede daardoor zijn situaties bekend waarin men onvoldoende preventieve beheersingsmaatregelen treft. In gesprekken met medewerkers van organisaties en ook wel van auditors hoort men reacties als ‘het zal zo’n vaart niet lopen’, ‘we controleren om het betaalpakket heen’ of ‘de crediteur belt vanzelf wel een keer’.

In dit artikel beschrijven wij de inzet van betaalpakketten van banken, zowel de versie waarbij gebruik wordt gemaakt van de onlinefunctionaliteit op de website van de bank als de versie waarbij een betaalpakket lokaal bij de organisatie (niet de bank) is geïnstalleerd. Aan de hand van de belangrijkste verschillen in de functionaliteiten van betaalpakketten lichten wij de risico’s toe. Met een voorbeeld gaan we in op de mogelijkheden om op eenvoudige wijze een CLIEOP03-bestand te bewerken.

In het kader van de jaarrekeningcontrole bespreken we wet- en regelgeving, richtlijnen en raamwerken die impact hebben op de AO/IC, algemene IT-beheersingsmaatregelen, het betaalpakket en het betaalproces. Als onderdeel daarvan lichten we de ‘bucketapproach’ toe, waarmee door middel van data-analyse inzicht wordt verkregen in de betaalstromen en de omvang en aard van eventuele uitval in het betaalproces.

Hieronder staat het artikel ‘Het banksaldo aangevuld'[Het artikel is iets aangepast. Enkele begrippen zoals ‘electronic banking’, ‘betalingssysteem’, ‘electronic bankingsysteem’, ‘betalingsvoorstellijst’ en ‘betalingsproces’ zijn aangepast aan de terminologie zoals die elders in dit artikel wordt gehanteerd. Deze begrippen zijn vervangen door ‘betaalpakket’, ‘betaalvoorstellijst’ c.q. ‘betaalproces’.] uit Accountant ([Groo08]) dat illustreert hoe (relatief) eenvoudig het in de praktijk is om fraude te plegen bij uitgaande betalingen. In dit voorbeeld wordt aangegeven hoe door het muteren van bankrekeningnummers in betaalvoorstellijsten en het bijwerken van tussenrekeningen werd gefraudeerd.

Een onderneming maakt bij het verrichten van betalingen gebruik van een betaalpakket. Het betaalproces is als volgt ingericht. Een medewerker van de administratie stelt vanuit de crediteurenadministratie een zogenaamde betaalvoorstellijst op. De medewerker geeft dit overzicht aan de directeur, inclusief de onderliggende facturen. De directeur controleert het overzicht met de onderliggende bescheiden en keurt de betalingen in het betaalpakket goed. Hierna vindt (geautomatiseerd) de betaling plaats.

Recentelijk is de onderneming gestuit op een aantal vreemde betalingen. Nader onderzoek heeft uitgewezen dat de medewerker verantwoordelijk voor het opstellen van de betaalvoorstellijst voor ruim één miljoen euro heeft gefraudeerd. Hoe? De medewerker wijzigde na aanmaak van de betaalvoorstellijst in het betaalpakket de naam en het bankrekeningnummer van de crediteur in zijn eigen naam en bankrekeningnummer. De directeur kreeg echter het oude ongewijzigde bestand, stelde vast dat het overzicht aansloot met de facturen en keurde de betaling goed. Hij was zich er niet van bewust dat de gegevens in het betaalpakket waren gewijzigd en dat in werkelijkheid de bedragen werden overgemaakt aan de fraudeur. Nadat de betaling was verricht werd het betaaloverzicht door de fraudeur op zodanige wijze gemanipuleerd dat het weer de juiste crediteurengegevens bevatte. Hierna werd de crediteurenadministratie bijgewerkt.

Als facturen niet worden betaald, gaan na verloop van tijd natuurlijk de crediteuren klagen. Dit werd door de fraudeur op eenvoudige wijze voorkomen. De fraudeur liet de facturen nogmaals betalen, maar nu op het juiste bankrekeningnummer. De directeur had dit toch niet door. Er werden dagelijks zoveel betalingen verricht dat hij een dubbele betaling niet op zou merken. Daar de crediteur al was afgeboekt, werden de betalingen op een tussenrekening geboekt. Nu zou je natuurlijk verwachten dat de accountant dit bij zijn controle wel zou ontdekken. Een tussenrekening met een hoog saldo valt natuurlijk op. Maar ook dit was snel opgelost. Op het moment dat de accountant zijn controle aankondigde, schoonde de fraudeur de tussenrekeningen en boekte de bedragen over naar diverse kostenrekeningen. Hij gebruikte hiervoor kostenrekeningen waarvan de realisatie ruim onder het budget en de realisatie van vorig jaar lag, zodat een en ander bij een cijferbeoordeling door de accountant niet op zou vallen. De medewerker kon op deze wijze jarenlang zijn banksaldo aanvullen, zonder dat hij tegen de lamp liep.

Fraude in het betaalproces komt in de praktijk zeer veel voor. Dit is ook logisch, aangezien hier het geld de onderneming verlaat. Toch blijkt de accountant deze vorm van fraude in de praktijk maar zelden te ontdekken, terwijl het in veel gevallen om omvangrijke (materiële) bedragen gaat. Uit oogpunt van fraude is het betaalproces dan ook een proces dat de nodige aandacht van de accountant verdient.

Omschrijving van het betaalproces en betaalpakketten

Hoog inherent risico

Op diverse momenten in het betaalproces worden bestanden gebruikt: als overdrachtsmedium tussen de financiële administratie dat opdrachten genereert en het betaalpakket, bij het versturen van de betaalopdrachten, maar ook afschriften en verwerkingsinformatie zijn veelal in bestanden opgeslagen. Hierin ligt een inherent hoog risico op bewuste manipulatie of onbewuste fouten. Bewuste manipulatie is voor de hand liggend aangezien via het betaalproces het meest direct geld aan de organisatie kan worden onttrokken. Ook het maken van onbewuste fouten is niet onwaarschijnlijk als er in het betaalproces veel momenten zijn dat bestanden worden overgedragen en regelmatig (handmatige) correcties plaatsvinden.

Als compensatie zou daarom een goed stelsel van beheersingsmaatregelen essentieel zijn. Echter, beheersingsmaatregelen rondom deze bestanden zijn dat niet altijd. Veelal wordt slechts gesteund op de controle van het totale bedrag in het betaalbestand en wordt de juistheid van individuele betaalopdrachten niet altijd vastgesteld.

Betaalproces en betaalpakket

Het betaalproces kent op hoofdlijnen de volgende stappen:

Subproces aanmaken (in financiële administratie):

  1. betaalvoorstellijst aanmaken
  2. betaalbestand aanmaken
  3. betaalbestand exporteren

Subproces betalen (in betaalpakket):

  1. betaalbestand importeren
  2. betaalopdracht handmatig invoeren
  3. betaalopdrachten versturen

Subproces bankverwerking (in centrale administratie van de bank):

  1. betaalopdrachten uitvoeren

Subproces verwerkingsinformatie (in betaalpakket):

  1. afschriften en verwerkingsinformatie downloaden

Subproces boeken van betaling (in financiële administratie):

  1. afletteren betalingen

De letters a tot en met i zijn ook opgenomen in de figuren 1 en 2. In deze twee figuren zijn in het kort de stappen weergegeven die worden doorlopen bij versturen van betaalopdrachten via een betaalpakket.

Betaalpakketten

In figuur 1 is het proces weergegeven dat ondersteund wordt door een onlinebetaalpakket en in figuur 2 betreft het een lokaal geïnstalleerd betaalpakket. In beide figuren is links door middel van de stippellijnen de organisatie weergegeven die de betaalopdrachten verstuurt. De bank zelf is in beide figuren eveneens door middel van stippellijnen aan de rechterkant weergegeven. Communicatie tussen beide partijen vindt veelal via internet plaats.

Figuur 1 geeft de situatie weer waarbij het onlinebetaalpakket via een website van de bank (rechts) wordt benaderd. De betaalopdrachten worden vanuit de financiële administratie gegenereerd en geïmporteerd in het onlinebetaalpakket of direct handmatig in het betaalpakket ingevoerd. In de figuur is duidelijk zichtbaar dat het betaalpakket zich op een webserver binnen de infrastructuur van de bank bevindt. Vanaf de webserver wordt met de centrale administratie van de bankrekeningen (transacties en saldi) gecommuniceerd. Het onlinebetaalpakket wordt door middel van een browser via internet benaderd voor zowel het invoeren van betaalopdrachten als het downloaden van de afschriften en de verwerkingsinformatie.

C-2010-3-Benjaminse-01

Figuur 1. Onlinebetaalpakket op website van bank.

In figuur 2 wordt een betaalpakket gebruikt dat lokaal bij de opdrachtgever is geïnstalleerd. Het lokaal geïnstalleerde betaalpakket ontvangt betaalopdrachten uit de financiële administratie of deze worden rechtstreeks ingevoerd. Daarvandaan worden betaalopdrachten (veelal op een later moment) naar de bank verstuurd. Deze zal de betaalopdrachten in haar centrale administratie van bankrekeningen verwerken. De verwerkingsinformatie wordt vervolgens door de bank beschikbaar gesteld in het lokaal geïnstalleerde betaalpakket.

C-2010-3-Benjaminse-02

Figuur 2. Betaalpakket lokaal geïnstalleerd bij de opdrachtgever.

Risico’s

Het is niet de doelstelling van dit artikel alle risico’s hier uitputtend te behandelen. Belangrijk verschil tussen beide hiervoor beschreven varianten is dat bestanden met betaal- en/of verantwoordingsinformatie gedurende enige tijd of bij de bank of bij de organisatie zelf staan. In het laatste geval is het risico op manipulatie (bewust) of bijvoorbeeld overschrijving (onbewust) aanmerkelijk groter.

Enkele andere voorbeelden van risico’s in het proces van uitgaande betalingen en inkomende verwerkingsinformatie zijn:

  • Betaalopdrachten worden ten onrechte gemuteerd.
  • Betaalopdrachten worden niet gefiatteerd.
  • Functiescheiding in het betaalproces ontbreekt.
  • Afschriften en verwerkinginformatie van de bank worden gemuteerd.
  • Door middel van slepen wordt geld aan de organisatie onttrokken.
  • Details van betaalopdrachten zijn achteraf niet meer te herleiden (audit trail).

Er heerst vaak een groot vertrouwen in collega’s: passen worden bij de pincodes bewaard en pincodes worden gedeeld met collega’s.

De bestanden waarin de betaalopdrachten (CLIEOP03) en afschriften of verwerkingsinformatie (MT940) zijn opgeslagen, zijn relatief eenvoudig in een simpele tekstverwerker aan te passen. Doordat veelal ten onrechte wordt gesteund op de controle van het totale bedrag, worden mutaties in het bestand lang niet altijd ontdekt aangezien het mogelijk is het bestand aan te passen, zoals in het voorbeeld dat in de inleiding wordt aangehaald. Er worden minimale controles op de juistheid van de betaalopdrachten uitgevoerd en vastlegging van deze controles vindt nauwelijks plaats. In sommige gevallen worden slechts de bedragen van een paar facturen gecontroleerd of wordt alleen het controletotaal beoordeeld.

Hieronder is ter illustratie een voorbeeld opgenomen om aan te tonen dat deze controles onvoldoende zijn. In figuur 3 is een deel van een CLIEOP03-bestand weergegeven. In blauw is het bedrag in centen weergegeven. Rood en groen geven de bankrekeningnummers weer van respectievelijk de opdrachtgever en de ontvanger. Het betreft een declaratie van 209,75 euro voor De Vries naar bankrekeningnummer 248592831 en de betaling van het salaris van Boer à 3.533,93 euro naar bankrekeningnummer 938492837.

C-2010-3-Benjaminse-03

Figuur 3. Deel van originele CLIEOP03-bestand.

Het is relatief eenvoudig dit CLIEOP03-bestand te bewerken zonder dat dit wordt ontdekt wanneer het bestand alleen aan de hand van het totaalbedrag wordt gecontroleerd. De bedragen kunnen immers binnen het bestand worden verplaatst omdat dit opgeteld nog altijd hetzelfde totaalbedrag oplevert.

In figuur 4 is te zien dat een deel van het bedrag van de declaratie bij de betaling van het salaris is opgeteld. Dit heeft geen invloed op het totaalbedrag omdat de 200 euro die bij de betaling van het salaris is opgeteld, van de betaling van de declaratie is afgetrokken.

C-2010-3-Benjaminse-04

Figuur 4. Deel van bewerkte CLIEOP03-bestand.

Verschillen in functionaliteiten van betaalpakketten

Wij treffen de volgende belangrijkste verschillen aan in de functionaliteiten bij betaalpakketten:

Autorisatie

De mate waarin gedetailleerd autorisaties kunnen worden ingericht, verschilt sterk tussen de pakketten. Dit varieert van betaalpakketten waarin alle gebruikers dezelfde rechten hebben tot betaalpakketten waarin autorisaties minutieus kunnen worden toegekend door middel van profielen. Om risico’s te beperken is het aan te bevelen een betaalpakket te gebruiken waarin de rechten per gebruiker gedetailleerd kunnen worden toegekend door middel van profielen.

Authenticatie

Voor veel activiteiten in de betaalpakketten geldt dat authenticatie en autorisatie van de gebruiker moeten plaatsvinden. Dit kan op de volgende manieren geschieden:

  • door middel van iets wat men weet: bijvoorbeeld een gebruikersnaam, het wachtwoord of een pincode;
  • met iets wat men heeft: bijvoorbeeld een token, een bankpas of een digitaal certificaat;
  • met behulp van iets wat men is: bijvoorbeeld een vingerafdruk, stemherkenning, iriscopie of gezichtsherkenning.

De huidige mechanismen om betaalopdrachten te fiatteren maken geen gebruik van de volledige inhoud van alle betaalopdrachten. Het enige wat door de huidige authenticatiemiddelen wordt bevestigd, is wie men beweert te zijn. Dit zegt dus niets over de feitelijke inhoud van de te fiatteren betaalopdrachten, die kan ondertussen zijn gemuteerd zonder dat de gebruiker dit bemerkt. Helaas zien we nog erg weinig beweging richting het gebruik van authenticatiemiddelen die gebruikmaken van iets wat men ‘is’. Ten slotte komen de meeste fraudes nog voort uit misbruik van zwakke authenticatiemiddelen (zoals het bekend worden van wachtwoorden en pincodes).

Per bank verschilt het sterk hoe gebruikers aan het betaalpakket worden toegevoegd. Het kan zijn dat organisaties geheel zelfstandig gebruikers, authenticatiemiddelen en autorisaties kunnen wijzigen in het betaalpakket of dat dit via de bank dient te verlopen. Dit is van belang voor het triggeren van wijzigingen in bevoegdheden van functionarissen alsmede het periodiek wijzigen van wachtwoorden, etc.

Hashtotalen

Voor gebruikers zijn niet altijd evenveel controlemogelijkheden beschikbaar in de vorm van controletotalen en hashtotalen. Hoe meer mogelijkheden bij het inrichten van controletotalen en hashtotalen de gebruiker tot zijn beschikking heeft, des te beter hij controles kan uitvoeren op de juistheid en volledigheid van het betaalbestand. Hashtotalen zijn een goede aanvulling op controletotalen. Controletotalen zoals die in een CLIEOP03-bestand worden toegepast houden geen rekening met de positie van het bedrag, zoals in figuur 3 is getoond. Het is daarom verstandig ook gebruik te maken van hashtotalen waarbij in de berekeningen wel rekening wordt gehouden met de positie. Hoewel het in theorie mogelijk is een betaalbestand te manipuleren en toch het hashtotaal ongewijzigd te houden, is dat in de praktijk aanzienlijk moeilijker en tijdrovender dan het manipuleren van een betaalbestand dat is voorzien van alleen een totaalbedrag als controletotaal.

Verantwoordingsinformatie

Het verdient de voorkeur om de individuele betaalopdrachten uit een betaalbestand in de verwerkingsinformatie te laten terugkomen, in plaats van alleen het totaalbedrag of de terugmelding dat de betaalopdrachten zijn verwerkt. Niet alle banken bieden een betaalpakket met die mogelijkheid. Eventuele aanpassingen van het oorspronkelijke betaalbestand worden dan niet eenvoudig opgemerkt.

Lokaal versus online

Betaalpakketten worden steeds vaker volgens de onlinevariant aangeboden. De bestanden met daarin de betaalopdrachten worden vanuit de financiële administratie gegenereerd en direct geïmporteerd in het onlinebetaalpakket. Het betaalpakket bevindt zich op een webserver die gekoppeld is met de infrastructuur van de bank. Het onlinebetaalpakket wordt door middel van een browser via internet benaderd voor zowel het invoeren van betaalopdrachten als het downloaden van de afschriften en de verwerkingsinformatie. Anderzijds worden betaalpakketten offline gebruikt waarbij het betaalpakket lokaal bij de opdrachtgever is geïnstalleerd. Het lokaal geïnstalleerde betaalpakket ontvangt betaalopdrachten uit de financiële administratie of deze worden rechtstreeks ingevoerd. Daarvandaan worden betaalopdrachten naar de bank verstuurd. De verwerkingsinformatie wordt vervolgens via diezelfde verbinding door de bank beschikbaar gesteld in het lokaal geïnstalleerde betaalpakket. Wij zien dat betaalpakketten door de banken steeds vaker online worden aangeboden. Het verschil tussen beide mogelijkheden heeft invloed op het risico tot ongewenste aanpassing van de betaalopdrachten. In het algemeen zal het inherente risico op wijziging van het betaalbestand groter zijn wanneer de betaalbestanden eerst intern worden opgeslagen. De eis van beveiliging van de IT bij banken (kans op reputatieschade bij de bank) is dermate hoog, dat verwacht mag worden dat de verwerking van de betaling bij de bank onder hoge beveiliging zal plaatsvinden. Overigens ontvangt de gebruiker van onlinebetaalpakketten geen zekerheid van de bank omtrent de kwaliteit van haar infrastructuur. Hier moeten de gebruikers vertrouwen hebben in de interne en externe toezichthouders.

Bovenstaande overwegingen zijn niet alleen van belang voor het beoordelen van de inrichting van het betaalpakket en de bijbehorende beheersingsmaatregelen, maar ook voor het selecteren van een nieuw te implementeren betaalpakket. Het is van belang om aan de hand van de functionele en technische eisen en wensen bovenstaande overwegingen in ogenschouw te nemen.

Regelgeving en richtlijnen

Zoals hierboven eerder is aangegeven, is de organisatie of de auditor zich soms onvoldoende bewust van de risico’s, treft men ‘bewust’ niet voldoende beheersingsmaatregelen of ziet men niet toe op de naleving ervan. Er is ook vrijwel geen wet- en regelgeving op dit punt. Wel zijn er diverse richtlijnen en raamwerken waarin aangegeven staat dat men beheersingsmaatregelen in de kritische processen en informatiesystemen, zoals betaalproces en het betaalpakket, moet aanbrengen.

Risk management principles for electronic banking

De Risk management principles for electronic banking ([Base03]) van het Basel committee on banking supervision van de Bank for international settlements (BIS) zijn opgesteld om banken adviezen (‘risk management principles’) mee te geven bij het inrichten van e-banking. Hoewel dit document is opgesteld vanuit het perspectief van de bank zelf, geeft het de gebruiker (als opdrachtgever) genoeg handvatten voor de inrichting van het betaalproces en het betaalpakket.

Hoewel deze veertien adviezen voor de banken zijn uitgegeven om de betrouwbaarheid en continuïteit voor e-banking te waarborgen, zijn ze natuurlijk voor iedereen die betrokken is in het betalingsverkeer van toepassing. De principles betreffen:

  1. Board and Management Oversight
    1. Effective management oversight of e-banking activities.
    2. Establishment of a comprehensive security control process.
    3. Comprehensive due diligence and management oversight process for outsourcing relationships and other third-party dependencies.
  2. Security Controls
    1. Authentication of e-banking customers.
    2. Non-repudiation and accountability for e-banking transactions.
    3. Appropriate measures to ensure segregation of duties.
    4. Proper authorisation controls within e-banking systems, databases and applications.
    5. Data integrity of e-banking transactions, records, and information.
    6. Establishment of clear audit trails for e-banking transactions.
    7. Confidentiality of key bank information.
  3. Legal and Reputational Risk Management
    1. Appropriate disclosures for e-banking services.
    2. Privacy of customer information.
    3. Capacity, business continuity and contingency planning to ensure availability of ebanking systems and services.
    4. Incident response planning.

Ieder principle wordt in het rapport verder uitgewerkt, waarbij er voor zes principles in een bijlage duidelijke richtlijnen worden geformuleerd:

  • security;
  • outsourcing;
  • authorisation;
  • audit trails;
  • privacy;
  • availability, business continuity en contingency planning.

Voorbeelden van dergelijke richtlijnen zijn:

  • ‘Banks should ensure that appropriate measures are in place to promote adequate segregation of duties within e-banking systems, databases and applications.’
  • ‘Specific authorisation and access privileges should be assigned to all individuals, agents or systems, which conduct e-banking activities.’
  • ‘E-Banking data and systems should be classified according to their sensitivity and importance and protected accordingly. Appropriate mechanisms, such as encryption, access control and data recovery plans should be used to protect all sensitive and high-risk e-banking systems, servers, databases and applications.’

Code voor Informatiebeveiliging

De Code voor Informatiebeveiliging is door de International Organization for Standardization en de International Electrotechnical Commission opgesteld en biedt een uitgebreide lijst aan beheersingsmaatregelen voor informatiebeveiliging. Informatiebeveiliging wordt daarin omschreven als de beveiliging van informatie tegen een breed scala van risico’s ([ISO05]).

Er wordt in de Code voor Informatiebeveiliging verwezen naar wet- en regelgeving op het gebied van de beveiliging van gegevens, privacy, intellectueel eigendom en de verwerking van gegevens:

  • De organisatie dient te allen tijde rekening te houden met de gevolgen voor de informatiebeveiliging door het versturen van gegevens via het internet. Betaalopdrachten worden via het internet naar de bank verstuurd. Bij gevolgen kan worden gedacht aan ongewenste mutaties (juistheid), publiekelijk bekend worden van de inhoud (vertrouwelijkheid) en de kans dat berichten niet of dubbel aankomen (volledigheid) c.q. het (achteraf) ontkennen dat berichten zijn verstuurd of klagen dat berichten wel zijn verstuurd maar niet zijn aangekomen (tijdigheid). Ook kan het voorkomen dat betaalopdrachten frauduleus door een andere afzender worden ingestuurd als ware het van de organisatie zelf (autorisatie).
  • Het overtreden van wet- en regelgeving dient te worden vermeden. Hier valt onder andere te denken aan wetgeving voor privacy, waarbij naast het bedrag ook andere persoonlijke gegevens in de beschrijving/toelichting of in de aard van de betaling zelf in het geding kunnen zijn.
  • Medewerkers moeten op de hoogte worden gesteld van hun verantwoordelijkheden ten aanzien van informatiebeveiliging en geheimhouding.

Enkele normen die in de Code voor Informatiebeveiliging worden genoemd zijn:

  • ‘Duties and areas of responsibility should be segregated to reduce opportunities for unauthorised or unintentional modification or misuse of the organisation’s assets.’
  • ‘Data protection and privacy should be ensured as required in relevant legislation, regulations and, if applicable, contractual clauses.’

COSO Enterprise Risk Management

Het COSO ERM-raamwerk is een raamwerk voor administratieve organisatie en interne beheersing. Eén van de doelstellingen van dit raamwerk is ‘safeguarding of resources’, ook wel bekend als ‘safeguarding of assets’. Er dienen volgens het COSO ERM-raamwerk dan ook beheersingsmaatregelen aanwezig te zijn die voorkomen dat bezittingen ten onrechte aan de organisatie worden onttrokken. Het proces van uitgaande betalingen is in het bijzonder een proces waar bezittingen (geld) de organisatie verlaten.

Wet bescherming persoonsgegevens

De Wet bescherming persoonsgegevens schrijft voor dat organisaties persoonsgegevens op een zorgvuldige wijze verwerken, verstrekken en verzamelen (artikel 6, 7 en 8). In deze wet staat onder andere dat persoonsgegevens niet verwerkt mogen worden ‘op een wijze die onverenigbaar is met de doeleinden waarvoor ze zijn verkregen’ (artikel 9). De verantwoordelijke organisatie dient ‘passende technische en organisatorische maatregelen’ te nemen om ‘persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking’. Deze maatregelen dienen ‘een passend beveiligingsniveau’ te garanderen ‘gelet op de risico’s die de verwerking en de aard van te beschermen gegevens met zich meebrengen’ (artikel 13).

Aansluitend is bepaald dat een bank voldoende waarborgen dient te bieden ten aanzien van ‘de technische en organisatorische beveiligingsmaatregelen met betrekking tot de te verrichten verwerkingen’ (artikel 14) ([Over09a]).

Binnen het betaalproces kunnen op diverse momenten en locaties persoonsgegevens worden opgeslagen en verstuurd. In het begin worden gegevens van medewerkers verzameld om bijvoorbeeld salarissen en declaraties te kunnen betalen. Deze gegevens in de betaalopdrachten bevatten de namen van de betreffende medewerkers, hun bankrekeningnummers, de bedragen (nettosalaris en declaraties) en een bijbehorende omschrijving. Maar ook gegevens over lidmaatschappen, donaties aan bijzondere doelen etc. die in de omschrijving van betalingen kunnen zijn vermeld, kunnen privacygevoelig zijn. Daarnaast dienen de gegevens tijdig weer te worden verwijderd. Het vrijstellingsbesluit ([Over01]) geeft bij een aantal processen, zoals bij crediteuren en leveranciers, concrete aanwijzingen van bewaartermijnen van dergelijke gegevens (waaronder die van betalingen).

Algemene voorwaarden

Organisaties dienen aan diverse voorwaarden van de bank te voldoen. Dit staat omschreven in de algemene voorwaarden voor (zakelijk) internetbankieren. Deze voorwaarden zijn van invloed op de wijze waarop de organisaties het betaalproces inrichten.

De algemene voorwaarden van deze banken hebben veel met elkaar gemeen. De organisatie dient zelf controles uit te voeren ten aanzien van de juistheid, volledigheid en tijdigheid van de verwerking van de betaalopdrachten. Verder eist de bank dat de organisatie over een beveiligde (internet)verbinding beschikt. Veelal hebben medewerkers van de organisatie persoonlijke authenticatiemiddelen waarvan men alle elementen geheim dient te houden en niet aan derden ter beschikking mag stellen.

Overige regelgeving

Bovenstaand zijn enkele richtlijnen weergegeven. Buiten de BIS-principles zijn de richtlijnen tamelijk generiek en ook van toepassing op andere processen met een hoog inherent risico of bewuste of onbewuste aanpassingen. Voor de accountantscontrole zijn natuurlijk ook de Nadere voorschriften controle- en overige standaarden (NV COS) en de general IT controls van belang.

Binnen NV COS van het NIVRA en het Besluit toezicht accountantsorganisaties wordt eveneens verwezen naar fraude. Fraude (van materieel belang) wordt in het Besluit toezicht accountantsorganisaties ([Over09b]) (artikel 36) gedefinieerd als ‘opzettelijk handelen […] om een wederrechtelijk voordeel te behalen en waarbij de aard of de omvang zodanig is dat beslissingen die in het maatschappelijk verkeer worden genomen op grond van de financiële verantwoording van de controlecliënt zouden kunnen worden beïnvloed door die misleiding’.

NV COS 240 ([NIVR09a]) schrijft voor dat de accountant verantwoordelijk is voor ‘het onderkennen van het risico van fraude in het kader van de controle van financiële overzichten’. Hierbij wordt voorgeschreven dat de accountant een ‘professioneel-kritische instelling’ moet aannemen en ‘afwijking van materieel belang als gevolg van fraude’ moet bespreken.

De accountant dient ‘het risico van een afwijking van materieel belang als gevolg van fraude’ in te schatten, zoals in NV COS 315 ([NIVR09b]) staat geschreven. Aansluitend daarop zal hij aanvullende controlewerkzaamheden moeten verrichten.

Analyse met behulp van datamining

Naast een goede inrichting met voldoende beheersingsmaatregelen in het proces kan met behulp van data-analyse een goed inzicht worden verkregen in de betaalstromen en de omvang en aard van eventuele uitval in het betaalproces. Bij uitval zal vrijwel altijd handmatige actie nodig zijn, die veelal fraudegevoeliger is en ook meer risico van het maken van onbewuste fouten oplevert.

Per processtap, zoals eerder beschreven, kan door diverse oorzaken uitval ontstaan. In figuur 5 is op basis van de zogenaamde ‘bucket-approach’ inzicht gegeven in de stappen uit het betaalproces (verticale kolommen) en buckets waar betaalgegevens per stap zijn opgenomen. De bucket voor de hoofdstroom aan de linkerkant zou idealiter gelijk zijn aan de bucket aan de rechterkant, want dan zijn er geen ongeregeldheden geweest.

C-2010-3-Benjaminse-05

Figuur 5. Voorbeeld van uitwerking bucket-approach voor betaalproces.

Zo kan bijvoorbeeld bij het importeren van het betaalbestand uitval ontstaan ten opzichte van de originele aangemaakte betaalvoorstellijst door gemuteerde betalingen in het betaalbestand. Dit is met stippellijnen weergegeven in figuur 5. De volgende vergelijking moet dan opgaan:

aantal geëxporteerde betalingen = aantal geïmporteerde betalingen + aantal gemuteerde betalingen

Per bucket is zo inzichtelijk te maken hoeveel van de oorspronkelijk te betalen crediteuren uiteindelijk juist en tijdig zijn betaald. Dit kan worden gedaan door per bucket door middel van data-analyse de bestanden/tabellen te analyseren en zo te bepalen hoeveel euro en/of betalingen het betreft. Zo wordt exact inzichtelijk hoeveel betalingen er uitvallen. Uitval heeft als nadeel dat de betreffende betalingen veelal handmatig moeten worden gecorrigeerd, met alle risico’s van dien.

Naast het feit dat de betreffende crediteuren niet juist en tijdig zijn betaald, levert dergelijke uitval uitzoekwerk op dat handmatig dient te worden verricht. Het is daarom van belang de omvang van deze uitval te beperken. Hierdoor is het betaalproces als geheel efficiënter te maken: minder handmatige acties.

Verbeteringen

Het betaalpakket brengt traditiegetrouw veel handmatige activiteiten met zich mee, wat tot onnodige risico’s leidt.

De combinatie van onversleutelde open bestandsformaten (bijvoorbeeld zoals CLIEOP03) en de tussenkomst van personen in het betaalproces is niet wenselijk. Dergelijke bestanden zijn zeer eenvoudig aan te passen zonder dat dit conflicten met de controletotalen oplevert.

Idealer zou een systeem zijn waarbij de tussenkomst van personen wordt beperkt en betaalbestanden vanuit de financiële administratie via het netwerk naar de bank worden verstuurd. Hierdoor neemt het risico af dat betaalbestanden worden gemuteerd. Banken bieden echter veelal geen mogelijkheid om een geautomatiseerde koppeling (door middel van bijvoorbeeld FTP of SQL) aan te gaan rechtstreeks vanuit de financiële administratie.

Hierbij is het tevens aan te raden een vorm van communicatie te hanteren waarbij de inhoud niet (voor personen) leesbaar is om zo de mogelijkheden om betaalopdrachten te kunnen muteren drastisch terug te dringen. Hiervoor moet de financiële administratie wel in staat zijn een dergelijk formaat of dergelijke versleuteling toe te passen. De bank zal dan als enige over de mogelijkheid moeten beschikken het versleutelde bestand te ontsleutelen. Dit is vergelijkbaar met encryptie waarbij een publieke sleutel en een geheime privésleutel worden gebruikt:

  • Voor de vertrouwelijkheid gebruikt de verzender de publieke sleutel van de ontvanger. De ontvanger kan het bericht dan lezen met zijn eigen privésleutel.
  • Als het om authenticiteit gaat, versleutelt de verzender het bericht met zijn eigen privésleutel. Zo kan iedereen aan de hand van zijn publieke sleutel controleren of de verzender is wie hij zegt dat hij is.

Conclusie

Elektronisch betalingsverkeer is al geruime tijd het normale medium voor het verrichten van betalingen van organisaties via de eigen bank. Er zijn diverse betaalpakketten die door banken worden aangeboden. Naar hun aard kent het betaalproces, waarbij geld de organisatie verlaat en schulden worden afgeboekt, een hoog inherent risico. Dat risico betreft natuurlijk enerzijds de gevolgen voor een organisatie indien betalingen onjuist worden gedaan, maar anderzijds ook een hoog frauderisico.

Inmiddels is het proces zo standaard geworden, dat de aandacht voor de risico’s lijkt te zijn weggeëbd. Toch komen er nog regelmatig fouten en fraudes voor, ook al halen alleen de meest bijzondere fraudes zoals met betaalautomaten de krant.

In het artikel is aangegeven dat de beschikbare regelgeving en richtlijnen voor de inrichting heel beperkt zijn en dat er veelal gesteund moet worden op de meer generieke richtlijnen voor informatiebeveiliging. In het referaat van Lodewijk Benjaminse is op basis van de richtlijnen en aanvullend concreet inzicht een uitgebreid normenstelsel voor de inrichting uitgewerkt.

Voor de beoordeling van de betaalstromen en inzicht in de stroom van betalingen (geautomatiseerd en/of handmatig) en de uitval is data-analyse met behulp van auditsoftware effectief gebleken. Daarbij kan de bucket-approach worden gehanteerd, waardoor in één oogopslag de stroom in aantallen betalingen of omvang van bedragen inzichtelijk wordt gemaakt. Aan de hand van dat overzicht kunnen eventuele bijzonderheden (zoals uitval) worden geanalyseerd.

Literatuur

[Base03] Basel committee on banking supervision, Risk management principles for electronic banking, juli 2003 (http://www.bis.org/publ/bcbs98.pdf).

[Boer96] J.C. Boer RE RA, ir. J.A.M. Donkers RE, drs. R.M. Renes en prof. dr. P. Wallage RA, Corporate Governance; de betekenis voor de ICT-Auditor, Compact 1996/5.

[Comm04] Committee of Sponsoring Organizations of the Treadway Commission, Enterprise Risk Management, Integrated Framework, september 2004.

[Groo08] R. de Groot, M. Grummel en B. Prins, Het banksaldo aangevuld, januari 2008 (http://www.accountant.nl/Accountant/Fraude+in+praktijk/Het+banksaldo+aangevuld).

[ISO05] ISO/IEC Standard, Information technology: Security techniques, code of practice for information security management, juni 2005.

[NIVR09a] NIVRA, Handleiding regelgeving accountancy: NV COS 240 (De verantwoordelijkheid van de accountant voor het onderkennen van het risico van fraude in het kader van de controle van financiële overzichten, oktober 2009 (http://www.nivra.nl/Sites/nivra_site/HRA/200903/html/38351.htm).

[NIVR09b] NIVRA, Handleiding regelgeving accountancy: NV COS 315 (Kennis van de entiteit en haar omgeving en het inschatten van het risico van een afwijking van materieel belang), oktober 2009 (http://www.nivra.nl/Sites/nivra_site/HRA/200903/html/38644.htm).

[Over01] Vrijstellingsbesluit, Staatsblad van het Koninkrijk der Nederlanden, 2001 250.

[Over09a] Overheid.nl, Wet bescherming persoonsgegevens, oktober 2009 (http://wetten.overheid.nl/BWBR0011468).

[Over09b] Overheid.nl, Besluit toezicht accountantsorganisaties, oktober 2009 (http://wetten.overheid.nl/BWBR0020184).

Continuous Monitoring for Solvency II

Inmiddels is bekend dat ook de verzekeringssector in toenemende mate te maken heeft met verdergaande regulering. Solvency II, IFRS, MCEV en eisen van DNB beogen meer transparantie en een betere balans tussen risico’s en winst maken. Het is uiteraard zaak om op een effectieve wijze compliant te worden met al die eisen. In dit artikel worden de knelpunten in de huidige situatie geanalyseerd en wordt de gewenste situatie op hoofdlijnen beschreven. Tot slot wordt een oplossingsrichting besproken waarbij IT en de IT-auditor een cruciale rol hebben. De kern van dit artikel ligt in het rapporteren van betrouwbare informatie in het vereiste tempo door gebruik te maken van cashflowvectoren.

Inleiding

Eén van de belangrijkste oorzaken van de huidige financiële crises is het beperkte inzicht van de markt in de wereldwijde balansrisico’s van financiële instellingen zoals banken, verzekeraars en pensioenfondsen. Hoewel de oorsprong van de huidige financiële crises bij de bancaire sector ligt werden al snel de effecten bij verzekeraars en pensioenfondsen merkbaar. In veel gevallen bleek het niet mogelijk om in het vereiste tempo betrouwbare informatie over de risico’s en over de financiële positie beschikbaar te krijgen.

Het gevolg is dat stakeholders waaronder toezichthouders eisen dat risk management wordt verbeterd, er meer transparantie komt en er gezocht wordt naar een betere balans tussen risico’s en winst maken. Een voorbeeld daarvan zijn de Solvency II-eisen zoals die voor verzekeraars vanaf eind oktober 2012 gaan gelden. Ook IFRS-regelgeving, Market Consistent Embedded Value (MCEV) en eisen van DNB wijzen allemaal in dezelfde richting: een verzekeraar moet continu inzicht hebben in de risico’s (continuous monitoring).

Het is uiteraard zaak om op een effectieve wijze compliant te worden aan al deze eisen. De echte uitdaging is om daarnaast kostenbesparingen en toegevoegde waarde voor de business te realiseren. De nieuwe eisen hebben uiteraard een groot effect op de strategie van verzekeraars en het hart van de processen, waaronder de noodzaak om modelmatig het risk based capital te berekenen en om stochastische modellen te hanteren voor het doorrekenen van economische scenario’s. Modellering wordt een integraal deel van het besluitvormingsproces van de verzekeraar, echter de huidige procesgang op gebied van actuariële reporting is niet meer in staat die ontwikkelingen bij te houden. Daarnaast is de integratie tussen Finance- en Risk-processen onvoldoende gerealiseerd en zijn actuariële reportingprocessen nog niet aangepast aan de nieuwe eisen waaronder Solvency II.

Leeswijzer

In de eerste paragraaf worden de ‘in control’-eisen vanuit Solvency II toegelicht. In de volgende paragraaf wordt het proces van actuariële rapportage beschreven zoals dat momenteel veelal is ingericht. In de paragraaf daarna wordt het principe van rapportage op basis van cashflow toegelicht. Vervolgens wordt aandacht besteed aan de IT-architectuur en de voordelen van het rapporteren op basis van cashflows. Daarna worden de rol van de EDP-auditor in de transitie, de mogelijke vervolgfasen en consequenties voor de organisatie beschreven.

‘In control’-eisen vanuit Solvency II

Het primaire doel van Solvency II is om de polishouder beter te beschermen tegen insolvabiliteit van de verzekeraars door eisen te stellen aan de omvang van het kapitaal dat de verzekeraar moet aanhouden. De omvang van het kapitaal is mede afhankelijk van de actuele financiële positie en de waardering van de belangrijkste risico’s van de verzekeraar. Voor Solvency II worden twee kernbegrippen gehanteerd voor de kapitaalvereisten: de Minimum Capital Requirement (MCR) en de Solvency Capital Requirement (SCR). De MCR staat voor de minimale kapitaalvereiste. De SCR levert de feitelijke kapitaalseis.

Voor Solvency II wordt hetzelfde conceptuele kader gehanteerd als eerder voor de Basel II-regelgeving (ter bescherming tegen insolvabiliteit van banken) is ontwikkeld. Het kader bestaat uit drie aspecten, ook wel pilaren genoemd (zie figuur 1). De eerste pilaar behandelt de wijze waarop risico’s in kaart worden gebracht en worden gekwantificeerd. Het interne risicomanagement en de controle door de toezichthouder zijn opgenomen in de tweede pilaar en de derde pilaar beschrijft de wijze waarop de verzekeraar moet rapporteren aan de toezichthouder en het publiek.

C-2010-3-Beek-01

Figuur 1. Solvency II-pilaren.

Solvency II dient eind oktober 2012 volledig geïmplementeerd te zijn. Veel verzekeraars zijn momenteel bezig met de voorbereiding hiervoor. Ook is CEIOPS, de Europese toezichthouder, actief om invulling te geven aan de diverse aspecten van de wetgeving (Directive) door middel van een stroom van Advices.

In artikel 41 van de directive wordt aangegeven dat verzekeraars een effectief systeem van governance dienen te hebben dat ten minste uit vier elementen bestaat: risk management, internal control, internal audit en uitbesteding. Daarnaast dienen verzekeraars te beschikken over een actuariële functie. Het risk-managementsysteem (artikel 44) bestaat uit het geheel van strategieën, processen en rapportages die nodig zijn om de risico’s van verzekeraars op een continue basis te monitoren, te beheersen en daarover te kunnen rapporteren.

De eisen vanuit Solvency II worden kernachtig samengevat in het artikel 45 ‘Own Risk and Solvency Assessment’ (ORSA), dat door het Europese Parlement wordt gezien als het hart van de regelgeving. Als wij dit vertalen naar de ‘in control’-eisen betekent dit eigenlijk dat informatie betrouwbaar en dagelijks beschikbaar moet zijn voor besluitvorming. In de praktijk zijn verzekeraars hier weken, zo niet maanden mee bezig. Ook vanuit het management is één van de belangrijkste zorgen rond de implementatie van de nieuwe eisen rond risk en capital management het verkrijgen van data en daarover op een snelle en controleerbare wijze rapporteren.

Informatietechnologie wordt niet veel genoemd in de Solvency II-regelgeving maar is wel één van de belangrijkste aspecten. Het verzamelen van gegevens vanuit de diverse organisatieonderdelen en het grote aantal legacy systemen bij verzekeraars brengt problemen met zich mee voor de datakwaliteit (integriteit en continuïteit van gegevens). In dit artikel zullen niet de formele eisen vanuit de directive ten aanzien van de IT worden behandeld, maar meer de gevolgen voor de IT en IT als middel om aan de eisen te kunnen voldoen.

Net als bij Basel II kan voor het berekenen van de kapitaalvereisten gebruik worden gemaakt van het standaardmodel, maar kunnen ook interne risicomodellen worden gehanteerd. Bij het gebruik van interne risicomodellen gelden dezelfde voorwaarden op gebied van modelvalidatie als voor Basel II, waarbij onder meer de internal-auditafdeling betrokken moet zijn. Met behulp van risicomodellen kunnen diverse scenario’s worden doorgerekend, risico’s van portefeuilles en producten worden bepaald en kan het benodigde kapitaalbeslag worden berekend om deze risico’s te absorberen. De gegevens zijn afkomstig uit zowel interne als externe bronnen. Verder dienen stresstests te worden uitgevoerd om inzicht te krijgen waar de grenzen van de risico’s liggen.

In dit artikel hebben we ervoor gekozen om verder niet in te gaan op de eisen rond het gebruiken van standaard- dan wel interne-risicomodellen. Deze problematiek krijgt in andere publicaties al de nodige aandacht. Wij gaan vooral in op een innovatief idee om de data beschikbaar te krijgen en de noodzakelijke verbeteringen in het proces van het rapporteren van risico’s te realiseren. Allereerst zullen we het huidige proces van actuariële rapportering verkennen en de wijzigingen die naar ons idee zouden moeten worden gerealiseerd om te kunnen voldoen aan het ‘in control’ zijn voor Solvency II. Daarna besteden we nog aandacht aan de secundaire, maar daarom niet minder belangrijke doelen, waaronder kostenbesparingen en toegevoegde waarde voor het management.

Het huidige proces van actuariële rapportages en het IT-landschap

Vanuit het gezichtspunt van de IT-auditor (maar ook van de andere stakeholders) valt veel aan het huidige proces van de totstandkoming van de actuariële rapportage op te merken. In hoofdlijn is er geen sprake van een transparant en controleerbaar proces (zie figuur 2).

C-2010-3-Beek-02

Figuur 2. Huidig proces van actuariële rapportages.

Vanuit de IT-architectuur is het belangrijkste probleem dat bij veel verzekeraars systemen en processen ingericht zijn op basis van individuele verzekeringsproducten. Vaak hebben systemen een lange historie waarbij heel veel data soms decennialang (vooral bij levensverzekeringen) worden vastgehouden. Veranderingen en conversies zijn bij een dergelijk IT-landschap moeilijk, complex en risicovol. Actuarissen onttrekken de data aan deze systemen maar vanwege de vele opgetreden veranderingen zijn de data vaak niet compleet, betrouwbaar en consistent als gevolg van onderling verschillende conventies. Dit heeft tot gevolg dat de data moeten worden geschoond en verrijkt voordat modelberekeningen überhaupt kunnen plaatsvinden.

Voor de berekening van de modellen en de scenario’s gebruiken actuarissen vaak standaard-projectiesystemen. Deze systemen zijn krachtig maar maken deels gebruik van verouderde IT-technologie en passen vaak moeilijk in het aanwezige IT-landschap qua standaarden en architectuur. De projectiesystemen werken op basis van een model van de werkelijke portefeuille, genereren vervolgens verwachte cashflows en komen dan pas aan de feitelijke projecties toe. Per saldo vindt dit in een IT-omgeving plaats waarbij de basis general IT controls niet zijn ingericht en ook applicatiecontroles ontbreken (zogenaamde ‘spreadsheet city’). Buiten de tooling is er sprake van een handmatig proces, zowel aan de input- als aan de outputkant, en opvallend is dat voor elke rapportage het proces van begin tot eind wordt doorlopen, zonder dat bijvoorbeeld de initiële cashflows worden opgeslagen voor hergebruik. Als gevolg van de vele handmatige bewerkingen kan de aansluiting met de financiële administratie en het resultaat naar bronnen alleen met veel moeite worden gemaakt.

Om minder afhankelijk te worden van spreadsheets zijn bij veel verzekeraars projecten gestart rond datawarehousing. Dit is een duidelijke stap vooruit maar in de praktijk bleek het vaak moeilijk om dit concept succesvol te implementeren. Doel was om dezelfde data als in de legacy systemen vast te houden (waardoor eigenlijk een herbouw plaatsvond van deze systemen met alle problematiek van dien), maar de interfacing met de primaire systemen bleek complex.

Buiten de IT-problemen is ook zichtbaar dat de huidige procesgang steeds meer onder druk komt in het licht van de nieuwe eisen. Het proces is zeer bewerkelijk en drukt een belangrijke tijdstempel op het rapportageproces. Hierdoor blijft er maar weinig tijd over voor de analyse- en de adviestaak van de actuariële afdeling. Het is duidelijk dat veel verzekeraars niet over het instrumentarium beschikken om de complexe standaard- en ad-hocrapportages binnen Solvency II – en de regelgeving die ongetwijfeld nog zal komen – in een transparant en controleerbaar proces te kunnen produceren.

Cashflow als basis van het rapportageproces

Hoe kan er nu wel een meer repeterend, transparant en controleerbaar rapportageproces worden gerealiseerd? Om tot een oplossing te komen van de geconstateerde problemen zijn experts op het gebied van actuariële problemen, risk management en IT gezamenlijk aan de slag gegaan.

Om een schaalbare en flexibele informatievoorzieningsfunctie in te richten dient deze in onze visie te zijn gebaseerd op de kleinste financiële bouwsteen van een verzekeringscontract. Deze bouwstenen, de feitelijk afzonderlijke verzekeringsdekkingen, kunnen worden weergegeven als cashflows (kasstromen) van zowel de creditzijde als de debetzijde van de balans. Er is een beperkt aantal variabelen (vectoren) benodigd om deze cashflows van een verzekeringscontract vast te stellen. Naast (de waarde van) de potentiële uitkering en de restantduur betreft dit de leeftijd en het geslacht van de verzekerde. Figuur 3 illustreert deze initiële cashflowvectoren.

C-2010-3-Beek-03

Figuur 3. Cashflowvectoren bestaande uit de potentiële uitkering, de kans en de contante waarde.

Het voordeel van het hanteren van de kleinste bouwstenen is de generieke toepassing voor allerhande rapportageprocessen. De definitie van een cashflow is universeel waardoor geen verschillen ontstaan tussen de datamodellen van de verschillende legacy systemen, wat de extractie en de bewerking van de data makkelijker maakt. Werken op basis van deze cashflows creëert dus direct harmonisatie. Bovendien wordt op prospectieve wijze de contractwaardering bepaald waardoor het beschikbaar hebben van historische contractgegevens tot een minimum wordt beperkt.

Over het algemeen wordt deze aanpak door actuarissen beaamd. Het idee om cashflows de basis te laten zijn van alle rapportageprocessen wordt echter nauwelijks toegepast. Met het op deze manier opzetten van rapportageprocessen ontstaat tevens een effectiviteit in het complianceproces en wordt voorkomen dat voor elke ontwikkeling weer een spreadsheetoplossing aan het bestaande landschap wordt toegevoegd. Door de actuele cashflows op een continue basis beschikbaar te maken wordt het fundament gelegd voor continuous monitoring. In de volgende paragraaf wordt aandacht besteed aan de hiervoor benodigde IT-architectuur.

Hoe ziet de IT-architectuur hiervan eruit?

De belangrijkste stap is om de cashflows op een efficiënte manier te verwerken en op te slaan in een IT-architectuur. Deze IT-architectuur bevat de volgende elementen:

  • datawarehouse;
  • extractie- en calculatietools;
  • actuariële analyse- en rapportagetools.

De totale IT-architectuur en stromen tussen de verschillende componenten zijn geïllustreerd in figuur 4.

C-2010-3-Beek-04

Figuur 4. IT-architectuur.

Datawarehouse

Voor de vastlegging van de cashflowvectoren dient een datawarehouse ‘nieuwe stijl’ te worden ingericht. Nieuw is de gedachte om deze cashflowberekeningen niet aan het eind van de periode te doen maar meteen bij de creatie van een nieuwe polis of bij wijziging ervan. Dat voorkomt een opeenstapeling van rekenexercities aan het eind van een rapportageperiode. De berekende cashflows worden opgeslagen in een datawarehouse. Op deze wijze ontstaat een ‘single source of truth’ en wordt het datawarehouse de basis van een betrouwbare en controleerbare informatievoorziening.

Merk op dat dit datawarehouse zich onderscheidt doordat slechts de cashflowvectoren per dekking worden vastgelegd en geen integrale vastlegging plaatsvindt van alle polisvariabelen inclusief de historische versies daarvan.

Het datawarehouse vormt de bron voor alle statutaire en managementinformatierapportages, waarbij de technologie en de datamodellering borg staan voor een continu inzicht in de risico’s en een schaalbare, flexibele oplossing naar de toekomst.

Extractie- en calculatietools

In de nieuwe opzet wordt voor de hele rapportageketen gebruikgemaakt van cashflows. Ideaal gesproken zouden de primaire systemen beschikken over functionaliteit om de cashflowvectoren te genereren. Dat is in de praktijk vaak niet het geval zodat we hier gebruik moeten maken van in de markt beschikbare tooling om de productdata uit de primaire systemen te vertalen naar cashflowvectoren (zogenaamde cashflow calculation engine).

Actuariële analyse- en rapportagetools

De feitelijke projecties kunnen vervolgens worden gemaakt op basis van een geaccordeerde set van economische parameters en van specifieke portefeuilleparameters. De uitkomsten van de projecties kunnen zo nodig worden opgeslagen in het datawarehouse.

Er zijn veel standaard-rapportagetools in de markt die kunnen worden gebruikt om in de vereiste statutaire en de gewenste managementinformatierapportages te voorzien. Met de beschikbare gegevens kunnen periodiek, maar ook ad hoc scenarioanalyse en stochastische berekeningen worden uitgevoerd naast de voor de jaarrekening, MCEV en Solvency II benodigde calculaties. Alle uitkomsten van de calculaties en rapportages kunnen worden opgeslagen in hetzelfde datawarehouse als waarin de cashflows en variabelen zijn opgeslagen. Meer in het bijzonder kan op deze manier de informatie ontleend aan de resultatenrekening en balans per contract (inclusief de gegevens nodig voor een resultaat naar bronnenanalyse) worden vastgelegd. Als hetzelfde principe ook wordt gehanteerd om veranderingen als gevolg van contractwijzigingen direct door te voeren en op te slaan, en hiermee niet te wachten tot het eind van de rapportageperiode, kan men op dagbasis beschikken over de resultatenrekening- en balansinformatie voor dat moment.

Samenvatting voordelen cashflow based reporting

De voordelen van deze aanpak zijn velerlei:

  • Er worden vooral veel minder data opgeslagen in het datawarehouse.
  • De berekening van de cashflows gebeurt op het moment dat het kan (bij iedere contractwijziging) en niet op het moment dat het niet meer anders kan (namelijk aan het eind van een rapportageperiode), waardoor bottlenecks op rapportagemomenten worden voorkomen.
  • De rapportages zijn gebaseerd op gegevens op contractniveau zonder aannames en alle soorten rapportages hebben eenzelfde generieke basis waardoor de aansluiting wordt gegarandeerd. Er wordt gewerkt met brondata in plaats van modellen (zoals ook in het geval van ‘replicating portfolios’), waardoor ook het onderhoud van deze modellen niet meer nodig is.
  • Het hele proces kan worden verplaatst naar een professionele IT-omgeving die aan de moderne internecontrole-eisen voldoet waarbij de legacy systemen niet worden aangetast.
  • Met één druk op de knop komt de informatie gelijk beschikbaar zodat wordt voldaan aan de ‘in control’-eisen vanuit Solvency II.
  • Door het vastleggen en up-to-date houden van de verlies & winstrekening en balans per verzekeringscontract is de aansluiting tussen Finance en Risk continu gegarandeerd.
  • Het rapportageproces verloopt geautomatiseerd, er is geen handmatige inbreng noodzakelijk en er is een volledige audit trail.
  • Het proces verloopt door de nieuwe aanpak vele malen sneller waardoor de beoogde besparingen op het gebied van het verzamelen, verrijken en schonen van data realistisch worden en er meer tijd voor analyse ontstaat. Dit wordt weergegeven in figuur 5.

C-2010-3-Beek-05

Figuur 5. Beperken van arbeidsintensieve en repeterende werkzaamheden ten gunste van advies.

Rol IT-auditor en relatie met de jaarrekeningcontrole

De afgelopen jaren is de rol van de IT-auditor bij de controle van verzekeraars steeds belangrijker geworden. De afhankelijkheid van de geautomatiseerde gegevensverwerking is alleen maar toegenomen en als geen ander kent de IT-auditor de problematiek van de legacy systemen bij verzekeraars. De combinatie van applicatiecontroles en algemene computercontroles is bij veel verzekeraars niet effectief en vaak moeten compenserende gegevensgerichte werkzaamheden plaatsvinden waarbij data-analyse onontbeerlijk is.

Een specifieke eis bij de controle van verzekeraars is de controle van de basisgegevens. Op grond van de basisgegevens bepaalt de actuaris de hoogte van de voorziening voor verzekeringsverplichtingen. Zonder betrouwbare input geen betrouwbare voorziening en daarmee resultaat. De IT-auditor is bij uitstek bekend met dit proces. Hij is daarom ook in staat te adviseren hoe dit anders en beter kan. Een opvallend aspect van de controle op de basisgegevens is dat dit elk jaar opnieuw plaatsvindt. Als er sprake is van basisgegevens, is er maar in beperkte mate sprake van wijzigingen. Met de geschetste oplossingsrichting uit de voorgaande paragraaf wordt ook de controle van de basisgegevens zelf veel eenvoudiger doordat specifiek aandacht kan worden besteed aan de wijzigingen in de basisgegevens ten opzichte van de voorgaande periode.

Gezien de complexiteit en de organisatorische impact van Solvency II voor verzekeraars, met name ook op IT-gebied, is het belangrijk dat IT-auditors vanaf het begin bij de Solvency II-implementatie worden betrokken. De IT-auditor is bij uitstek de onafhankelijke deskundige op het gebied van IT zodat hij bij problemen rond het ontsluiten van data uit de bronsystemen en data warehousing als adviseur kan optreden. Noodzakelijke Solvency II-kennis, inclusief kennis op het gebied van interne modellen, zal veel meer bij de actuariële discipline aanwezig zijn. Multidisciplinaire samenwerking is vereist zodat actuarissen, IT-adviseurs en auditors nauw samenwerken op het gebied van Solvency II.

Wat zijn de mogelijke fasen hierna?

Zoals beschreven hebben we in het datawarehouse een polisadministratie gerealiseerd die uitsluitend is gebaseerd op cashflowvectoren en waarbij de berekeningsuitkomsten met één druk op de knop beschikbaar kunnen zijn. Dit betekent dat we naast de al gerealiseerde voordelen met betrekking tot het sneller en betrouwbaarder rapporteren nog meer toegevoegde waarde kunnen creëren. Wij beschrijven hier een aantal voordelen die op basis van de gekozen oplossing beschikbaar komen:

  • Bij veel verzekeraars zijn berekeningen voor afkoopwaarde vaak tijdrovend, arbeidsintensief en wordt er gewerkt op basis van een vastgestelde set van formules op discrete basis. Binnen deze aanpak wordt het mogelijk afkoopwaarden (en andere contractwaarderingen) op basis van een marktconsistente waarde snel en efficiënt te bepalen. Dat zal een vereiste zijn indien op basis van een marktconsistente waarde wordt gerapporteerd.
  • Wanneer we uitgaan van de veronderstelling dat alle verzekeringsproducten voorgesteld kunnen worden als een combinatie van cashflows kan de time to market van productontwikkeling teruggebracht worden van maanden naar dagen of zelfs uren! Ook combinaties van producten vormen dan geen belemmering meer en kunnen eenvoudig worden gerealiseerd. In feite kan elke combinatie van cashflows worden gebundeld tot een nieuw product. Dit betekent ongekende mogelijkheden voor de marketingafdeling, terwijl de gehele rapportagestructuur al generiek is ingericht en niet meer opnieuw behoeft te worden opgebouwd.
  • Doordat cashflowvectoren eenvoudig kunnen worden gecombineerd en de berekeningen snel beschikbaar zijn, leent de oplossing zich ook om contractinformatie en de waarde van een verzekeringscontract snel beschikbaar te krijgen voor polishouders, bijvoorbeeld via web-based applicaties.
  • Voor de waardering van verzekeringscontracten is de historie eigenlijk niet van belang. Overwogen kan worden de overgang in de contractadministratie te maken van productgericht naar cashflow als basis. Het moge duidelijk zijn dat de inspanning noodzakelijk om een traditionele backoffice-administratie bij te houden vele malen groter is dan die voor een cashflowadministratie. De laatste maakt een veel efficiëntere procesgang mogelijk.

Gevolgen voor de organisatie

Het ontsluiten van cashflows als basis voor de rapportages voor verschillende stakeholders binnen en buiten de organisatie is niet alleen een IT-project. Het heeft ook zeker gevolgen voor de betrokken afdelingen zoals Finance, Risk en het Actuariaat.

  • Zoals eerder genoemd is cashflow de kleinste bouwsteen van de rapportage-elementen van onder andere de financiële, risk en actuariële rapportages. De aansluiting tussen deze rapportages benodigd voor Solvency II, die hiermee kan worden gerealiseerd, is dan ook een groot voordeel van deze aanpak. De afdelingen Finance, Risk en het Actuariaat zijn echter verre van geïntegreerd. De afdelingen opereren los van elkaar met eigen processen, systemen en rapportages. De grenzen tussen de verschillende afdelingen zullen voor een succesvolle implementatie van Solvency II in ieder geval moeten worden geslecht. Het voordeel van het gebruik van cashflows is juist de gemeenschappelijkheid ervan als basis voor de harmonisatie.
  • Transparantie en controleerbaarheid kan als een bedreiging worden gezien door de betrokken afdelingen die daarmee een deel van de onafhankelijkheid verliezen. Echter, hun taken zullen worden verrijkt doordat nu (meer) tijd beschikbaar is voor analyses en voor het voorbereiden van beleidsbeslissingen.
  • Afdelingen als Finance, Risk en Actuariaat worden bemenst met vakmensen met hun eigen specialisme, methoden en tooling. Samenwerking tussen specialisten brengt doorgaans problemen met zich mee. Zo zal het rapportageproces in het kader van bijvoorbeeld de maandafsluiting eveneens sterk veranderen, wat ook gevolgen heeft voor de eigen planning en werkwijze.
  • Als cashflow de basis wordt voor meerdere rapportages voor verschillende afdelingen komt de vraag over eigenaarschap al snel op. Wie is nu eigenaar van het datawarehouse, de tooling, maar vooral van de data zelf? Het beleggen van het eigenaarschap zal geen makkelijke opdracht zijn maar het is wel een essentiële stap in de realisatie van een afdelingsoverstijgende verandering.

Wij hebben hierboven een aantal organisatorische aspecten beschreven die in het kader van change management van groot belang zijn voor een succesvolle implementatie van Solvency II en rapportering op basis van cashflows. Uiteindelijk is Solvency II eigenlijk niet een compliancevraagstuk of een vraagstuk van rapportagesystemen, maar zal ook de strategie van de verzekeraars moeten worden bijgesteld om de nieuwe noodzakelijke balans tussen risico’s en rendement inzichtelijk te krijgen. Als deze veranderingen niet door het hoogste managementniveau worden onderschreven en uitgedragen, zal het moeilijk blijven om ook op rapportagegebied stappen vooruit te maken. Wij horen in de praktijk momenteel nog vaak het argument dat bestaande problemen al veel aandacht vragen en er weinig tijd is om meer fundamentele zaken zoals cashflow based reporting op te pakken. Solvency II en de effecten daarvan op de organisatie leven kennelijk nog te weinig waardoor kansen worden gemist om in één keer een aantal voordelen te realiseren. Wij verwachten het komende jaar een omslag op dit gebied waarbij verzekeraars die wel ruimte maken om te innoveren op dit gebied een belangrijk concurrentievoordeel kunnen bewerkstelligen.

Samenvatting en conclusie

Door verzekeraars worden op dit moment gap-analyses gestart op gebied van Solvency II. Hierbij is er vooral aandacht voor de gevolgen van de berekeningswijze van de kapitaalvereisten en het inrichten van de modellen. In dit artikel werd ingegaan op de gevolgen voor de actuariële reporting en is een oplossing aangereikt om te komen tot continuous monitoring op basis van cashflows als fundament voor het voldoen aan de ‘in control’-eisen die de kern van Solvency II vormen. De IT-auditor vervult tussen de actuarissen en specialisten vanuit risk management een belangrijke rol in de realisatie van Solvency II-compliance.

Als beter kan worden voldaan aan de nieuwe ‘in control’-eisen betekent dit ook dat de controle van de jaarrekening kan worden vereenvoudigd, met name voor wat betreft de controle van de basisgegevens en de verzekeringstechnische voorziening. Op basis van zijn ervaring kan de IT-auditor adviseren over verbeteringen en samen met actuarissen en specialisten vanuit risk management een belangrijke rol spelen bij het traject van de realisatie van Solvency-compliance.

Literatuur

[CEIO08] CEIOPS Advice for L2 Implementing Measures on SII: ‘System of Governance’, 10 november 2009.

[Dijk09] Agnes van Dijk, Carola Steenmeijer en Ad Kok, Solvency II overview, presentatie KPMG 8 april 2009.

[Meer09] Age Jan van der Meer, De IT-impact van Solvency II, de EDP auditor, 1, 2009.

Optimaliseren afsluit- en rapportageproces: juist nu!

In de snel veranderende omgeving met de toenemende onzekerheid van tegenwoordig, is het nog belangrijker geworden om snel over betrouwbare managementinformatie te beschikken. Dit heeft tot gevolg dat de druk op de organisatie om over een optimaal afsluit- en rapportageproces te beschikken vergroot is. Door een aantal stappen te zetten waaronder het inzichtelijk maken van het afsluit- en rapportageproces en het implementeren van ‘quick wins’ kan een eerste antwoord worden gegeven op deze toenemende druk.

Hogere verwachtingen van stakeholders veroorzaken toenemende druk

Het snel over betrouwbare managementinformatie beschikken is van belang voor zowel het management van de organisatie zelf als voor andere stakeholders zoals aandeelhouders, analisten en toezichthouders. De toenemende druk wordt veroorzaakt door hogere verwachtingen:

Management wil in staat zijn snel bij te sturen

Door de onzekerheid in de markt dienen gegevens over onder meer omzet, kosten en liquiditeit direct beschikbaar te zijn zodat de leiding indien nodig snel kan bijsturen. Ook zorgt een snelle informatievoorziening ervoor dat er meer tijd besteed kan worden aan waardetoevoegende activiteiten zoals analyse en beslissingsondersteunende taken, iets wat erg belangrijk is in een omgeving waarin je kort op de business moet zitten.

Markt en investeerders vragen snelle en betrouwbare informatie

De economische teruggang veroorzaakt onzekerheid bij investeerders, zij willen daarom snelle en betrouwbare informatie zien over huidige en toekomstige resultaten van de onderneming. De onderneming kan haar imago positief beïnvloeden door snel en betrouwbaar te rapporteren; zo laat zij zien dat ze haar zaakjes administratief op orde heeft.

Stakeholders kijken kritisch naar de kosten van de organisatie

Er wordt kritischer naar de totale kosten van de organisatie gekeken, inclusief de kosten van de financiële functie. Efficiënter werken en terugbrengen van de doorlooptijd in het afsluit- en rapportageproces leidt naar verwachting tot kostenbesparing.

Versnellen én verbeteren van de kwaliteit door integrale aanpak

Om het afsluit- en rapportageproces daadwerkelijk te optimaliseren dient de organisatie te kijken naar de versnelling van het proces zonder daarbij de kwaliteit van de rapportage uit het oog te verliezen. Tussen snelheid en kwaliteit is een direct verband te leggen: een snelle oplevering van de rapportages is alleen zinvol wanneer de cijfers aan de gewenste kwaliteit voldoen. Dé reden voor vertraagde publicatie is gelegen in het feit dat de cijfers niet in een eerder stadium betrouwbaar opgeleverd kunnen worden.

Het efficiënter maken van het afsluit- en rapportageproces, het vergroten van de kwaliteit en het vaststellen van de relevantie van de rapportages die opgeleverd worden, vraagt om een integrale aanpak waarbinnen verschillende onderdelen met elkaar samenhangen (figuur 1).

Door bijvoorbeeld vast te stellen welke rapportages gewenst zijn, wordt bepaald welke gegevens geconsolideerd dienen te worden en welke elementen bij het afsluiten van het grootboek een rol spelen.

C-2010-2-Kouwenhoven-01

Figuur 1. Afsluit- en rapportageproces. [Klik hier voor grotere afbeelding]

Naast het bekijken van het afsluit- en rapportageproces in samenhang wordt er gekeken naar de verschillende elementen die invloed uitoefenen op dit proces. Bij het identificeren hiervan helpt het om onderscheid te maken in de volgende categorieën: mensen & organisatie, processen, systemen, en output & rapportage.

De integrale aanpak onderscheidt zich van de traditionele benaderingen die zich voornamelijk richten op de versnelling van het proces, door onder andere de volgende zaken:

  • De aanpak richt zich op het vinden van een balans tussen snelheid en kwaliteit van rapportageprocessen.
  • Het sneller en beter willen afsluiten en rapporteren is een business issue en niet alleen een finance issue.
  • Integrale benadering van het proces van begin tot eind: van bron(systemen) tot rapportage.
  • Aandacht voor accountingvraagstukken in combinatie met efficiency van processen en systemen en organisatieveranderingen (inclusief mensen en cultuur).
  • Integrated reporting: het op elkaar afstemmen van de interne én de externe informatievoorziening.

De businesscase voor het management is het creëren van een stevige financiële functie die in staat is snel en betrouwbaar informatie te genereren zodat het management direct kan inspelen op veranderingen in de business. Een goed afsluit- en rapportageproces heeft dan ook direct een positief effect op het opstellen van forecasts en budgettering.

In het vervolg van dit artikel gaan we in op de verbeteringen die in het afsluit- en rapportageproces te realiseren zijn en hoe die bereikt kunnen worden. De nadruk zal liggen op de verbeteringen die op korte termijn, binnen twee maanden, geïmplementeerd kunnen worden. Aan deze zogenoemde ‘quick wins’ is in deze tijd de grootste behoefte. Door quick wins te implementeren is de onderneming in staat haar afsluit- en rapportageproces een eerste verbeterslag te geven. Het doorvoeren van structurele verbeteringen of nog verder, het herontwerpen van de rapportageprocessen vergt vaak grote investeringen en een langere implementatietijd.

De start

Starten met het optimaliseren van het afsluit- en rapportageproces kan de volgende stappen doorlopen:

  1. samenstellen van een afsluitteam;
  2. inzichtelijk maken huidig afsluit- en rapportageproces;
  3. identificeren verbetermogelijkheden;
  4. inzichtelijk maken gewenst afsluit- en rapportageproces, maken keuze voor implementatie quick wins en vaststellen van prioriteiten ten aanzien van verbeteringen;
  5. implementeren gewenst afsluit- en rapportageproces en quick wins.

Stap 1. Samenstellen van een afsluitteam

Om tot een geoptimaliseerd afsluit- en rapportageproces te komen is het van belang om álle medewerkers erbij te betrekken die invloed hebben op het afsluit- en rapportageproces. Dit betekent dat naast de financiële afdeling ook bijvoorbeeld de afdeling HR (personeelsgegevens) en de afdeling Sales (klant- en omzetgegevens) bij het proces betrokken zijn. Door het afsluit- en rapportageproces in te richten als project, kan binnen de organisatie belegd worden wie welke activiteiten wanneer gaat uitvoeren. Benoem een (tijdelijke) projectleider die het proces coördineert. Meestal wordt deze rol door de controller ingevuld.

Stap 2. Inzichtelijk maken van huidig afsluit- en rapportageproces

Een relatief eenvoudige tweede stap bij het verbeteren van het afsluit- en rapportageproces is het organiseren van een workshop met het afsluitteam. In deze workshop maken de deelnemers de ‘deliverables’ inzichtelijk: welke zaken moeten we opleveren? Begin met het eindproduct voor ogen: de deelnemers stellen een lijst op met de op te leveren rapportages. Vanuit het eindproduct kan men terugredeneren naar de activiteiten die nodig zijn om deze rapportage tot stand te brengen.

Per rapportage wordt vastgesteld:

  • welke activiteiten plaatsvinden;
  • wanneer deze activiteiten uitgevoerd worden;
  • wie deze activiteiten uitvoert.

Stap 3. Identificeren verbetermogelijkheden

Door het in kaart brengen van de activiteiten komen ‘automatisch’ verbeterpunten naar voren. Zo kan bijvoorbeeld blijken dat activiteiten op verschillende tijdstippen plaatsvinden, meerdere personen dezelfde werkzaamheden uitvoeren of dat zaken juist blijven liggen.

Zoals eerder gezegd: bij het identificeren en structureren van de verbeteringen is het aan te bevelen om deze te categoriseren in de deelgebieden mensen & organisatie, processen, systemen, en output & rapportage. In figuur 2 worden enkele suggesties gedaan voor verbeteringen die binnen twee maanden te realiseren zijn. Deze suggesties kunnen worden gebruikt als startpunt om de quick wins voor de eigen organisatie in kaart te brengen.

C-2010-2-Kouwenhoven-02

Figuur 2. Suggesties van verbeteringen die relatief snel geïmplementeerd kunnen worden. [Klik hier voor grotere afbeelding]

Stap 4. Inzichtelijk maken gewenst afsluit- en rapportageproces, maken keuze voor implementatie quick wins en vaststellen van prioriteiten ten aanzien van verbeteringen

Nadat de huidige activiteiten in kaart gebracht zijn, kan gestart worden met het opstellen van een activiteitenkalender van de gewenste situatie, inclusief activiteiten, tijdsplanning en verantwoordelijken. Daarnaast wordt vastgesteld welke quick wins te implementeren zijn.

Door de quick wins te prioriteren en vast te leggen in een actieplan wordt voor iedereen die bij het afsluit- en rapportageproces betrokken is, duidelijk waar de komende periode aan gewerkt zal gaan worden en wat de beoogde verbetering in kwaliteit en/of snelheid is.

Stap 5. Implementatie van verbeteringen

Nu inzichtelijk is gemaakt wat het gewenste proces is voor de oplevering van een rapportage en welke verbeteringen te realiseren zijn, dient stap 5 niet vergeten te worden: het daadwerkelijk implementeren van deze verbeteringen. Dit is geen eenmalige actie, maar dient gecoördineerd plaats te vinden waarbij voortdurende monitoring door de projectleider gewenst is. Het is daarbij belangrijk prioriteiten te stellen en te starten met de activiteiten die snel te implementeren zijn en snel resultaat opleveren zodat mobilisatie en verandering in de onderneming gerealiseerd worden.

Resultaat

Een verbeterd afsluit- en rapportageproces helpt te voldoen aan de wensen van de interne en externe stakeholders. Het maakt het proces efficiënter, beter beheersbaar en minder complex. Een verbeterd afsluit- en rapportageproces heeft als verwacht resultaat dat informatie eerder en van een kwalitatief hoogwaardiger niveau beschikbaar gesteld kan worden tegen lagere kosten (zie figuur 3).

C-2010-2-Kouwenhoven-03

Figuur 3. Te verwachten resultaten van verbeteringen die leiden tot het voldoen aan de wensen van de stakeholders. [Klik hier voor grotere afbeelding]

Concluderend: elke verbetering is welkom

In dit artikel is ingegaan op het belang van een snelle en betrouwbare informatievoorziening, de stappen tot verbetering en het realiseren van quick wins. Het resultaat van deze acties zal per onderneming verschillen. Het creëren van inzicht in het afsluit- en rapportageproces en het implementeren van de geopperde quick wins zullen in ieder geval in elke onderneming een positief effect hebben op het afsluit- en rapportageproces.

In deze tijd is elke verbetering welkom, zeker wanneer deze relatief eenvoudig te realiseren is. De keus van welke en hoeveel quick wins geïmplementeerd worden en daarnaast welke structurele stappen ondernomen worden om het proces ook op de langere termijn te verbeteren, is uiteraard aan de onderneming zelf.

Case: Getronics: de intercompanyrapportage, eerste fase van de verbetering

Getronics stelt maandelijks haar managementrapportage op waarvan de intercompanyrapportage er één is. Gedurende de afsluiting is dit een element dat steeds tot vertraging leidt en waarover veel discussie is.

Het huidige proces was vastgelegd in een procedure en zag er in hoofdlijnen als volgt uit:

C-2010-2-Kouwenhoven-t01

Tabel 1. Processtappen met bijbehorende tijdsplanning en verantwoordelijkheden oude situatie.

Stap 1 tot en met 3. Opzetten van afsluitteam, inzichtelijk maken van huidig afsluit- en rapportageproces en identificeren verbetermogelijkheden

Het management van de organisatie heeft de controller als projectleider aangewezen voor het intercompanyproces. Deze heeft als startpunt een workshop georganiseerd waarbij alle betrokkenen van het intercompanyproces samengebracht zijn. In deze bijeenkomst is vastgesteld in hoeverre bovenstaande activiteiten (zoals vastgelegd in de accounting manual) compleet zijn, wanneer de activiteiten op dit moment uitgevoerd worden en door wie.

Bij het inzichtelijk maken van de huidige situatie kwamen de volgende verbeterpunten naar voren:

  • Het was niet voor iedereen helder hoe het gehele proces eruitzag. Zo was bij een medewerker van een businessunit niet bekend wat er met de gegevens die aangeleverd werden, op het hoofdkantoor gebeurde.
  • Een aantal personen was niet met bovenstaande planning bekend, waardoor ook na werkdag –8 facturen verzonden werden aan andere interne partijen.
  • Er bleek veel onderlinge afstemming nodig tussen de verschillende businessunits.
  • Taken en verantwoordelijkheden in het proces waren niet duidelijk.
  • Er was geen standaard-rapportagetemplate voor intercompanyafstemming.
  • De tijdsspanne van het proces was ruim.
  • Het IC-proces bevond zich op het kritische pad van de afsluiting: in een periode wanneer men het erg druk heeft.

Stap 4. Inzichtelijk maken gewenst afsluit- en rapportageproces, maken keuze voor implementatie quick wins en vaststellen van prioriteiten ten aanzien van verbeteringen

In een tweede bijeenkomst is gezamenlijk gekomen tot een nieuwe planning van het IC-proces:

C-2010-2-Kouwenhoven-t02

Tabel 2. Processtappen met bijbehorende tijdsplanning en verantwoordelijkheden nieuwe situatie.

Uit tabel 2 blijkt dat de doorlooptijd met de helft verkort is. Daarnaast is het IC-proces uit het kritieke pad gehaald.

Andere verbeteringen die opgepakt zijn:

  • Er is gekozen voor één afstemmoment, dat gecoördineerd wordt door het hoofdkantoor.
  • Taken en verantwoordelijkheden ten aanzien van het intercompanyproces zijn op één A4’tje vastgelegd en ondertekend door de betrokkenen.
  • Er is een standaardtemplate ontwikkeld die gebruikt wordt bij de afstemming.

Stap 5. Implementeren gewenst afsluit- en rapportageproces en verbetermogelijkheden

Door bovenstaande stappen te communiceren binnen de onderneming en de centrale coördinatie te beleggen bij het hoofdkantoor is de onderneming in staat gebleken het IC-proces binnen twee maanden aanzienlijk te verbeteren. Dit proces bleek dan ook geen vertragende factor meer te zijn in het afsluitproces.

AudIT Innovation

Hoe haal ik meer waarde uit mijn SAP-systeem? Dat is de titel van het onderzoek uitgevoerd door KPMG IT Advisory, KPMG Audit en KPMG Meijburg bij organisaties in Zuid-Nederland die SAP gebruiken. Naast vragenlijsten en interviews is ook een tweetal ronde tafels georganiseerd op 17 juni en 9 juli 2009 op de Hightech Campus Eindhoven. Het onderzoek omvat onderwerpen op het gebied van het optimaliseren van SAP, zoals centralisatie, business proces management, btw en innovatie op het gebied van de financiële audit. Het onderzoek is in december 2009 verschenen in een beperkte boekoplage ([KPMG09]) ten behoeve van de betrokken organisaties.

In dit artikel wordt op de eerste plaats ingegaan op de visie van KPMG op het gebied van AudIT Innovation. Hierin zullen de ontwikkelingen bij de organisaties en de reactie hierop van hun accountants worden beschreven. Daarna wordt een terugkoppeling gegeven van de enquêteresultaten en de samenvatting van de rondetafeldiscussies.

Visie van KPMG

De huidige focus van organisaties op centralisatie van ERP-systemen heeft in eerste instantie vooral kostenbesparingen, harmonisatie en standaardisatie als doelstelling. Echter, deze centralisatie maakt ook innovaties van de aanpak van de jaarrekeningcontrole (financiële audit) mogelijk. Door het centraal beschikbaar hebben van transactiedata kan de jaarrekeningcontrole verder worden gecentraliseerd. De opzet van (financial) shared service centers zal de mogelijkheid om audits te centraliseren vergroten.

De accountant streeft een efficiënte en effectieve jaarrekeningcontrole na. Door gebruik te maken van centraal beschikbare data en (financiële) processen, kunnen routinematige transactionele processen efficiënter worden gecontroleerd. De accountant zal minder tijd nodig hebben voor handmatige controles van deze processen en zich vooral kunnen richten op niet-routinematige posten. Het gebruik van de operationele transactie- en procesinzichten door de accountant wakkert vaak ook een behoefte in de organisatie aan. Indien de organisatie deze inzichten zelf gaat monitoren en beschikbaar stellen heeft dat niet alleen een positieve en continue uitwerking op het internecontrolesysteem van de organisatie zelf, maar het stelt de accountant in staat hier ook gebruik van te maken. Dit leidt dan tot een aanpak die Continuous Monitoring ([KPMG08]) wordt genoemd.

AudIT-aanpak in drie fasen

KPMG heeft een maturitymodel ontwikkeld dat de groei van deze AudIT-aanpak weergeeft (zie figuur 1).

C-2010-1-Veld-01

Figuur 1. Maturitymodel AudIT-aanpak.

Fase 1. Multiple ERP approach

Bij organisaties die in elk land een apart ERP- of IT-systeem hebben ingericht, wordt de Multiple ERP approach toegepast. Hierbij is vaak sprake van een beperkte IT- controleomgeving waarbij door de organisaties wel algemene IT-maatregelen zijn ingericht, maar weinig focus bestaat op geautomatiseerde controls binnen de bedrijfsprocessen. Voor de controle van de jaarrekening kiest de accountant vaak een lokale gegevensgerichte aanpak. De mogelijkheden tot efficiency zijn beperkt en er bestaat een reële kans op dubbel auditwerk in de diverse landen. Uiteindelijk resulteert dit in een niet-optimale aanpak.

Veel organisaties bewegen zich momenteel naar fase 2, die veel mogelijkheden biedt voor het optimaliseren en innoveren van de auditaanpak.

Fase 2. Central ERP approach

Met kostenreductie als voornaamste drijfveer centraliseren veel organisaties momenteel hun ERP-systemen. Dit vindt in veel gevallen plaats in combinatie met het opzetten van shared service centers. Door deze centralisatie is ook een verdere top-down- en risicogebaseerde audit mogelijk. Er zijn minder lokale procedures noodzakelijk door het uitvoeren van centrale procedures en centraal verkregen inzicht. Volledigheid van omzet kan bijvoorbeeld centraal worden getest door voor alle landen te analyseren of alle verkooporders goed zijn uitgeleverd, gefactureerd en uiteindelijk geboekt in het grootboek. Door centraal te verifiëren dat (routinematige) transacties in het verkoopproces juist en volledig zijn verwerkt, hoeven de lokale accountants geen procedures meer op deze posten uit te voeren. Dit kan ook leiden tot een reductie van de auditfee.

Fase 3. Continuous Monitoring

De derde fase van het maturity-auditmodel wordt aangeduid met Continuous Monitoring. Dit is een logisch vervolg op de vorige fase, waarbij niet de auditor maar de organisatie zelf de diverse inzichten genereert. Vaak volgt dit uit de behoefte van de organisatie om zelf continu zicht te hebben op de internecontrolestatus. Vaak wordt gebruikgemaakt van geautomatiseerde tooling. In deze tooling worden zogenaamde ‘rules’ gedefinieerd, die continu het ERP-systeem analyseren op mogelijke overtreding van deze rule. Deze uitzonderingen worden vervolgens gerapporteerd aan de verantwoordelijke medewerkers voor verdere opvolging. Voor het genoemde voorbeeld uit de vorige fase betekent dit dat de uitzonderingen op het gebied van de volledigheid van de omzet direct kunnen worden opgelost.

Naast het oplossen van problemen voordat ze verdere gevolgen hebben, wordt met deze aanpak ook inzicht verkregen in de kwaliteit van processen en controls. Door de oorzaak van problemen te analyseren kan op basis van de uitkomsten het systeem worden aangepast, zodat deze uitzonderingen in de toekomst kunnen worden voorkomen.

De AudIT-aanpak in de praktijk

Er is een duidelijke overgang te zien tussen de traditionele auditaanpak (Multi ERP approach) en de toekomstige auditaanpak (Central ERP en Continuous Monitoring approach). In de traditionele aanpak lopen lokale teams simpelweg elke post van de balans na. De lokale resultaten worden geanalyseerd door de businessunit of procesteams alvorens te worden doorgezet naar het centrale team (zie figuur 2).

C-2010-1-Veld-02

Figuur 2. Transitie naar AudIT-aanpak.

De toekomstige audit zal meer gebruikmaken van de centraal toegankelijke SAP-systemen en (manuele) controles uitgevoerd door een shared service center. Een op SAP gebaseerde auditbenadering is een zeer efficiënte en effectieve aanpak. Efficiënt omdat maximaal wordt gesteund op functiescheidingen en geautomatiseerde controles. Effectief doordat – ondersteund door IT-auditors – via data-analyses ongewenste functievermengingen en/of niet goed functionerende geautomatiseerde controles zichtbaar worden gemaakt.

Door de op SAP gebaseerde auditbenadering richt de controle zich nadrukkelijker op uitzonderingen in routinematige processen. Daarnaast zullen het financial auditteam en het centrale team zich toeleggen op de niet-routinematige processen zoals waarderingen en analytische procedures. In het uiterste geval zullen de lokale teams alleen nog het bestaan van activa vaststellen. Naast efficiencyvoordelen, zo leert de praktijk, wordt met de AudIT-aanpak meer toegevoegde waarde gecreëerd, waarbij samen met de organisatie mogelijkheden tot business improvement worden geïdentificeerd.

Specifieke enquêteresultaten

Uit de interviews blijkt dat accountants het SAP-systeem gebruiken bij het uitvoeren van controlewerkzaamheden. Uit de enquêteresultaten (totaal 31 organisaties) blijkt verder dat de organisaties zich op verschillende niveaus van volwassenheid bevinden (zie figuur 3). Zo zitten de meeste organisaties nog in de Multiple ERP approach (22). Het merendeel van deze organisaties beweegt zich wel al naar de Central ERP approach door onder andere hun centralisatieprojecten. De Central ERP approach is terug te zien bij acht organisaties. Slechts één organisatie is al verder gevorderd en past Continuous Monitoring toe. De mogelijkheden voor verdere optimalisatie zijn dus zeker aanwezig.

C-2010-1-Veld-03

Figuur 3. Enquêteresultaten AuditIT-aanpak. [Klik hier voor grotere afbeelding]

Interessant is te zien hoe verschillend de betrokken accountants IT-auditprocedures inzetten bij deze organisaties. In zijn algemeenheid kun je een aantal groepen onderscheiden in het gebruik van het SAP-systeem binnen de audit.

  • Focus op IT general controls (13 organisaties)

    Het testen van de zogenoemde IT general controls (ITGC) en functiescheidingen in het proces. Deze controles hebben echter weinig tot geen directe efficiencyverhoging van de audit tot gevolg.
  • Focus op IT application controls, naast ITGC (12 organisaties)

    Bij het gebruik van IT application controls (ITAC) wordt de nadruk gelegd op het testen van de SAP-configuratiecontroles in de bedrijfsprocessen. Veelgenoemde voorbeelden zijn de three-way-match en de automatische facturatie. Deze controls kunnen de efficiency van de audit verhogen. Deze is echter vaak beperkt, doordat slechts één specifieke stroom van transacties wordt getest.
  • Focus op Data Analytics, naast ITGC en ITAC (6 organisaties)

    Met behulp van Data Analytics kunnen alle transacties in het SAP-systeem worden gecontroleerd. Vanuit alle betaalde inkoopfacturen kan worden bepaald welke via de three-way-match, de two-way-match, buiten de toleranties of rechtstreeks via het grootboek zijn ingeboekt, waarbij ook rekening wordt gehouden met de functiescheidingen. Een beperkt aantal uitzonderingen dient nog te worden opgevolgd, waardoor op een efficiënte wijze een volledige controle uitgevoerd is en veel audit evidence (positive assurance) kan worden verkregen.

In het kader is een concreet praktijkvoorbeeld uitgewerkt, dat laat zien hoe op basis van data-analyse voor het inkoopproces op effectieve wijze identificatie en verdere evaluatie van restrisico’s kan worden uitgevoerd.

Indien de beide inzichten worden gecombineerd, zien we dat de aanpak van de accountants op het gebied van de IT-auditprocedures vaak afhangt van de volwassenheid van een organisatie. Bij een Multiple ERP approach heeft de accountant vooral focus op de ITGC en functiescheidingen. Uitbreidingen met ITAC en Data Analytics-procedures worden hier minder toegepast. Wel is opvallend dat ondanks de Multiple ERP approach toch Data Analytics toegepast wordt in de auditaanpak. Dit geeft aan dat de accountant verder is met de auditaanpak dan overeenkomt met de volwassenheid van de organisatie. Vaak heeft de accountant dan ook meer inzicht in de SAP-processen dan de organisatie, zodat ook op dit volwassenheidsniveau toegevoegde waarde door de accountant wordt geleverd.

Naarmate de volwassenheid van de organisatie toeneemt, zal ook de toepassing van IT-auditprocedures door de accountant worden aangepast. Zo wordt er relatief meer focus gelegd op ITAC en Data Analytics.

Samenvattend kan dus worden gesteld dat op alle volwassenheidsniveaus de accountant door IT-auditprocedures een toegevoegde waarde heeft voor de audit en de organisatie. Ook zal door de verdere centralisatie van organisaties de aanpak veranderen, waardoor een verdere optimalisering van de auditaanpak kan ontstaan.

Rondetafeluitkomsten

De rondetafeldiscussies op 17 juni en 9 juli zijn geopend met een praktijkcasus van Philips op het gebied van Continuous Monitoring. Hieruit blijkt dat het succes van Continuous Monitoring niet alleen een betere en efficiëntere controle oplevert, maar ook een grotere transparantie van de bedrijfprocessen om mogelijke procesverbeteringen te identificeren. Dit verbetert de samenwerking met lokale units. De boodschap is dan: ‘we komen je helpen te verbeteren’ in plaats van: ‘we gaan nog meer centraal monitoren’. Continuous Monitoring en Continuous Improvement gaan daarmee hand in hand.

Tijdens de rondetafeldiscussies werd opgemerkt dat in principe de oude en nieuwe auditaanpak hetzelfde zijn, maar dat de techniek de audit nu goedkoper en sneller maakt. Daardoor is er tijd beschikbaar om de uitzonderingen beter te bekijken en te begrijpen, wat vroeger minder gebeurde. Echter, Continuous Monitoring kan ook worden gezien als Continuous Auditing, waarbij de auditor gedurende het jaar input kan geven, zodat verrassingen aan het eind van het jaar zoveel mogelijk worden voorkomen. Dit levert duidelijk meer toegevoegde waarde en hierin verschilt de nieuwe aanpak ook van de oude.

Deze nieuwe aanpak spreekt het merendeel van de deelnemers aan. De centralisatie en harmonisatie van IT en shared service centers wordt wel nog gezien als een uitdaging. Veel organisatieonderdelen werken nog op hun eigen wijze (lokaal georiënteerd). ‘De company-afhankelijkheid moet je eruit halen.’ Het management moet hier beslissingen in nemen en die organisatiebreed afdwingen en doorvoeren.

De vraag of Continuous Monitoring alleen voor SOx-organisaties relevant is wordt door de deelnemers volmondig met ‘nee’ beantwoord. Ook het argument dat ‘het moet van de accountant’ blijkt niet de manier te zijn om naar Continuous Monitoring door te groeien. De belangrijkste drijfveer moet zijn dat organisaties een continue procesverbetering nastreven: ‘betere controle is een handig bijproduct’. Wanneer organisaties deze procesinzichten gaan ontwikkelen blijkt vaak dat ‘in de praktijk SAP nog niet optimaal wordt gebruikt’.

Compliance en control hebben vaak een negatieve klank. Belangrijk is om de positieve kant te benadrukken, zodat deze elementen als toegevoegde waarde worden gezien. Eén van de deelnemers gaf als voorbeeld om medewerkers meer verantwoordelijkheden binnen de organisatie te geven als ze hun processen aantoonbaar beter in control hebben. Betere procesbeheersing levert daarnaast betere management- en stuurinformatie op.

De deelnemers denken verschillend over de vraag of de accountant aangehaakt moet worden in dergelijke trajecten. Het proces moet vooral door de organisatie gedragen worden en niet een ‘moetje’ zijn voor de accountant. Aan de andere kant kan de accountant wel gebruikt worden als stok achter de deur om ervoor te zorgen dat het proces voldoende voortgang blijft houden.

Verder kwam de vraag ter sprake waarom SAP BW het concept Continuous Monitoring niet standaard ondersteunt of er eenvoudig aan kan worden toegevoegd. SAP BW wordt echter vooral ingezet voor het weergeven van financiële en geaggregeerde gegevens. SAP BW biedt op dit moment geen standaardfunctionaliteit voor het rapporteren van uitzonderingen in operationele bedrijfsprocessen. SAP heeft wel andere tools beschikbaar voor het monitoren van bedrijfsprocessen. Zo wordt door SAP naast de Governance, Risk en Compliance (GRC) ‘Process Control’ tool, ook de Business Process Monitoring module van SAP Solution Manager aangeboden. Naast SAP bieden ook andere organisaties tools aan voor het monitoren van bedrijfsprocessen.

Slotwoord

Centralisatie van organisaties (onder andere door het opzetten van shared service centers) en centralisatie van ERP-systemen hoeft niet alleen tot kostenbesparing bij de organisaties te leiden, maar kan ook een volgende innovatiestap mogelijk maken van de financiële-auditaanpak.

De enquêteresultaten laten zien dat de volwassenheid van de auditaanpak vaak samenhangt met de mate van centralisatie bij de organisaties. De beschreven ‘Bucket Approach’ laat echter zien, dat de toegevoegde waarde ook reeds kan worden behaald bij organisaties die nog decentraal georiënteerd zijn.

Tijdens de rondetafeldiscussies werd wel duidelijk dat organisaties deze proactieve houding van de accountant verwachten. Uiteindelijk waren alle deelnemers het erover eens dat de nieuwe auditaanpak een gezamenlijke inspanning is door het realiseren van de noodzakelijke veranderingen in de auditaanpak, de SAP-systemen en de organisatie. Pas dan kan de nieuwe aanpak voor de audit én de organisatie leiden tot een toegevoegde waarde.

Praktijkvoorbeeld Data Analytics in de AudIT

De ‘Bucket Approach’ toegelicht

Veel bedrijven streven naar het maximaal automatiseren van hun routinematige processen. De financieel-administratieve afhandeling van in- en verkopen is een voorbeeld van dit soort routinematige processen. Tijdens de financiële controles van deze processen zou dan ook maximaal gebruik moeten kunnen worden gemaakt van de controles die in het proces door IT worden afgedwongen (applicatieve controles) en controles die door IT worden ondersteund (data-analyse).

Data-analyse is een monitoring control, detectief van aard en gericht op alle gegevensverwerking in een bepaalde periode (ook wel bekend als ‘substantive testing’). Deze wijze van analyse geeft volledig inzicht in waar bijzonderheden zijn opgetreden in de operatie, waarbij materialiteit in euro’s bepaalt of additioneel onderzoek gewenst is. De applicatieve controles zijn daarbij randvoorwaardelijk en preventief van aard. Om de kracht van data-analyse te laten zien is hieronder een concreet voorbeeld uitgewerkt voor het inkoopproces.

Fact based auditing van het inkoopproces

Bij het inkoopproces kunnen we verschillende werkstromen onderscheiden, elk met een eigen risicoprofiel. De onderkende risico’s leiden tot controledoelstellingen die voornamelijk zijn gericht op de juiste, tijdige en volledige verwerking van goederenontvangst, ontvangen facturen en verrichte betalingen.

C-2010-1-Veld-04

Figuur 4. Procescontrole binnen het inkoopproces op risicoprofielen per stroom.

Mede door de aanwezige functiescheiding in het proces en de ondersteunende applicatieve controles heeft iedere werkstroom zijn eigen restrisico. Door de werkstroom te combineren met het object van onderzoek (goederenontvangst, factuur en/of betaling) ontstaan ‘bakjes’ met eigen restrisico’s die ieder om hun eigen onderzoek vragen. Deze aanpak wordt binnen KPMG ook wel de ‘Bucket Approach’ genoemd. In figuur 5 zijn aan de hand van een voorbeeldsituatie de ‘Buckets’ en de restrisico’s nader geclassificeerd. De kracht van deze benadering zit in de volledigheid van de evaluatie van alle facturen en alle betalingen. Op deze wijze bestaat er niet alleen aandacht voor de uitzonderingen met materialiteit, maar wordt ook gesteund op de ‘positive assurance’ die uitgaat van een three-way-match en two-way-match afhandeling van het inkoopproces.

C-2010-1-Veld-05

Figuur 5. Procescontrole op basis van data-analyse. [Klik hier voor grotere afbeelding]

In dit voorbeeld wordt bijvoorbeeld negentig procent van de facturen met een waarde van vijftig procent van de gehele inkoopstroom direct ingevoerd en niet gekoppeld aan een order. In deze stroom wordt geen gebruik gemaakt van de kracht van controle op basis van three- of two-way-match. Afgezien van het verhoogde internecontrolerisico is het ook erg arbeidsintensief om al deze facturen handmatig geaccordeerd te krijgen voordat tot betaalbaarstelling wordt overgegaan.

Een andere opmerkelijke ‘Bucket’ is ‘Geblokkeerde facturen’ met een acceptabele eindstand qua materialiteit in euro’s en aantallen. Inkoopfacturen kunnen bij het inboeken in SAP worden geblokkeerd voor betaling indien niet is voldaan aan de ingestelde tolerantielimieten op two- of three-way-match. Bovendien kunnen inkoopfacturen handmatig worden geblokkeerd voor betaling. Nadere studie van de ‘Geblokkeerde facturen’ in dit voorbeeld heeft tot de volgende bevindingen geleid:

C-2010-1-Veld-06

Figuur 6. Inkopen / Crediteuren: two/three-way-match buiten tolerantie (geblokkeerde facturen). [Klik hier voor grotere afbeelding]

  • De tolerantielimieten in SAP zijn ingesteld op een maximale afwijking van één procent en/of € 50 per factuur ten opzichte van de geplaatste order.
  • 844 inkoopfacturen met een referentie naar een inkooporder (en een totale waarde van € 89.908.445) zijn geblokkeerd geweest voor betaling en later alsnog betaalbaar gesteld. In totaal zijn er 4.090 inkoopfacturen met een referentie naar een inkooporder verwerkt, wat impliceert dat 21 procent van de facturen wordt geblokkeerd voor betaling.

De afweging waarmee de organisatie kampt is dat enerzijds de automatische autorisatie van inkoopfacturen kan resulteren in onwenselijke financiële verliezen, maar dat anderzijds door de handmatige goedkeuring van facturen buiten SAP onevenredig inefficiënte verwerking van inkoopfacturen plaatsvindt.

In deze voorbeeldsituatie is het raadzaam te onderzoeken wat de oorzaken zijn van de geblokkeerde facturen en te onderzoeken of het mogelijk is om het aantal geblokkeerde facturen verder terug te brengen, bijvoorbeeld door het tijdig boeken van de goederenontvangst of door het aanpassen van toleranties.

Een andere discussie binnen de jaarrekeningcontrole is de impact van de aanwezige functiescheidingsconflicten. Met data-analyse kan bijvoorbeeld de omvang van functievermenging op inboeken, factureren en vrijgeven van facturen voor betaling worden aangetoond (zie figuur 7).

C-2010-1-Veld-07

Figuur 7. Functiescheidingsconflicten (ook wel Segregation of Duties (SOD)-conflicten genoemd) op inkoopfacturen.

  • Zestien procent van de inkopen (€ 3.284.000) is tot stand gekomen met een functiescheidingsconflict op inboeken van de factuur en het vrijgeven van dezelfde factuur voor betaling.

Door vermenging van beide functies kan een ongewenste autorisatie voor betaling van de factuur zijn gegeven die resulteert in financiële verliezen. De financiële transacties behorende bij de conflicten op functiescheiding dienen op ongewenstheid te worden geëvalueerd. Daarnaast dient in SAP functiescheiding consistent te worden doorgevoerd op het vrijgeven van facturen en het inboeken van de factuur.

Voorgenoemde voorbeelden laten ‘fact based’ zien dat zowel de interne controle als de efficiëntie waarmee de administratie wordt gevoerd, duidelijk verbeterd kan worden.

Deze aanpak leidt tot een efficiënte en heel gerichte centrale aanpak, waarbij tevens veel toegevoegde waarde wordt geleverd in de vorm van concrete procesverbeteringsadviezen. Op deze manier snijdt het mes aan twee kanten.

Literatuur

[KPMG08] Governance, Risk, and Compliance Driving Value through Controls Monitoring, KPMG IT Advisory, 2008.

[KPMG09] Consolideren of Excelleren, ‘Hoe haal ik meer waarde uit mijn SAP-systeem?’, KPMG IT Advisory, december 2009.

Facts to Value

Besluitvorming vindt tegenwoordig meer en meer plaats op basis van een kwantitatief onderbouwde business case, in plaats van kwalitatieve aspecten en aannames. In praktijk zien de auteurs veel waardering voor een fact-based (bottom-up) benadering voor het creëren van inzicht en waarde: Facts to Value. Dataminingtools, tegenwoording beter bekend als Business Intelligence-tools, bieden hiertoe steeds meer mogelijkheden. De sleutel tot succes ligt in het analyseren van data, het combineren van data en het daaruit toegevoegde waarde creëren. Datamining wordt voor steeds meer doeleinden gebruikt, bijvoorbeeld voor het analyseren van het betaalgedrag van debiteuren, koopgedrag van klanten, fraudeanalyses, dubbele betalingen, en procesanalyses. Dit artikel beschrijft een aantal succesvoorbeelden van datamining, en de toegevoegde waarde hiervan.

Inleiding

Datamining is eigenlijk niets nieuws. Het wordt al jaren gebruikt om invulling te geven aan uiteenlopende informatievraagstukken, een mooi voorbeeld hiervan is marktonderzoek. Met de opkomst van dataminingoplossingen, vaak bekend onder de naam Business Intelligence (BI)-oplossingen, is ook het inzetten van datamining door overheid en bedrijfsleven een populair onderwerp geworden. Een eerder gepubliceerd onderzoek van KPMG ([KPMG09]) wijst erop dat het bedrijfsleven het potentiële nut en misschien ook wel de noodzaak van datamining begint in te zien. Toonaangevende systeemleveranciers zoals SAP en ook gespecialiseerde adviesbedrijven bieden steeds meer kant-en-klare oplossingen aan, waarmee bedrijven door middel van plug en play allerlei analyses kunnen maken. Uit voornoemd onderzoek van KPMG blijkt dat ongeveer dertig procent van de onderzochte bedrijven BI-oplossingen gebruikt. Daarnaast is het merendeel van de bedrijven die nog geen Business Intelligence-oplossing gebruiken, van plan een dergelijke oplossing te implementeren binnen drie jaar. Wel valt op dat de volwassenheid van de toepassing van BI nog in de kinderschoenen staat. BI is voornamelijk nog het domein van een paar (IT-) specialisten, en het ontbreekt veelal aan een gestructureerde aanpak.

Het gebruik van ERP-systemen, met een groei naar ‘single instance’, geeft bedrijven toegang tot enorme volumes aan data. Daarmee is een analyse op voornoemde bedrijfsdata uitermate geschikt om inzicht te bieden in hoe bedrijfsprocessen feitelijk verlopen en om de performance te verbeteren. De data kunnen voor meerdere doeleinden worden gebruikt, zoals:

  • het verbeteren van business performance;
  • het verbeteren van de datakwaliteit en -integriteit;
  • het optimaliseren van werkkapitaal;
  • fraudedetectie;
  • het verbeteren van supply chain management en voorraadbeheer;
  • het standaardiseren en optimaliseren van het gebruik van het ERP-systeem;
  • het verbeteren van risk management door het bieden van inzicht in de risico’s die een bedrijf loopt.

Ook de overheid heeft de mogelijkheden van data-analyse ontdekt. Recentelijk is door de staatssecretaris van Onderwijs een brief naar de Tweede Kamer gestuurd waarin zij aangeeft een controle te willen gaan uitvoeren op fraude bij subsidie op kinderopvangkosten. De controle behelst het uitvoeren van een aansluiting tussen twee administraties, de administratie van de belastingdienst en de administratie van het UWV. Door gebruik te maken van datamining kan op een zeer efficiënte en effectieve wijze de informatie worden verkregen die ten behoeve van het uitvoeren van een controle nodig is.

Datamining is daarnaast ook een veelbelovende en efficiënte manier voor bedrijven en auditors om mogelijk ongeautoriseerde transacties, die buiten vooraf gedefinieerde criteria vallen te detecteren, hetgeen in de huidige markt ook wel aangeduid wordt als continuous monitoring / continuous auditing. Hierbij kan gedacht worden aan het overschrijden van kredietlimieten en kortingspercentages bij verkooporders, het niet tijdig uitleveren van orders, en het aantal creditnota’s per dag. Ook auditors beginnen deze mogelijkheden meer en meer te zien en laten in sommige gevallen al software (plug-ins) meelopen in de transactiesystemen van hun klanten of downloaden periodiek data om voor een bepaalde periode de data op onregelmatigheden te detecteren. De auditor verkrijgt hiermee zekerheid voor de jaarrekeningcontrole voor bijvoorbeeld de auditcycles ‘Order to Cash’ en ‘Purchase to Pay’ en de bijbehorende balansposten.

Figuur 1 toont een voorbeeld van een rapportage voor de externe accountant. Uit de rapportage blijkt in hoeverre inkooporders leiden tot goederenontvangst en betaling. Tevens blijken de uitzonderingen en niet-afgeronde inkooporders.

C-2010-1-Toledo-01

Figuur 1. Voorbeeld van een rapportage aan de externe accountant. [Klik hier voor grotere afbeelding]

Succesvoorbeelden in de praktijk

De succesvoorbeelden uit de praktijk betreffen veelal het analyseren van fraudegevallen, procesoptimalisering, ondersteuning aan de jaarrekeningcontrole en working capital-analyses. Achtereenvolgens beschrijven we een casus inzake een analyse werkkapitaal, een jaarrekeningcontrole en een fraudeonderzoek.

Analyse werkkapitaal

In het huidige economische klimaat besteden bedrijven aandacht aan het beheersen van de werkkapitaalpositie. Vaak beheersen bedrijven hun werkkapitaalpositie op basis van cijfers in de managementinformatie-overzichten. Veelvoorkomende kengetallen voor de werkkapitaalpositie zijn:

  • Days Payable Outstanding (DPO): het gewogen gemiddelde van het verschil tussen de feitelijke betalingsdatum en de factuurdatum;
  • Days Inventory Outstanding (DIO): het gewogen gemiddelde tussen de waarde van de voorraad en de omloopsnelheid (gemiddeld dagelijks gebruik) van die voorraad;
  • Days Sales Outstanding (DSO): het gewogen gemiddelde van de feitelijke ontvangst van de betaling en de factuurdatum.

Wat nu de drijvende factoren, ofwel de proces performance indicatoren, zijn die het werkkapitaal beïnvloeden, is vaak onduidelijk door onvoldoende detaillering in de beschikbare managementinformatie. Door gebruik te maken van de beschikbare details in ERP-systemen is het mogelijk deze DPO, DIO en DSO vanuit de systeeminrichting en feitelijke transacties op te bouwen, waarbij voor alle processtappen de relevante elementen worden meegenomen.

C-2010-1-Toledo-02

Figuur 2. Voorbeeld van een grafische weergave van betaalgedrag.

Typische bevindingen bij het uitvoeren van een detailanalyse op werkkapitaal zijn:

  • De feitelijke betaaldatum voor ontvangen facturen wijkt af van afgesproken betalingstermijn en het bedrijfsbeleid inzake betalingstermijnen. Zo worden ontvangen facturen soms, of in enkele gevallen vaak, eerder betaald dan de uiterste betaaldatum en komt het voor dat kortingen voor vroeg betalen niet of niet volledig worden geïnd.
  • Bestellingen vinden plaats zonder dat hiervoor gebruik wordt gemaakt van de voorkeursleveranciers en van de tarieven en betalingstermijnen zoals deze zijn overeengekomen in raamovereenkomsten.
  • De feitelijke ontvangst van betalingen wijkt af van de met de afnemer gemaakte afspraken. Hoewel ERP-systemen vaak de mogelijkheid hebben om een automatische escalatie te doen op facturen die lang openstaan, wordt follow-up van een openstaande factuur in veel gevallen te laat en soms niet opgestart.
  • Aan de frequentie van factureren ligt vaak geen analyse ten grondslag. Met een betalingstermijn van dertig dagen vanaf einde maand, maakt het voor de timing van betaling niet uit of aan het begin of aan het einde van de maand wordt gefactureerd. U kunt zich voorstellen dat bij een betalingstermijn van dertig dagen na levering het belangrijk is om direct bij levering de factuur mee te sturen.
  • Bij het bepalen van aan te houden minimumvoorraden wordt niet of onvoldoende rekening gehouden met karakteristieken van afnemers of leveranciers. De kennis dat een leverancier de neiging heeft om een inkooporder eerder, later of niet volledig af te leveren, wordt bijvoorbeeld niet gebruikt bij het bepalen van de aan te houden minimumvoorraad. Of er worden hoge minimumvoorraden eindproduct aangehouden voor afnemersgroepen met een lage afzet.

Het uitvoeren van deze in eerste instantie technische analyses geeft al de nodige ‘food for thought’. U kunt zich wellicht voorstellen dat het bespreken van deze resultaten met de proceseigenaren en uitvoerenden confronterend kan zijn. Hoe dan ook, het bespreken van de resultaten brengt het resultaat van de analyse verder door oorzaken en concrete verbeteracties te identificeren. Uiteindelijk doel is het werkkapitaal (en de daarbij behorende ‘cash-to-cash cycle time’) te optimaliseren, om daarmee de rentekosten te minimaliseren.

Jaarrekeningcontrole

Inleiding

Door het van kracht worden van de Sarbanes Oxley Act, Tabaksblat, etc., is bij beursgenoteerde bedrijven veel nadruk komen te liggen op interne beheersing. Ook de externe accountant maakt in zijn controleaanpak gebruik van de getroffen interne beheersingsmaatregelen. Niet in de laatste plaats omdat een gegevensgerichte controle vaak hoge kosten met zich meebracht. Een systeemgerichte aanpak kan echter niet altijd worden toegepast vanwege tekortkomingen in de interne controle, waardoor gegevensgerichte werkzaamheden, bijvoorbeeld aanvullende steekproeven, moeten worden uitgevoerd. Hier ligt een enorm besparingspotentieel voor datamining. Door datamining toe te passen op omvangrijke gegevensbestanden opent zich een uitgebreid scala aan mogelijkheden om over de gehele populatie controle-informatie te verkrijgen. In auditjargon wordt dit type controle ook wel aangeduid als Computer Aided Audit Techniques (CAATS). Ter ondersteuning hiervan bestond al een aantal tools, zoals ACL en IDEA. Binnen de accountantscontrole worden deze tools al jarenlang gebruikt door een aantal enthousiaste experts op de kantoren.

Ervaringen tonen aan dat de inzet van CAATS niet altijd succesvol is. Die inzet en de impact op de accountantscontrole is in een eerder Compact-artikel ([Brou07]) beschreven. Enkele observaties ter zake zijn:

  • Uitgevoerde analyses leveren vaak uitgebreide uitzonderingsrapportages (lijstwerk) op.
  • Het afwerken van de uitzonderingsrapportages is tijdsintensief.
  • De relatie tussen de analyses en auditevidence is vaak onduidelijk.
  • Een cost-benefitanalyse voor data-analyse ontbreekt veelal doordat er geen duidelijke relatie met de controleaanpak is.

Ondanks bovenstaande punten is de toegevoegde waarde van CAATS in de jaarrekeningcontrole duidelijk. De vraag is nu hoe meer toegevoegde waarde kan worden gecreëerd. In de afgelopen tijd hebben auditors de nodige ervaring opgedaan in het verbeteren van de effectiviteit van de CAATS-aanpak. De succesvolle audits met behulp van datamining hebben een aantal overeenkomsten. Het betreffen de volgende overeenkomsten:

  • Een duidelijke link tussen de uit te voeren data-analyse met de controleaanpak. Op basis van de controleaanpak kunnen de juiste analyses worden gedefinieerd per auditcycle.
  • Verstrekken van positive assurance in plaats van rapportage van uitzonderingen.
  • Optimaal gebruik van de centralisatie van systemen. De data worden centraal vanuit één locatie getest, waardoor duidelijke efficiencyvoordelen behaald kunnen worden.
  • Hergebruik van ontwikkelde queries in volgende jaren.

De aanpak voor de controle van de jaarrekening met behulp van data-analyse of CAATS is met deze uitgangspunten verder uitgewerkt. Hieronder wordt geïllustreerd hoe deze aanpak werkt voor een organisatie die recent een SAP-systeem wereldwijd heeft geïmplementeerd.

De aanpak in de praktijk

Deze organisatie heeft wereldwijd een ERP-omgeving, waardoor de totale processen van ‘Order to Cash’ en ‘Purchase to Pay’ centraal vanuit Nederland te controleren zijn. Voor de auditor is bij deze organisatie onder meer van belang dat de invoer van verkooporders juist en volledig is, en verder dat alle orders leiden tot een goederenuitgifte. In overleg met de externe accountant zijn vervolgens analyses uitgevoerd op:

  • de invoer van data
    • de invoer van transactiedata en stamtabellen door het testen van parametersettings (invoer en waarschijnlijkheidscontroles);
    • analyseren van wijzigingen van stamdata ten opzichte van voorgaande perioden;
  • de verleende toegangsrechten en functiescheidingen, waarna is onderzocht welke transacties zijn uitgevoerd door medewerkers met te veel rechten;
  • de juistheid en volledigheid van de geld- en goederenstromen; voor de accountants onder ons: ‘de waardenkringloop van Starreveld’.

In figuur 3 is de aanpak schematisch weergegeven.

C-2010-1-Toledo-03

Figuur 3. Schematisch overzicht van de controleaanpak met behulp van dataminingtools. [Klik hier voor grotere afbeelding]

Onderstaand volgen twee voorbeelden van de uitkomsten van de data-analyse.

Ongewenste functievermenging

Een voorbeeld van een uitgevoerde analyse is het gegevensgericht analyseren van de logische toegangsbeveiliging, niet alleen voor het hoofdkantoor maar voor alle divisies. In een aantal gevallen waren de toegangsrechten te ruim ingesteld. Een risico op zich. Echter, door in aanvulling op het beoordelen van de compententietabellen ook een feitelijke analyse van transacties uit te voeren, kon worden vastgesteld dat er slechts in enkele gevallen sprake was van een feitelijk ongewenste functievermenging. Met andere woorden, ondanks dat er een leemte was in de inrichting van de logische toegangsbeveiliging was de impact beperkt. Daarnaast konden de gevonden transacties redelijk eenvoudig worden opgevolgd en was de inspanning beperkt.

Betalingen aan leverancier

Door een analyse op de centrale datawarehouseomgeving kon door middel van datamining de zogenoemde ‘three way match’ (aansluiting van bestelling, goederenontvangst en betaling) worden vastgesteld. Het aantal facturen dat niet automatisch is gematchet met een purchase order en/of goederenontvangst maar uiteindelijk wel betaalbaar is gesteld, is een standaard-exceptielijst. Echter, in deze data-analyse werd ook inzichtelijk wat het aantal ‘goede’ betalingen was. Het exceptielijstje kon op deze manier in perspectief (materialiteit) worden geplaatst. Hoewel er in dit geval opvolging noodzakelijk was is het niet ondenkbaar dat er ook gevallen zijn waarbij de lijst in zijn geheel niet meer materieel (belangrijk om op te volgen) is. Tijdens deze analyse werd een aantal mogelijke dubbele betalingen geconstateerd en afwijkingen in de goederenontvangst door mogelijk onjuiste registratie in het magazijn.

Deze uitzonderingen zijn vervolgens aan de gecontroleerde aangeboden voor opvolging. De organisatie heeft met de externe accountant samengewerkt om de belangrijkste afwijkingen te analyseren en na te gaan of er geen ongeautoriseerde transacties hebben plaatsgevonden.

De rapportage heeft vervolgens conform figuur 1 plaatsgevonden.

Voor de accountant heeft deze aanpak een aantal voordelen met zich meegebracht:

  • De controle kon grotendeels vanuit Nederland plaatsvinden.
  • De data-analyse kon al in de planningsfase worden uitgevoerd, waardoor de risicoanalyse onderbouwd kon worden met feitelijke waarnemingen.
  • De accountant heeft in zijn management letter extra aanbevelingen gedaan met betrekking tot het optimaliseren van de bedrijfsprocessen. Deze aanbevelingen zijn tot stand gekomen op basis van analyses op dezelfde data die gebruikt zijn in het kader van de jaarrekeningcontrole.
  • De gekozen controleaanpak met behulp van data-analyse sluit aan bij de belevingswereld en de IT-ontwikkelingen van de organisatie.
  • De aanpak heeft geleid tot een kwalitatief betere audit (integrale waarnemingen in plaats van steekproeven of deelwaarnemingen).
  • De organisatie heeft op basis van de aanbevelingen in de management letter een omvangrijk verbeteringsprogramma opgezet om zelf een stap te maken in het continu volgen van uitzonderingen (continuous monitoring) en heeft de logische toegangsbeveiliging aangescherpt.
  • De accountant heeft positive assurance gekregen voor een belangrijk deel van de transactiestroom.
  • De accountant heeft tijdens deze controle de in de proposal beloofde efficiencyvoordelen daadwerkelijk gerealiseerd.

Fraudeonderzoek – Gedrukte kortingen

Een uitgeverij geeft een aantal bladen uit. Voor deze organisatie zijn de belangrijkste omzetstromen de opbrengsten uit abonnementen en de opbrengsten van advertenties in bladen. Bij dit bedrijf bestonden geen richtlijnen of andere beheersingsmaatregelen inzake de kortingen die verkoopmedewerkers konden geven aan adverteerders. De verkoopmedewerkers administreerden de kortingen in een maatwerkapplicatie, die gebaseerd is op Oracle. Met betrekking tot de inrichting van voornoemde maatwerkapplicatie had de uitgeverij weinig documentatie of kennis in huis. De accountant werd tijdens de jaarrekeningcontrole geconfronteerd met een gerucht over het toekennen van kortingen aan bevriende adverteerders door verkoopmedewerkers. Ten einde inzicht te krijgen in de aard en omvang van de verstrekte kortingen, besloot de accountant forensische data-analysespecialisten in te zetten.

Door middel van interviews met medewerkers en met de accountant heeft de forensische data-analyse specialist het advertentieproces en de significante risico’s daarin in kaart gebracht. De forensische data-analyse specialist heeft data-analyse ingezet om gegevensgericht vast te stellen of de geïdentificeerde significante risico’s in de praktijk bestonden. Uit de data-analyse bleek dat er meer dan honderd verschillende kortingtypen in de maatwerkapplicatie bestonden, die ook werden gebruikt door de verkoopmedewerkers. Verder bleek uit de data-analyse dat de stroom van creditnota’s zeer omvangrijk was en dat facturen vaak handmatig werden aangepast na de publicatiedatum van de advertentie. Het hierboven genoemde gerucht werd overigens niet onderbouwd door de data-analyse; het bedrag dan wel het kortingspercentage week niet significant af tussen de verschillende verkoopmedewerkers.

De accountant heeft de resultaten van de data-analyse gebruikt als ‘audit evidence’ en om de management letter te schrijven ten aanzien van het ‘Order to Cash’-proces op de advertentieomzetstroom. Naar aanleiding van de bevindingen in de management letter ten aanzien van de advertentieomzetstroom vroeg de uitgeverij de forensische data-analyse specialist om haar te ondersteunen bij het opzetten van een monitoringtool voor voornoemde omzetstroom. De forensische data-analyse specialist heeft voor deze uitgeverij een dashboard gebouwd waarmee door middel van real-time data-analyse de belangrijkste risico’s rond de advertentieomzetstroom gevolgd kunnen worden. De uitgeverij heeft daarnaast naar aanleiding van de bevindingen uit de management letter het aantal kortingtypen in het maatwerksysteem drastisch verminderd. Ook heeft de uitgeverij ‘application controls’ in het maatwerksysteem laten bouwen zodat facturen niet meer handmatig kunnen worden aangepast en creditnota’s dienen te worden geautoriseerd. Alle voornoemde maatregelen hebben tot gevolg gehad dat de opbrengsten uit advertenties met dertig procent zijn gestegen.

Het extractie- en analyseproces

Het definiëren van de analyses gebeurt vaak in een overleg of workshop met verschillende stakeholders, bijvoorbeeld internal audit, proceseigenaren, procesmanagers, externe accountant, enzovoort. De uitkomst van een dergelijke bijeenkomst is vaak een lijst van eisen en wensen die richting geeft aan de data-extractie, de analyse en rapportage.

De dataminingoplossing bestaat uit drie stappen (zie figuur 4):

  • data-extractie (downloads);
  • data-analyse;
  • rapportage en opvolging.

C-2010-1-Toledo-04

Figuur 4. Data-extractieproces. [Klik hier voor grotere afbeelding]

Bij het analyseren van de targetomgeving (core system) dienen de applicatie(s) en database(s) verkend te worden. Daarbij wordt onder meer geïdentificeerd welke tabellen en velden worden gebruikt, in welke valuta bepaalde velden worden weergegeven, en of velden inclusief of exclusief btw zijn.

De data-analyse kan met veel verschillende standaard eindgebruikeroplossingen worden uitgevoerd, van Microsoft Office tot geavanceerde Business Intelligence-oplossingen en monitoringtools. Los van de gekozen technologie zal de gebruiker van de dataminingoplossing de uit te voeren analyses vooraf moeten definiëren en de targetomgeving moeten analyseren. Op basis hiervan wordt een data request gedefinieerd, ofwel een selectie van tabellen en velden die in de data-extractie moeten worden betrokken. Van belang hierbij is dat naast de velden die direct in de rapportage genoemd worden, ook velden nodig zijn om de analyse op te bouwen, bijvoorbeeld factuurnummers of klantnummers, zodat verschillende tabellen aan elkaar kunnen worden gekoppeld.

De data-extractie kan op verschillende manieren plaatsvinden:

  • Het uitvoeren van een SQL-statement op de database. Met SQL-software of een databasemanagementsysteem kan een SQL-statement worden geschreven waarmee direct op de database een selectie wordt gedaan.
  • Het maken van een data-extractie via de applicatie. De meeste applicaties hebben wel een transactie die de mogelijkheid biedt om vanuit de applicatie een data-extractie te doen.
  • Het installeren van speciale software. Diverse softwareleveranciers hebben specifiek voor data-extractie op ERP-systemen speciale software geschreven om het extractieproces te vereenvoudigen.

Elk van deze alternatieven heeft zijn voor- en nadelen. Het is dan ook goed om vooraf te bepalen welke extractiemethode het meest geschikt is per analyse. Een SQL-statement kan heel goed werken bij een eenmalige analyse, werkt vaak snel, maar vergt ook gedetailleerde kennis van SQL-taal en de databaseomgeving. Een data-extractie via de applicatie werkt goed bij een eenmalige analyse, vergt vaak minder kennis van SQL en database, maar de extractie wordt vaak op de voorgrond van de applicatie gestart. Dit kan van invloed zijn op de performance van het systeem, zeker bij grote analyses. Het installeren van speciale software en het gebruik van extractieprofielen bieden een oplossing voor het herhaaldelijk uitvoeren van standaardqueries. De extractie vindt vaak plaats op de achtergrond met lage rechten zodat de performance van het systeem niet wordt beïnvloed.

Na de extractie van data kan worden gestart met het inlezen en analyseren van data. Het vaststellen van de juistheid en volledigheid van de data-extractie en het inlezen van de data is een stap die nog wel eens wordt overgeslagen met als gevolg dat mogelijk met onjuiste of onvolledige data wordt gewerkt. In theorie bestaan er verschillende manieren om de juistheid en volledigheid van de ingelezen data vast te stellen. De meest sterke controle is het aansluiten van een hashtotaal. In de praktijk is een hashtotaal vaak echter niet beschikbaar en dient een aansluiting te worden gemaakt met standaardrapportages, bijvoorbeeld een proef- of saldibalans.

Nadat de queries zijn uitgevoerd op de data van de organisatie kan worden gestart met het analyseren van de data. Hoe goed de voorbereiding is geweest, blijkt al snel bij het uitvoeren van de data-analyse en de validatie van de eerste resultaten. In de analyse worden vaak verbanden gelegd tussen verschillende tabellen en tellingen gemaakt, of waarden gesommeerd. Indien euro’s, Britse ponden en Amerikaanse dollars bij elkaar worden opgeteld, of geen onderscheid gemaakt wordt tussen data-datums in Amerikaanse conventie en Europese conventie, kunnen er onverwachte resultaten uit de analyse komen. Als niet alle sleutelvelden zijn onderkend tijdens de verkenning van het systeem zal het koppelen van verschillende tabellen niet lukken, of tot vreemde resultaten leiden.

De uitdaging is vervolgens om de data zodanig te analyseren en verbanden te leggen dat data informatie worden. Gedegen kennis van de organisatie, systemen en boekingsgangen is een must om tot een goede analyse te komen. Het blijft mensenwerk, en opletten. Een voorbeeld dat het bovenstaande illustreert, is het verhaal van een overijverige assistent die vanuit fraudeperspectief een analyse maakte van alle boekingen op zondag. Dit leverde een enorme waslijst aan boekingen op. De assistent bracht deze naar zijn manager, die vervolgens deze lijsten moest afwerken (aanwijzing van fraude). Wat bleek uiteindelijk? In het weekend draaiden veel batches, die boekingen genereerden. De lijst van de assistent bleek louter uit voornoemde batches te bestaan. Er was dus niets aan de hand.

Inmiddels is er ruime ervaring opgedaan met het presenteren van data. Het management van een organisatie is vaak geconfronteerd met een overload aan informatie, waardoor het moeilijk is om hoofdlijnen van details te onderscheiden. Indien de auditor het management voorziet van een visuele weergave van de resultaten van de data-analyse, zoals grafieken en overzichtelijke tabellen, zijn de hoofdlijnen per definitie goed zichtbaar. Op het moment dat de auditor grafieken presenteert aan het management van bijvoorbeeld de aantallen handmatige boekingen per vestiging, creditfacturen zonder goederenontvangst, goederenuitlevering aan klanten die hun kredietlimiet hebben overschreden, heb je hun aandacht. Er loopt namelijk geld de deur uit. Van de externe accountant vergen deze verstoringen van de geld- en goederenbeweging veel controletijd die gereduceerd kan worden door data-analyse. Door data-analyse toe te passen op voornoemde verstoringen, slaat de auditor dus twee vliegen in één klap.

Het is duidelijk dat iedere belanghebbende een andere behoefte heeft, maar uiteindelijk altijd de feitelijk onderliggende data tot zijn beschikking wil hebben, ofwel een management dashboard met drill-down functionaliteit. Gelukkig is een drill-down functionaliteit tegenwoordig technisch ook mogelijk, maar wordt deze nog niet in alle gevallen toegepast. Een tussenoplossing die de auteurs in praktijk zien zijn drielaagsrapportages: 1) totaal dashboard, 2) weergave per proces en processtap, en ten slotte 3) lijstwerk met details.

Voor een internationale organisatie heeft de auditor de processen bij de verschillende dochtermaatschappijen vergeleken. Management was zich absoluut niet bewust van de verschillen tussen de verschillende dochtermaatschappijen, wat tot interessante discussies heeft geleid. In figuur 5 is een voorbeeld opgenomen hoe de uitkomsten te presenteren aan de bedrijfsleiding van een onderneming.

C-2010-1-Toledo-05

Figuur 5. Voorbeeld voor rapportage aan management en de externe accountant. [Klik hier voor grotere afbeelding]

Lessons learned

De kracht van datamining zit niet alleen in het naar boven halen van data maar ook in het kunnen interpreteren en presenteren van data. De sleutel tot een succesvolle data-analyse:

  • De data-analist heeft grondige kennis van systemen en boekingsgangen bij de klant, en genereert een query waarmee data geanalyseerd worden, die werkelijk van belang zijn.
  • De resultaten worden op een overzichtelijke manier gepresenteerd passend op de informatiebehoefte van de gebruiker.
  • Naadloze samenwerking tussen de persoon die kennis heeft van het systeem, de data-analysespecialist, en de gebruiker, die kennis heeft van auditing en de boekingsgangen bij de klant.
  • De controle van de geïmporteerde data. In de praktijk is enkele malen geconstateerd dat werk was verricht op onvolledige data. Sindsdien behoren uitgebreide validatieslagen tot de standaardwerkwijze.

Samenvatting

De begrippen datamining en data-analyse zijn niet nieuw. Wel nieuw is het inzicht dat de presentatie van de resultaten van data-analyse de sleutel is tot succes.

Data omzetten in toegevoegde waarde, ofwel Facts to Value, zou naar ons oordeel leidend moeten zijn bij het adviseren van klanten op basis van data-analyse. De stand van de techniek en de veelheid aan beschikbare tools brengen veel mogelijkheden met zich mee. Bij het inzetten van deze tools (onder andere voor data-extractie) dient vanuit de klantvraag en klantsystemen gedacht te worden en niet vanuit de tool. Naast de mogelijkheden om organisaties te ondersteunen nemen ook de interesse en de mogelijkheden toe om in de jaarrekeningcontrole data-analyse in te zetten. Data-analyse en datamining brengen in bepaalde klantsituaties voor de accountantscontrole een enorm besparingspotentieel met zich mee door het zelfstandig kunnen vaststellen van de waardenkringloop. Ook is het vaak mogelijk om de systeemgerichte aanpak voort te zetten door met data-analyse de impact van veelvoorkomende tekortkomingen in de logische toegangsbeveiliging vast te stellen.

Literatuur

[Brouw07] Drs. P.P.M.G.G. Brouwers RE RA, mw. B. Beugelaar RE RA en drs. M. Berghuijs, Fact-finding en data-analyse, toepassingen in de praktijk, Compact 2007/3.

[KPMG09] KPMG 2009, Turning Data into Value – A KPMG Survey of Business Intelligence and Data Warehousing, 2009.

Digitaal sporen

KPMG Forensic is gespecialiseerd in het onderzoeken van mogelijke integriteitsschendingen. In dit artikel schetsen de auteurs vanuit hun ervaring hoe en onder welke voorwaarden digitaal materiaal ingezet kan worden in forensische onderzoeken. Daarbij geven ze aan welke voorzorgen in acht genomen moeten worden voor een correcte behandeling van potentieel bewijsmateriaal.

Inleiding

Bijna dagelijks staan op de voorpagina’s van de kranten berichten over fraudegevallen. Zowel (semi-)overheidsorganisaties, banken als andere bedrijven blijken betrokken te zijn bij fraude. Soms in de rol van slachtoffer doordat een eigen medewerker of een leverancier de organisatie benadeeld heeft, in andere gevallen blijken organisaties zelf structureel wet- en regelgeving te ontduiken of bewust onjuiste financiële gegevens naar buiten te brengen. Slechts weinig verbeeldingskracht is nodig om te bedenken dat de zaken die de kranten halen alleen een topje van de ijsberg vormen. Dagelijks worden vele bedrijven en overheden geconfronteerd met integriteitsschendingen zoals fraude maar ook vertrouwelijke informatie die aan derden is doorgespeeld, schendingen van het intellectueel eigendomsrecht of onderzoeken ingesteld door justitie, toezichthouder of mededingingsautoriteit naar eventuele onregelmatigheden.

In veel organisaties die geconfronteerd worden met signalen met betrekking tot dergelijke schendingen slaat de schrik hevig toe. De signalen kunnen vanuit de interne organisatie naar boven komen maar ook via externe partijen zoals een bank, subsidieverstrekker, toezichthouder, openbaar ministerie, accountant of een in- of externe klokkenluider. Van de verantwoordelijke functionarissen binnen een organisatie, meestal directieleden of compliance officers, worden op korte termijn adequate maatregelen verwacht. Daarbij moet een aantal belangrijke beslissingen in een kort tijdsbestek worden genomen om de ontstane ‘crisis’ te managen. Slechts bij een beperkt aantal organisaties ligt hiervoor een draaiboek klaar in de vorm van een ‘fraud risk reaction plan’.

Een adequaat en snel optreden is gewenst maar wordt bemoeilijkt doordat de aard en de omvang van de zaak veelal onduidelijk zullen zijn en de relevante feiten en omstandigheden onbekend. Daarom wordt in veel situaties besloten om een (intern) onderzoek in te stellen dat zo snel mogelijk meer duidelijkheid verschaft. Afhankelijk van de bron van informatie zal een organisatie eerst, voor zover mogelijk, de herkomst en de betrouwbaarheid van de signalen willen verifiëren. Indien de signalen betrouwbaar lijken te zijn dan zal de organisatie snel een beeld willen verkrijgen van de aard en omvang van de mogelijke schending en de betrokken personen of partijen. Op basis van die informatie kunnen vervolgens passende maatregelen worden genomen.

In dit artikel wordt ingegaan op de belangrijke rol die digitale gegevens en informatie over het gebruik van computersystemen in een forensisch onderzoek spelen. De auteurs beschrijven vanuit hun ervaring binnen KPMG Forensic de belangrijkste risico’s rondom het betrekken van digitale gegevens in forensische onderzoeken. Vervolgens gaan zij in op de belangrijkste uitgangspunten voor het gebruik van digitale gegevens in een forensisch onderzoek om de risico’s te mitigeren.

Voorbereiding intern onderzoek

Ondanks het feit dat een snelle reactie zeer gewenst is, is het van groot belang dat in de aanloop naar een dergelijk onderzoek zeer zorgvuldig wordt gehandeld. Daarbij moet in ieder geval rekening worden gehouden met de wettelijke bescherming van de privacy van individuele werknemers. Ook spelen vragen zoals welke medewerkers moeten worden ingelicht (zoals het wel/niet inlichten van de direct leidinggevende) en welke verplichtingen gelden ten aanzien van het inlichten van externe organen zoals justitie of toezichthouders. Tegelijkertijd zal de organisatie veelal acties willen ondernemen om de onregelmatigheden te stoppen en/of de schade te beperken (bijvoorbeeld beslagleggingen of het intrekken van autorisaties). Indien reeds concrete personen in beeld zijn van wie de organisatie het handelen of juist het nalaten daarvan wil onderzoeken, kan gekozen worden voor een persoonsgericht onderzoek.

Bij de grote banken en sommige andere grote organisaties bestaat een eigen afdeling gericht op het onderzoeken van potentiële integriteitsschendingen, veelal gepositioneerd onder de Interne Audit Dienst (IAD). Als een organisatie niet over een dergelijke afdeling beschikt zijn er verschillende gespecialiseerde bedrijven om eventueel in combinatie met een juridische adviseur te ondersteunen bij een onderzoek.

Rol van digitale gegevens

Voor het bepalen van de aard en omvang van de eventuele fraude of andere integriteitsschendingen zal een onderzoek zich in eerste instantie richten op het reconstrueren van de relevante gebeurtenissen. Om die gebeurtenissen in kaart te kunnen brengen zal vaak gestart worden met het achterhalen van relevante documenten en correspondentie zowel op papier als digitaal.

Dit artikel is specifiek gericht op het doen van onderzoek naar digitaal aanwezige gegevens omdat deze vaak een cruciale rol spelen en een speciale aanpak vergen. Het type informatie waarnaar gezocht wordt, kan grofweg worden verdeeld in twee categorieën. De eerste categorie bestaat uit documenten en e-mails waarvan de inhoud inzicht verschaft in de gebeurtenissen (e-discovery). De crux van het digitaal onderzoek is hierbij het selecteren van relevante documenten. De tweede categorie bestaat uit het zoeken naar de aanwezigheid van specifieke sporen in computersystemen (computer forensics). Hierbij gaat het om vragen als ‘Heeft de heer X het vertrouwelijke document abc in zijn bezit?’, ‘Heeft mevrouw Y document abc gekopieerd naar een USB-stick?’ of ‘Door wie is document abc opgesteld?’.

Onderzoeken van digitale gegevens

Als documenten zijn opgeslagen op een algemeen toegankelijke locatie, fysiek of binnen een computersysteem, en niet duidelijk als persoonlijk eigendom gemarkeerd zijn, dan kan een organisatie de inhoud van die documenten zonder veel problemen gebruiken in een forensisch onderzoek. Het ligt echter voor de hand dat de meeste relevante informatie niet op dergelijke openbare plaatsen wordt opgeslagen maar op een afgeschermde locatie.

In hoeverre een organisatie bevoegd is om afgeschermde locaties te doorzoeken hangt af van verschillende factoren. Privé-eigendommen van de werknemer kunnen in ieder geval niet door de werkgever doorzocht worden, daartoe is alleen justitie bevoegd. Het feit dat een tas of een USB-stick wordt aangetroffen op de werklocatie doet daar geen afbreuk aan.

Artikelen die eigendom zijn van de werkgever mogen onder bepaalde voorwaarden wel doorzocht worden mits aantoonbaar is dat de werknemer vooraf van die mogelijkheid op de hoogte is gebracht. In veel organisaties hebben medewerkers een verklaring omtrent het gebruik van IT-middelen ondertekend, daarin is vaak de mogelijkheid opgenomen om bij vermoedens van ontoelaatbare handelingen de computer of andere apparatuur te onderzoeken. Een dergelijke regeling moet overigens worden voorgelegd aan en goedgekeurd door de ondernemingsraad. Als een dergelijke regeling ontbreekt, is het alternatief de betreffende medewerker actief om toestemming te vragen.

Het raadplegen van persoonlijke documenten en correspondentie van een individuele medewerker zal bovendien in verhouding moeten staan tot het onderzoeksdoel (beginsel van proportionaliteit). Het mag verder niet zo zijn dat gewenste informatie ook op een andere, minder belastende, manier te verkrijgen is (beginsel van subsidiariteit).

Als aan de bovenstaande voorwaarden wordt voldaan en geen nodeloze inbreuk op de privacy wordt gedaan, dan is in Nederland een organisatie bevoegd om indien zij daartoe gegronde redenen heeft, de e-mail en andere bestanden van een werknemer te bekijken voor zover deze via een bedrijfsaccount verstuurd of ontvangen zijn. Daarbij mag de privacy niet meer aangetast worden dan noodzakelijk is voor het onderzoek.

Uitvoering onderzoek digitaal materiaal

Het onderzoeken van de digitale gegevens in een organisatie kan zeer relevante informatie opleveren over de mogelijke integriteitsschending. Als een dergelijk onderzoek echter onjuist wordt opgezet, bestaat er een aanzienlijke kans op het aanbrengen van onherstelbare schade. De risico’s bestaan voornamelijk uit de vernietiging of beschadiging van bewijsmateriaal, een zodanige behandeling van bewijsmateriaal dat de authenticiteit niet meer vast te stellen is of het onrechtmatig verkrijgen van bewijsmateriaal waardoor de latere bruikbaarheid in onder andere gerechtelijke procedures op losse schroeven komt te staan.

Een goed en bruikbaar onderzoek naar digitale gegevens zal in ieder geval moeten voldoen aan de onderstaande voorwaarden:

  • informeren van de betrokkenen over het onderzoek;
  • behoud van de integriteit van de digitale gegevens;
  • reproduceerbaarheid van bevindingen;
  • vermijden van disproportionele schending van de privacy van betrokkenen en van derden;
  • toepassing van hoor- en wederhoor;
  • naleving van wet- en regelgeving.

Deze voorwaarden worden hieronder nader toegelicht inclusief een korte beschrijving van de wijze waarop deze in de praktijk vorm worden gegeven.

Informeren betrokkenen

Als een onderzoek wordt uitgevoerd onder de accountantsrichtlijnen en gericht is op het (nalaten van) handelen door specifieke personen, dan dienen de richtlijnen van het persoonsgericht onderzoek aangehouden te worden. Eén van die richtlijnen is het zo spoedig mogelijk informeren van de betrokkenen over het uit te voeren onderzoek. Indien er een zwaarwegend onderzoeksbelang is, kan dit informeren tijdelijk worden uitgesteld. Dit uitstel dient wel zo veel mogelijk beperkt te worden.

Indien een betrokkene geïnformeerd wordt over het onderzoek bestaat de kans dat deze vervolgens belastend materiaal probeert te wijzigen of te verwijderen. Bestaat hierop een reële kans, dan kan onder bepaalde omstandigheden worden besloten om digitale informatie eerst veilig te stellen alvorens de betrokkene op de hoogte te stellen van het onderzoek. Als de informatie wordt veiliggesteld door een exacte kopie (een image) te maken dan hoeft de betrokkene hier niet eerder iets van te merken dan op het moment dat dit door de onderzoekers aan de betrokkene wordt gemeld.

Behouden integriteit gegevens

Moderne computers hebben de vanuit onderzoeksoogpunt lastige eigenschap dat onder invloed van tal van processen die automatisch gestart worden, de opgeslagen gegevens kunnen muteren en geactualiseerd worden. Een deel van die processen gaat al van start zodra het besturingssysteem opgestart wordt. Andere processen zorgen voor wijzigingen in de computer zodra een verbinding met het netwerk of het internet tot stand is gekomen of zodra een applicatie of een document geopend wordt. Herkenbare voorbeelden van dat laatste zijn de laatst geopende documenten in Windows en in Office-applicaties zoals Excel en Word. Theoretisch kan het zelfs zo zijn dat de inhoud van een computer vernietigd wordt zodra een ‘onbevoegde’ toegang probeert te krijgen.

Bij een politieonderzoek direct na een ernstig misdrijf wordt de ‘plaats delict’ onmiddellijk hermetisch afgegrendeld totdat de technische recherche haar werk heeft kunnen doen. Analoog daaraan dienen computers, smartphones en vergelijkbare apparatuur die onderzocht worden in het kader van een fraudeonderzoek zo identiek mogelijk te zijn aan de situatie waarin een betrokkene deze achtergelaten heeft. De eerste stap in de feitelijke uitvoering van een computerforensisch onderzoek is daarom, indien mogelijk, het maken van een volledige en letterlijke kopie van de originele gegevens. Daarbij gaat het vrijwel altijd om minimaal één harde schijf, eventueel aangevuld met een andere gegevensdrager zoals een ISB-stick. Dit proces wordt ‘imagen’ genoemd. Het verschil met een normale kopieeractie is dat (verborgen) systeeminformatie en gewiste bestanden behouden blijven in de image. Indien het origineel niet in de oorspronkelijke staat bewaard kan worden door de onderzoekers, wordt ook een tweede image gemaakt voor het verrichten van de feitelijke onderzoekswerkzaamheden.

Reproduceerbaarheid bevindingen

Indien in een onderzoek belastend materiaal wordt gevonden in de computer van een betrokkene, dan zou deze kunnen beweren dat het niet een originele versie betreft maar een versie die gemanipuleerd is door de onderzoekers of door collega’s.

Tegen een dergelijke bewering is uitsluitend verweer mogelijk als een nieuw onderzoek op basis van (dezelfde) authentieke gegevens tot dezelfde bevindingen leidt. Dit betekent in ieder geval dat vast moet staan waar en onder welke omstandigheden het bewijsmateriaal is aangetroffen en hoe dit bewijsmateriaal vervolgens is behandeld. Daarbij hoort ook een zorgvuldige vastlegging van de verrichte werkzaamheden. Op basis van deze vastlegging moet het mogelijk zijn de werkzaamheden volledig opnieuw uit te voeren waarbij dezelfde bevindingen naar voren komen.

In een computer-forensisch onderzoek zijn er vaak technische hobbels die genomen moeten worden. Het systeem dat door een betrokkene gebruikt is kan niet altijd gebruikt worden voor het onderzoek (bijvoorbeeld een server), waardoor een onderzoeker noodgedwongen een ander systeem zal moeten gebruiken voor het onderzoekswerk. Ook kan een onderzoeker oplopen tegen beveiligingsmaatregelen zoals wachtwoorden of encryptietechnieken waardoor de gegevens niet of moeilijker toegankelijk zijn. Als een organisatie haar ICT uitbesteed heeft, zorgt dit ook vaak voor complicaties, zeker als de digitale gegevens fysiek buiten Nederland worden opgeslagen. Het is belangrijk dat de wijze waarop met de hier genoemde zaken is omgegaan, ook vastgelegd wordt.

Vermijden van disproportionele schending privacy van betrokkenen en derden

Computers bevatten zeer veel informatie waaronder vaak ook heel persoonlijke informatie. Een groot deel van die informatie heeft geen betrekking op het onderzoek. Dit legt een grote verantwoordelijkheid bij de forensische onderzoeker om zich te beperken tot die informatie die relevant is, in het bijzonder als een computer ook bestanden van of over anderen bevat. Hier treedt echter een variant van het de-kip-of-het-ei-verhaal op. De relevantie van een document is pas te beoordelen nadat het document gelezen is. Maar alleen die documenten die relevant zijn mogen gelezen worden.

Op basis van het subsidiariteitsbeginsel is door Asscher en Steenbruggen (1996) de privacypiramide ontwikkeld. Zij hebben de onderstaande hiërarchie opgesteld in de mate waarin het doorzoeken van e-mail de privacy aantast. Met enige aanpassing kan een vergelijkbare indeling bij het doorzoeken van de persoonlijke bestanden van medewerkers worden gehanteerd. De piramide omvat de volgende zes niveaus (van hoog naar laag):

  1. Inhoud
  2. Scan op taal (d.w.z. het invoeren van zoektermen)
  3. Scan op plaatjes (gericht op o.a. het wegfilteren van spam of pornografie)
  4. Onderwerpregel
  5. Attachments
  6. Volume

Op basis van het subsidiariteitsbeginsel zal de onderzoeker moeten zoeken op een zo laag mogelijk niveau in de piramide om de privacy daarmee zo minimaal mogelijk te schaden. Als het volume van het aantal e-mails of de namen van de verzonden attachments voldoende informatie bieden, voor het doel van het onderzoek, is het niet noodzakelijk dat de onderzoeker naar een meer gedetailleerd niveau gaat en daarbij ook kennis van de onderwerpen van de e-mails of zelfs van de inhoud neemt.

Als e-mail en documenten doorzocht worden om de relevante gebeurtenissen in kaart te brengen, zal de onderzoeker zich waarschijnlijk door het ingeven van zoekwoorden op niveau 2 bevinden. In een onderzoek naar het lekken van informatie kan wellicht volstaan worden met zoekacties op niveau 5.

Toepassing van hoor- en wederhoor

Als het onderzoek uitgevoerd wordt als een persoonsgericht onderzoek geldt in ieder geval dat de betrokkene de mogelijkheid moet krijgen om op de inhoud van de bevindingen te reageren. Ook in andere gevallen verdient het aanbeveling om bevindingen door betrokkenen te laten verifiëren.

Hiermee wordt het risico op foutieve bevindingen beperkt. Het is bijvoorbeeld niet onaannemelijk dat in een computer-forensisch onderzoek blijkt dat met de account van gebruiker X bepaalde handelingen zijn verricht. Het is evenwel mogelijk dat zijn wachtwoord bij een collega bekend is en dat niet gebruiker X maar een collega de betreffende handeling heeft verricht. Als de betrokkene niet zelf bevestigt dat hij de handelingen heeft uitgevoerd, dan dient de betreffende handeling niet aan de gebruiker te worden toegeschreven maar aan zijn gebruikersaccount. Zelfs bij het toeschrijven aan een bepaalde account zal bekeken moeten worden of dit het gevolg kan zijn van manipulatie door iemand anders dan de betrokkene.

Naleving van wet- en regelgeving

Gedurende de opzet en de uitvoering van een computer-forensisch onderzoek zijn er nog diverse andere wetten die van toepassing kunnen zijn. Het is onmogelijk om hier een volledig overzicht van te geven maar hieronder volgen enkele aanvullende wetten en regels die bij een computer-forensisch onderzoek een rol kunnen spelen. Een aantal landen kent wetgeving die het uitvoeren van bepaalde gegevens naar het buitenland belemmert. Ook in Nederland is dit van toepassing op sommige financiële gegevens.

Het in bezit hebben van kinderpornografisch materiaal is expliciet strafbaar gesteld in Nederland. Bij het maken van een image worden alle gegevens op een informatiedrager overgenomen zonder dat vooraf bekend is welke gegevens hierop staan. Indien later zou blijken dat een gemaakte image kinderpornografisch materiaal bevat, dan is de onderzoeker feitelijk in het bezit van dat materiaal. In een voorkomend geval zal de onderzoeker daarom dan ook aangifte bij de politie moeten doen en met haar in overleg treden over wat met de gemaakte image moet gebeuren.

Conclusie

In dit artikel is een aantal risico’s beschreven met betrekking tot het onderzoeken van digitale informatie in het kader van een potentiële integriteitsschending. Daarnaast zijn uitgangspunten benoemd waaraan een computer-forensisch onderzoek in ieder geval moet voldoen. Twee specifieke aandachtspunten zijn daarbij van belang. Ten eerste dient het onderzoeksmateriaal technisch correct behandeld te worden en ten tweede dient de onderzoeker zich bewust te zijn van zijn bevoegdheden.

Voor organisaties die beschikken over een eigen afdeling voor het onderzoeken van integriteitsschendingen is het nuttig om medewerkers opgeleid en voorbereid te hebben in het omgaan met digitaal bewijsmateriaal. Indien specifieke en/of specialistische kennis niet aanwezig is om het gehele onderzoek zelfstandig te voltooien is het belangrijk de regiefunctie te behouden en toezicht te hebben op de in dit artikel genoemde aandachtspunten.

Voor organisaties waarbij het onderzoeken van digitale gegevens nog niet is geborgd in de interne regelingen verdient het aanbeveling dit onderwerp te inventariseren en er proactief beleid op te ontwikkelen. Indien een mogelijke integriteitsschending zich openbaart en verschillende informatiebronnen zijn formeel niet bruikbaar voor het onderzoek, dan kan dit de uitkomsten van het onderzoek ernstig schaden.

Literatuur

Mr. L.F. Asscher en mr. W.A.M. Steenbruggen, Het e-mailgeheim op de werkplek, NJB 2001 / 37.

P. van den Heuvel, E-mail op het werk, afstudeerscriptie Universiteit Utrecht, 2002.

Trends in IT internal audit

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

Inleiding

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

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

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

Organisatie en planning

Planningsproces

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

Gebruik van standaardraamwerken

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

C-2010-1-Houwelingen-01

Figuur 1. Gehanteerde raamwerken.

Integratie van IT-audit met andere disciplines

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

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

Goedkeuring auditplan en -rapportage

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

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

C-2010-1-Houwelingen-02

Figuur 2. Rapportering door het IAD.

Teambezetting en vaardigheden

Teambezetting

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

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

Opleiden of werven?

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

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

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

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

Het gebruik van tools

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

C-2010-1-Houwelingen-03

Figuur 3. Toepassingen van tooling.

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

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

Rapportageproces en kwaliteit

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

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

C-2010-1-Houwelingen-04

Figuur 4. Rapportagelijnen.

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

Het meten van kwaliteit

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

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

Ronde tafel Trends in IT Audit

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

Surveybespreking

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

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

Invloed economische crisis

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

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

Dataprivacy

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

Hoe verder?

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

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

Literatuur

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

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

Federated Identity Management, het perspectief van de IT-auditor

Identity & Access Management (IAM) is een vakgebied dat steeds professioneler wordt benaderd in de meeste moderne organisaties. Terwijl de volwassenheid van IAM-strategieën toeneemt, heeft zich een nieuwe grens afgetekend: Federated Identity Management of FIM. FIM definieert de verzameling overeenkomsten, standaarden en technologieën die het mogelijk maken identiteitsgegevens uit te wisselen over autonome domeinen. Naarmate de voordelen van FIM duidelijk worden, neemt de interesse toe in de vraag hoe FIM geïmplementeerd zou moeten worden en wat hierbij de belangrijkste aandachtspunten zijn. Door de belangrijkste aandachtspunten of ‘kenmerken’ van een FIM-implementatie in ogenschouw te nemen kunnen organisaties hun FIM op een betrouwbare wijze inrichten zodat IT-auditors dat op een effectieve wijze kunnen beoordelen.

Inleiding

In een wereld die steeds internationaler wordt, hebben steeds meer organisaties te maken met het immer toenemende tempo waarmee informatie met partners wordt uitgewisseld. Het effectief en efficiënt kunnen samenwerken met leveranciers en klanten, en tegelijkertijd ‘in control’ zijn over de informatiestromen, is één van de critical success factors geworden voor hedendaagse organisaties. Ook het beveiligen van toegang tot informatie is een belangrijk aandachtspunt voor moderne organisaties. Vanuit dit aandachtspunt zijn strategieën ontwikkeld voor het beheer van identiteiten en logische toegangsbeveiliging (Engels: Identity & Access Management, IAM) die van oorsprong gebaseerd zijn op een lokaal en afgeschermd beveiligingsdomein. Door het landschap van informatiebronnen te ‘verdelen’ in lokale domeinen, werd het mogelijk een nauwkeurig gedefinieerde groep gebruikers toegang te verlenen tot een nauwkeurig gedefinieerde groep bronnen. Echter, de toegang tot deze groep bronnen moet in de wereld van nu worden uitgebreid naar externe werknemers of vestigingen, autonome delen van de organisatie, externe partners en veel meer buitenstaanders. Zonder adequate beheersingsmaatregelen is te verwachten dat de risico’s voor veiligheid toenemen. De concepten, technische oplossingen en standaarden zijn inmiddels dermate ontwikkeld dat veilige en gecontroleerde uitwisseling van informatie tussen autonome entiteiten mogelijk is. Onder de noemer Federated Identity Management stelt dit organisaties in staat de toegang van partners tot hun bronnen te beheersen en om de bronnen van die partners te gebruiken.

Terwijl FIM sinds de introductie begin 2000 ([Norl02]) steeds meer wordt toegepast, zien IT-auditors en organisaties zich genoodzaakt een antwoord te vinden op de uitdagingen die dit nieuwe concept met zich meebrengt. Zowel de gebruikers als de organisaties kunnen significante voordelen behalen, gegeven dat de overeenkomstige risico’s adequaat worden beheerst. Dit artikel biedt een high-level handvat door inzicht in de belangrijkste kenmerken van een FIM-implementatie te geven. Deze kenmerken kunnen organisaties helpen bij het implementeren van een betrouwbare FIM-omgeving en IT-auditors bij het uitvoeren van een adequate audit op deze FIM-omgeving. Hierbij benadert dit artikel FIM vanuit het perspectief van de dienstverleners.

Wat is Federated Identity Management?

Beheer van identiteiten

Een identiteit is een ‘representatie van een entiteit in een specifiek applicatiedomein’ ([Jøsa05]). In een typische werkelijke situatie vertegenwoordigen entiteiten gewoonlijk juridische entiteiten (bijvoorbeeld natuurlijke personen of organisaties). Voorbeeld van een identiteit zouden de geregistreerde persoonlijke gegevens van een werknemer kunnen zijn, mogelijk aangevuld met enkele fysieke karakteristieken van die persoon, alle binnen het applicatiedomein van de werkgever. Een identiteit kan ook een systeem representeren. Identiteiten zijn opgemaakt uit een verzameling karakteristieken, identificators genaamd (zoals de accountID, naam en geboortedatum van een persoon). Binnen het beheer van identiteiten (Engels: Identity Management) nemen dienstverleners ofwel serviceproviders een belangrijke positie in. Een serviceprovider is ‘een entiteit die diensten verleent aan andere entiteiten. Voorbeelden van dit soort diensten zijn onder andere internettoegang, aanbieders van mobiele telefonie en hostingbedrijven voor webapplicaties.’ ([Wiki09])

Zoals Jøsang en Pope ([Jøsa05]) beschrijven is het toegestaan een entiteit te koppelen aan nul of meer identiteiten binnen een gegeven domein. Het is bijvoorbeeld mogelijk dat een natuurlijk persoon zowel geregistreerd is als een werknemer van een productiebedrijf, als dat deze persoon klant is van datzelfde bedrijf. Hoewel het noodzakelijk is dat er een unieke identificator bestaat die gebruikt kan worden om de entiteit te herkennen (gedeelde identiteiten mogen niet bestaan als auditability vereist is), is het natuurlijk wel toegestaan dat een entiteit meerdere identiteiten heeft verspreid over meerdere domeinen. FIM biedt de mogelijkheid diensten te verlenen aan een enkele entiteit die meerdere identiteiten kent. Figuur 1 illustreert hoe een entiteit gekoppeld kan zijn aan meerdere identiteiten en hoe iedere identiteit op haar beurt opgemaakt kan zijn uit meerdere unieke of niet-unieke identificators.

C-2010-1-Guensberg-01

Figuur 1. De relatie tussen entiteiten (entities), identiteiten (identities) en identificators (identifiers).

Identity & Access Management

Identity and Access Management (IAM) definieert de processen en technologie voor het creëren, beheren van de levenscyclus (Engels: life cycle management), propageren (Engels: provisioning) en monitoren van digitale identiteitsgegevens teneinde conform het beleid van de organisatie toegang te verlenen tot informatie. Hermans ([Herm05]) definieert IAM als: ‘Het beleid, de processen en de onderliggende technologie voor het effectief en efficiënt beheren en beheersen van wie toegang heeft tot wat binnen een organisatie’. Met andere woorden, IAM definieert wie je bent, beheerst wat je kunt doen en wat niet, en faciliteert het monitoren van compliance en audits op basis van deze informatie; alle binnen de context van het lokale beveiligingsdomein (dus de diensten die in scope zijn verklaard). Merk op dat IAM niet noodzakelijk beperkt is tot informatiesystemen. Integendeel: bijna alle IAM-oplossingen kunnen even gemakkelijk toegang beheersen tot logische als tot fysieke diensten.

Op dit moment zijn er twee overheersende IAM-modellen ([Jøsa05]):

  1. Het model van de geïsoleerde gebruikersidentiteit (momenteel het meestgebruikte IAM-model) vereist dat iedere dienst een identificator en inlogcombinatie (gebruikersnaam en wachtwoord) hanteert voor de gebruikers van die dienst. De serviceprovider beheerst de naamgevingen binnen een lokaal beveiligingsdomein en wijst identificators toe aan gebruikers. Gebruikers zijn aan een unieke identificator gekoppeld (bijvoorbeeld het accountnummer) voor iedere logische of fysieke dienst waarvan zij gebruikmaken. Aparte inlogcombinaties worden gehanteerd voor de unieke identificators. Het voordeel van dit model is dat het een relatief eenvoudige benadering biedt tot IAM omdat het beheer van identiteiten per serviceprovider in de meeste gevallen overzichtelijk is. Het nadeel echter is dat gebruikers zelf moeten bijhouden van welke verschillende diensten zij gebruikmaken en wat de identificators en inlogcombinaties zijn die daarbij horen.
  2. Het model van de gecentraliseerde gebruikersidentiteit maakt gebruik van één aanbieder van identificators en de bijbehorende inlogcombinaties. Deze dienst kan vervolgens gebruikt worden door alle andere dienstverleners in het domein; ofwel als een extra aanbieder van identificators en/of inlogcombinaties, ofwel exclusief door de serviceprovider. Een uitbreiding van het model van de gecentraliseerde gebruikersidentiteit wordt bereikt door een gebruiker die door een vertrouwde serviceprovider is gecontroleerd ook voor andere serviceproviders als geauthenticeerd te beschouwen. Dit wordt gewoonlijk een Single Sign-On (SSO)-oplossing genoemd, omdat de gebruiker zich slechts eenmalig hoeft te authenticeren (één enkele inlogactie is vereist) om alle diensten te gebruiken.

Om het gecentraliseerde model te kunnen gebruiken, is het nodig de informatie over identiteiten onderling te delen in een federatie. FIM, een optionele component in een IAM-raamwerk, maakt dat mogelijk. Federated Identity Management bestaat uit de verzameling overeenkomsten, standaarden en technologieën die het mogelijk maken identiteitsgegevens uit te wisselen over autonome domeinen en op een veilige en beheerste wijze. De volgende onderdelen van een FIM vallen op:

  • Overeenkomsten, standaarden en technologieën. Alhoewel de technische voorzieningen belangrijk zijn, is FIM met nadruk afhankelijk van samenwerking op basis van vertrouwensrelaties.
  • Identiteitsgegevens. De uitwisseling van identiteiten en inlogcombinaties staat samenwerking met partners toe, terwijl de partners ‘in control’ kunnen blijven ten aanzien van de autorisaties en de toegang van gebruikers tot informatie.
  • Over autonome domeinen. Deze domeinen kunnen zich buiten de grenzen van de organisatie bevinden (externe partijen), maar zij kunnen zich ook bevinden binnen de grenzen van de organisatie (bijvoorbeeld in de keten van dienstverlening binnen de organisatie zelf). Implementatie van FIM binnen de organisatie zelf is een recente ontwikkeling die in het bijzonder van belang is binnen overheidsomgevingen (dit wordt in dit artikel verder niet uitgediept).

Federated Identity Management

In een FIM-raamwerk maken overeenkomsten tussen verschillende serviceproviders het mogelijk dat identiteiten die niet door de serviceprovider maar door afzonderlijke identiteitsverleners ofwel identityproviders worden beheerd, worden herkend over alle domeinen die onderdeel zijn van het FIM-raamwerk. Zulke overeenkomsten omvatten het beleid en de standaarden die gebruikt dienen te worden. Een identityprovider is de dienst of organisatie die verantwoordelijk is voor het vaststellen (authenticeren) van de identiteit van een gebruiker ten behoeve van zowel de lokale diensten als de diensten van externe partijen. Een serviceprovider verleent een dienst aan gebruikers en maakt daarbij gebruik van een identityprovider die, namens de serviceprovider, de authenticatie en het verzamelen van gebruikersattributen verzorgt. Hoewel autorisatie niet bij de identityprovider plaatsvindt maar bij de serviceprovider, levert de identityprovider in veel gevallen de voor autorisatie vereiste informatie die door de serviceprovider wordt gebruikt bij het wel of niet verlenen van toegang tot bepaalde informatie.

C-2010-1-Guensberg-02

Figuur 2. Conceptueel overzicht van het FIM-concept en de vertrouwensrelaties tussen gebruiker, identityprovider en serviceprovider.

Figuur 2 toont een conceptueel overzicht van het FIM-concept. De figuur illustreert ook hoe de vertrouwensrelaties zijn opgebouwd tussen de gebruiker en de identityprovider, respectievelijk de identityprovider en de serviceprovider. FIM maakt het mogelijk dat beide vertrouwensrelaties worden getransporteerd naar een vertrouwensrelatie tussen de dienstverlener en de gebruiker. Nadat de gebruiker een bewijs van authenticiteit heeft overgelegd aan de identityprovider, bepaalt de identityprovider dat de gebruiker inderdaad geauthenticeerd is. Vervolgens wordt door de identityprovider een verklaring (Engels: assertion) afgegeven aan de serviceprovider die de informatie uit die verklaring kan gebruiken om de gebruiker verder te autoriseren. De dienst kan vervolgens verleend worden conform afspraak.

Aandachtsgebieden binnen een FIM-omgeving

Organisaties zetten FIM-oplossingen vandaag de dag steeds vaker in voor het op een beheerste wijze uitwisselen van informatie over autonome domeinen. Zo ook wordt steeds meer praktijkervaring opgedaan met de voor- en nadelen van FIM-oplossingen. Op basis van deze ervaring kan een aantal ‘good practices’ worden onderkend. Zoals reeds aangegeven omvat een FIM-omgeving de organisatorische, procesmatige en technologische aspecten. In deze paragraaf zijn de ‘good practices’ per aspect inzichtelijk gemaakt.

Organisatorische kwaliteiten

Een FIM-omgeving heeft idealiter de volgende organisatorische kwaliteiten ([Comp09] [Praa04] [Auth09]):

  • De eerste stap richting FIM is de definitie van de FIM-businesscase. Alleen als er een businesscase is gedefinieerd, zullen de belanghebbenden de mogelijke voor- en nadelen kunnen inschatten en kunnen bepalen wat de kosten zijn die zij bereid zijn te nemen om die voordelen te behalen en de risico’s adequaat te beheersen. De betrokken organisaties moeten tot de conclusie komen dat het loont om samen te werken, waarna zij de obstakels één voor één in overleg moeten adresseren. Aansprakelijkheid moet duidelijk gedefinieerd zijn in overeenkomsten tussen de federatiepartners, inclusief aansprakelijkheidslimieten als gevolg van veiligheidsincidenten, fouten, etc.
  • Er moet een solide vertrouwensbasis bestaan die wordt ondersteund door ondubbelzinnige toewijzing van rollen en verantwoordelijkheden (bijvoorbeeld in een RACI-matrix). De partijen in de federatie moeten audits toestaan van hun respectievelijke FIM-domeinen op basis van vooraf afgesproken beheersingsmaatregelen en uniforme auditprocedures. Net zoals dat bij outsourcing gebeurt, kunnen SAS 70-rapporten of Third-Party Mededelingen (TPM’s) worden gebruikt om de vertrouwensrelatie te waarborgen. Eigenaarschap van processen en objecten moet duidelijk gedefinieerd zijn en door de federatiepartners worden onderschreven.
  • Het is belangrijk dat er een beveiligingsraamwerk bestaat om de high-level beveiligingsvereisten te definiëren waar gebruikers en beheerders aan moeten voldoen. Een FIM-beveiligingsbeleid is idealiter onderdeel van het generieke (informatie)beveiligingsbeleid van de organisatie. Het beleidsdocument moet op basis van de ontwikkelingen in IT worden bijgehouden en van toepassing zijn op de federatie en de federatiepartners. Het stimuleert het verbeteren van de bekendheid met het beleid zelf (awareness) en beschrijft de vereisten voor het voldoen aan de wet- en regelgeving die van toepassing zijn binnen de federatie. Beveiligingsproblemen in de federatie kunnen de risico’s van fraude, (identiteits)diefstal en interpretatiefouten doen toenemen als partijen foutieve informatie aan elkaar doorgeven en op die informatie vertrouwen.
  • Problemen in het partnerschap kunnen alleen voorkomen worden als de organisaties investeren in het ondubbelzinnig vastleggen van rollen en verantwoordelijkheden in gemeenschappelijk geaccordeerde en geaccepteerde overeenkomsten. Dergelijke overeenkomsten bevatten afspraken die bepalen wie wat mag of moet doen, wie waarvoor betaalt en wie waarvan profiteert. Overeenkomsten moeten op zijn minst adresseren wat het bereik is van het vertrouwde domein (de overkoepelende doelstellingen, belanghebbenden, procesvereisten per partner), wat de expliciete overeenkomsten zijn voor auditing en op welke wijze de afspraken gewijzigd kunnen worden (meta-overeenkomsten).
  • De FIM-omgeving moet voldoen aan de relevante in- en externe privacywet- en regelgeving. Idealiter ligt de controle over het gebruik van eigen gegevens bij de gebruiker zelf.
  • Toewijding van het management moet waarborgen dat de beveiliging van FIM adequaat wordt geadresseerd in het FIM-businessplan en dat overeenstemming wordt bereikt over de toewijzingen van taken en verantwoordelijkheden in FIM-beveiliging. Dit geldt voor de organisatorische, procesmatige en technologische beheersingsmaatregelen en de wijze waarop FIM-beveiligingsinitiatieven worden ondersteund.

Procesmatige kwaliteiten

Een FIM-omgeving heeft idealiter de volgende procesmatige kwaliteiten ([Praa04]):

  • Gebruikers moeten uniek identificeerbaar zijn binnen de federatie om auditability van gebruikersactiviteit te kunnen waarborgen. De levenscyclus van de gebruiker moet conform afgesproken tijdigheid in de identity repository worden gereflecteerd, inclusief het deactiveren of verwijderen van identificators als een gebruiker definitief of tijdelijk uit dienst gaat.
  • Adequate maatregelen moeten waarborgen dat de sterkte van authenticatie binnen de federatie geïmplementeerd is conform de afspraken die daarover bestaan; alle partners hanteren een equivalent wachtwoordbeleid dat ten minste het volgende omvat: wachtwoordcomplexiteit en update regels, lockout na herhaaldelijk foutief inloggen en beveiligde opslag van wachtwoorden. Gemeenschappelijke overeenkomsten moeten bestaan zodat ondubbelzinnige classificatie van authenticatievereisten en -maatregelen wordt bereikt, inclusief de diensten die mogen worden verleend op basis van een bepaald authenticatieniveau van de gebruiker. Auditing van de authenticatiemiddelen moet zodanig frequent plaatsvinden dat technologische ontwikkelingen worden gereflecteerd in de sterkte van de gebruikte middelen. Audits moeten ten minste gericht zijn op het productieproces, de aanvraagprocedure, het uitgifteproces en het beheer van de authenticatiemiddelen die de partners gebruiken.
  • De functionaris die verantwoordelijk is voor het aanmaken, wijzigen en intrekken van autorisaties moet alle autorisaties documenteren die direct of indirect (bijvoorbeeld via rollen) aan gebruikers zijn toegewezen in een autorisatiematrix of vergelijkbare administratie. Procedures moeten bestaan om de administratieve processen rondom het aanmaken, wijzigen en verwijderen van autorisaties te beheersen inclusief vereiste accordering. De autorisatiematrix (SOLL) moet periodiek worden vergeleken met de werkelijke autorisaties (IST) in een representatieve steekproef van de beschikbare diensten. Het resultaat daarvan dient periodiek door het hogere management te worden geaccordeerd.
  • Op basis van een risicoanalyse moeten gevoelige wijzigingen in de identificatie- en authenticatiegegevens worden gemonitord en opgeslagen (bijvoorbeeld het aanmaken, uitlezen, wijzigen of verwijderen van gebruikers met bijzondere rechten). De monitoringinstellingen moeten periodiek gecontroleerd worden door het management van de informatiebeveiligingsafdeling. Monitoringrapportages moeten op een beveiligde locatie worden opgeslagen welke het onmogelijk maakt voor ongeautoriseerde gebruikers om deze rapportages aan te passen. Verantwoordelijkheden moeten zijn toegewezen voor het controleren van monitoringalarmsignalen en -rapportages, en voor het nemen van adequate actie in geval aan de daarvoor gedefinieerde condities wordt voldaan (als bijvoorbeeld sprake is van een daadwerkelijke inbraak).
  • In federaties hebben de partners relatief veel controle over de verleende toegang tot de objecten van de auditee. Wegens de belangrijke functie van monitoring en audit bij het bereiken en handhaven van de wederzijdse vertrouwensrelatie, die voor een goed functionerende federatie vereist is, moeten er periodiek onafhankelijke audits plaatsvinden. Deze audits moeten worden uitgevoerd conform de daarover door middel van de FIM-overeenkomst gemaakte afspraken. Auditing biedt de mogelijkheid voor federatiepartners om de kwaliteit te controleren van de toegangsprocessen van hun gelijken. Dit is essentieel voor het bereiken van het vertrouwen dat de partners hun medewerking verlenen aan dergelijke audits. De IT-auditor dient bij het beoordelen van de federatie rekening te houden met de (on)volwassenheid van de federatiepartners en eventuele compenserende maatregelen.
  • Adequate functiescheiding (Engels: Segregation of Duties, SoD) moet bestaan om te voorkomen dat gebruikers waarde aan de organisatie kunnen onttrekken zonder dat dit wordt opgemerkt. Op basis van een risicoanalyse moet worden voorkomen dat bijzondere rechten als gevolg van onbedoelde combinaties in de verdeling van rechten een beveiligingsrisico opleveren. De functionaris die verantwoordelijk is voor het aanmaken, wijzigen en intrekken van autorisaties mag niet in staat zijn aanpassingen te doen zonder dat het management daarvan voor- of achteraf op de hoogte wordt gesteld.

Technologische kwaliteiten

Een FIM-omgeving heeft idealiter de volgende technologische kwaliteiten ([Kuip08] [Blak08] [Davi07] [Ping09]):

  • Een federatie zou moeten bestaan uit partijen die zo los mogelijk verbonden zijn (Engels: loosely coupled): actueel decentraal beheer van identiteiten verdient de voorkeur boven gedeelde verouderde identity repositories. Het gebruik van gemeenschappelijk afgesproken technologie is cruciaal voor het bereiken van FIM, maar de uitwisselbaarheid van de door de IAM-tooling geboden functionaliteit is dat evenzeer.
  • Omdat standaardisatie van technologie essentieel is voor federaties, moet de auditee continu de laatst beschikbare technologische standaarden blijven overwegen, zoals SAML 2.0 (identiteitsattributen), XACML (interpretatie van uitgewisselde (SAML-) gegevens), SPML (uitwisseling van gebruiker, object en service-provisioninginformatie) en SOAP (transport van op XML gebaseerde berichten). Hoewel het voorbereid zijn op meerdere standaarden de interoperabiliteit van een organisatie zal vergroten, zullen de kosten en complexiteit waarschijnlijk ook toenemen.
  • Er moet een technische federatieovereenkomst gehanteerd worden, waarin ten minste het volgende is gedefinieerd: gebruik, opslag en definitie van identiteitsattributen, de gebruikte risiconiveaus, sterkte van authenticatie en toegestane identityproviders per dienst, het verwerken van autorisaties door de serviceprovider (bijvoorbeeld individuele versus functionele accounts), vereisten aan de veiligheid van opgeslagen, verwerkte of verzonden gegevens, de te gebruiken standaarden en de vereisten aan certificering van alle partners (bijvoorbeeld het gebruik van PKI of een vergelijkbaar mechanisme voor veilige communicatie).
  • Er moet een gemeenschappelijk change-managementbeleid inzake FIM worden gebruikt door alle partners in de federatie, waarin ten minste het volgende wordt geadresseerd: de documentatie, autorisatie en uitvoering van (nood)wijzigingen, het proces van testen en aftekenen inclusief testdocumentatie en het scheiden van ontwikkel-, test-, acceptatie- en productieomgevingen inclusief eventuele uitzonderingsprocedures voor directe wijzigingen in de productieomgeving.
  • Er moet een definitie zijn van voor de federatie gekozen topologie. Mogelijke federatietopologieën zijn: point-to-point (ofwel: ‘één-op-één’), mesh (ofwel: ‘verbonden’), star (ofwel: ‘as en spaak’) en gecentraliseerd. Hoewel partnerships in een federatie gewoonlijk niet op een hiërarchische wijze zijn opgebouwd, is een verzameling van federaties (een confederatie) dat vaak wel.
  • Er moet een definitie zijn van de voor de federatie gekozen implementatie. Mogelijke implementatieopties zijn: proprietary (het ontwikkelen van een eigen oplossing), open source, een op standaarden gebaseerde federatieserver of uitbreiding van een bestaande IAM-suite.

FIM is gebaseerd op gedeeld vertrouwen, niet noodzakelijkerwijs op gedeelde technologieën. De FIM-technologieën hebben een ondersteunende functie ten opzichte van de vertrouwensrelatie in de federatie.

Conclusies en slotnotitie

Dit artikel laat zien dat het concept van FIM een waardevolle oplossing kan bieden voor een scala aan uitdagingen voor moderne organisaties die op een beheerste wijze informatie willen delen met externe partners buiten hun beveiligingsdomein. De volgende conclusies kunnen worden getrokken uit het in dit artikel gepresenteerde onderzoek.

De stand van zaken

Wat betekent FIM voor moderne organisaties? Wordt het gebruikt? Hoe?

Het concept van FIM heeft op dit moment een behoorlijk definitief stadium bereikt en het samensmelten van standaarden heeft met SAML 2.0 plaatsgevonden. De businesscase voor federatie wordt in toenemende mate gebaseerd op gebruikersgemak, efficiency en effectiviteit, doordat de externe processen van organisaties duidelijk ondersteund worden door deelname aan een federatie.

Voorbeelden van FIM-implementaties zijn momenteel gemakkelijker te vinden in de onderwijs- en overheidsomgevingen dan in de commerciële bedrijfsmatige omgeving. Volwassenheid zou een voorwaarde kunnen worden als de organisaties betrokken zijn in fusies en overnames; niet alleen de volwassenheid van FIM zal in dat geval een rol spelen, ook de algemene IAM-volwassenheid van de andere partijen.

De meeste auditkantoren bemerken een langzame toename van FIM-gerelateerde opdrachten in het internationale speelveld. Het nadeel van de eerste oplossingen voor logische identificatie was vaak dat de hele ‘portemonnee’ moest worden gepresenteerd, waardoor de serviceprovider irrelevante attributen moest verwerken en de gebruiker zich onnodig gedwongen zag persoonlijke informatie kenbaar te maken. FIM biedt hier in potentie oplossingen voor. Het IAM-onderzoek dat in 2008 door KPMG is uitgevoerd, vermeldt ([KPMG08]): ‘In de meeste organisaties van de respondenten zijn IAM-projecten gericht op het beheer en beheersen van toegang door werknemers en externen tot interne systemen en informatie. Federated Identity Management, de grensoverschrijdende verbinding van IAM-omgevingen, wordt in de meerderheid van de organisaties van respondenten nog niet in brede zin gebruikt.’

In tegenstelling tot de meeste bedrijven is de overheid een organisatie die bestaat uit een groot aantal redelijk autonome suborganisaties. De IT-omgevingen van de overheid bevatten tegelijkertijd een groot aantal legacy systemen en state-of-the-arttechnologie zoals webportals op het intranet en, in toenemende mate, ook op het internet. De overheid ziet in dat er een behoefte zal bestaan aan samenwerking via FIM als de decentrale IAM-initiatieven volwassen zijn geworden.

Auditaandachtspunten

Wat zijn de belangrijkste aandachtspunten voor de IT-auditor en auditee in FIM-gerelateerde audits?

De belangrijkste aandachtspunten voor de IT-auditor en auditee betrokken bij FIM-audits zijn afgeleid van de eerder beschreven good practices rondom FIM. De aandachtspunten kunnen gegroepeerd worden in clusters die betrekking hebben op de organisatie, processen en technologie van een organisatie.

De belangrijkste FIM-auditaandachtspunten voor een beoordeling van de organisatie hebben te maken met de vertrouwensrelatie en het gegeven dat deze door een heldere businesscase moet worden ondersteund, met de wederzijds aangenomen en gehandhaafde beveiligingsraamwerken en met de toewijzing van verantwoordelijkheden en betrokkenheid van het management. FIM-overeenkomsten moeten bestaan en compliance met de relevante in- en externe wet- en regelgevingen moet worden bewaakt (bijvoorbeeld door de eindgebruiker de controle te laten voeren over eigen gegevens). Commitment van het management zorgt ervoor dat de beveiliging van FIM voldoende wordt geadresseerd.

De belangrijkste FIM-auditaandachtspunten voor een beoordeling van de processen hebben te maken met de unieke identificatie van gebruikers en de eenduidige implementatie van de authenticatie- en autorisatieprocessen. Auditen van de authenticatiemiddelen en IST/SOLL-vergelijkingen moeten op voldoende regelmatige basis plaatsvinden en worden opgevolgd. Wijzigingen in de identificatie en authenticatiegegevens moeten worden gemonitord en adequate functiescheiding moet van kracht zijn.

De belangrijkste FIM-auditaandachtspunten voor een beoordeling van de technologie hebben te maken met het los verbinden van federatiepartners (loose coupling) en het gebruik van passende technologische standaarden. Een technische federatieovereenkomst moet bestaan, evenals een change-managementbeleid inzake FIM en een definitie van de federatietopologie en de gekozen aanpak voor implementatie.

FIM-gerelateerde audits moeten, zo nodig periodiek, plaatsvinden op basis van een vooraf gedefinieerde frequentie. Auditinspanningen moeten altijd worden ontplooid op basis van een risicoanalyse om de juiste inzet van middelen te bepalen.

De belangrijkste kwaliteiten van een FIM-raamwerk

Dit artikel biedt een praktisch high-level handvat voor zowel de organisaties die hun FIM-raamwerken geaudit weten als de IT-auditors die een dergelijke audit uitvoeren.

Een goed FIM-ontwerp en een goede FIM-implementatie kunnen door de auditee worden bereikt door de hier volgende kwaliteiten te waarborgen. Overeenkomstig hiermee zou een IT-auditor de volgende belangrijkste aandachtspunten in een FIM-audit moeten betrekken om tot een gedegen audit te komen.

  • Een FIM-omgeving heeft idealiter de volgende organisatorische kwaliteiten:
    • De FIM-businesscase is helder gedefinieerd voorafgaand aan implementatie.
    • Er bestaat een solide vertrouwensrelatie tussen de federatiepartners.
    • Er is een beveiligingsraamwerk van kracht om de high-level vereisten aan beveiliging te beheersen.
    • De federatiepartners hebben op ondubbelzinnige wijze de vereiste rollen en verantwoordelijkheden vastgelegd in wederzijds geaccordeerde en aangenomen overeenkomsten.
    • De auditee voldoet aan de relevante in- en externe (privacy) wet- en regelgeving. Idealiter heeft de gebruiker zelf de controle over de informatie die over hem of haar wordt gebruikt.
    • Betrokkenheid van het management waarborgt een adequate aanpak voor FIM-beveiliging.
  • Een FIM-omgeving heeft idealiter de volgende procesmatige kwaliteiten:
    • Gebruikers zijn overal in de federatie altijd uniek identificeerbaar.
    • Sterkte van authenticatie is op eenduidige wijze geïmplementeerd in de federatie.
    • De autorisatiematrix (SOLL) wordt periodiek vergeleken met de werkelijke autorisaties (IST).
    • Wijzigingen in gevoelige identificatie- en authenticatiegegevens worden gemonitord en opgeslagen.
    • Er vinden periodieke onafhankelijke audits plaats.
    • Er bestaat adequate functiescheiding.
  • Een FIM-omgeving heeft idealiter de volgende technologische kwaliteiten:
    • De federatie bestaat uit partijen die zo los mogelijk verbonden zijn (loose coupling).
    • De laatst beschikbare technologische standaarden worden gebruikt.
    • Een technische federatieovereenkomst wordt gehanteerd.
    • Er is een gemeenschappelijk change-managementbeleid inzake FIM aangenomen door de federatiepartners.
    • De federatietopologie is gedefinieerd.
    • De gekozen federatie-implementatie is gedefinieerd.

Merk op dat zowel het adresseren van de belangrijkste kwaliteiten door de auditee als de beoordeling daarvan door de IT-auditor zou moeten plaatsvinden op basis van een voorafgaande risicoanalyse en een afweging van de voor- en nadelen van de kwaliteiten.

Slotnotitie

Hoewel FIM slechts gericht is op een beperkt onderdeel van de complete uitdaging, namelijk de uitwisseling van identiteitsgegevens tussen autonome domeinen, zijn de mogelijkheden op zijn minst veelbelovend te noemen. Echter, voordat organisaties FIM gaan implementeren zouden zij de in dit artikel genoemde belangrijkste kwaliteiten in ogenschouw moeten nemen. Hierbij kunnen de hier gepresenteerde high-level handvatten worden uitgewerkt naar de specifieke situatie van de auditee; concepten zoals ‘voldoende frequent’ worden dan vertaald naar een concrete meetbare indicator.

[Auth09] http://www.authenticationworld.com/Authentication-Federation/CreatingAFederatedAuthenticationTrust.pdf (laatst bezocht september 2009).

[Blak08] Bob Blakley, Dan Blum en Gerry Gebel, Federated Identity – Reference Architecture Technical Position, Burton Group, 2008.

[Comp09] http://www.computerworld.com.au/index.php/id;162794021;fp;2;fpid;2 (laatst bezocht september 2009).

[Davi07] Claire Davies en Matt Shreeve, Federated access management: international aspects, Curtis+Cartwright Consulting Limited, 7 juni 2007.

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

[Jøsa05] A. Jøsang en S. Pope, User-Centric Identity Management, Proceedings of AusCERT mei 2005, Brisbane, Australia.

[KPMG08] KPMG, 2008 European Identity & Access Management Survey, KPMG, 2008.

[Kuip08] Jaap Kuipers, eID Convergence challenges (slide 8), SURFnet/ECP.NL, 2008.

[Norl02] Eric Norlin en Andre Durand, Federated Identity Management, Whitepaper, PingID Network, 2002.

[Ping09] http://www.pingidentity.com/information-library/Federated-Identity-Management-Tutorial.cfm (laatst bezocht september 2009).

[Praa04] Jan van Praat en Hans Suerink, Inleiding EDP-auditing, Ten Hagen & Stam uitgevers, 2004.

[Wiki09] http://en.wikipedia.org/wiki/Service_provider (laatst bezocht september 2009).

Onlinebronnen

Ten slotte wordt hier een aantal websites opgesomd die aanknopingspunten vormen voor vervolgonderzoek en praktische toepassing van de theoretische concepten uit dit artikel:

  • http://openid.net/what/ – Deze website presenteert het OpenID-concept dat besproken wordt in dit artikel en dat een lezer een eerste aanraking biedt met de mogelijke voordelen van deze techniek.
  • http://www.inames.net/ – Deze website presenteert het i-name-concept van identificators die voor mensen gemakkelijk te onthouden zijn. Ze zijn ontworpen om het probleem van permanente adressering op te lossen; hoe kan een onlineadres worden gecreëerd dat niet onderhouden hoeft te worden en dat nooit verandert ongeacht hoe vaak de contactgegevens van de eigenaar veranderen.
  • http://identity20.com/media/OSCON2005/ – Dick Hardt’s OSCON 2005 Keynote getiteld Identity 2.0: dit is een inspirerende en dynamische introductie van Identity 2.0 en laat zien hoe het concept van digitale identiteiten zich aan het ontwikkelen is.
  • http://www.identityblog.com/?p=352 – Kim Cameron’s whitepaper getiteld The Laws of Identity: een verzameling ‘wetten’ die zouden moeten gelden voor de personen die werken met identiteiten. Door deze wetten te respecteren, zo beargumenteert Cameron, is het mogelijk een verenigd systeem te creëren dat universeel geaccepteerd wordt en duurzaam is.

Geslaagd GRC binnen handbereik

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

Inleiding

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

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

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

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

C-2010-1-Beugelaar-01

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

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

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

Het belang van geslaagd GRC

De wildgroei

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

C-2010-1-Beugelaar-t01

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

Het belang

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

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

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

C-2010-1-Beugelaar-02

Figuur 2. Componenten van beheersingskosten.

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

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

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

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

Een aanpak tot succesvolle uitrol van GRC

Een visie op geïntegreerd GRC

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

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

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

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

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

C-2010-1-Beugelaar-03

Figuur 3. KPMG’s holistisch GRC-model.

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

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

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

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

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

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

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

GRC en COSO-ERM

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

C-2010-1-Beugelaar-04

Figuur 4. COSO-ERM-framework.

De complexiteit van het inrichten van GRC

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

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

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

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

De GRC-scan

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

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

De GRC-scan beantwoordt op hoofdlijnen de volgende vragen:

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

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

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

Deze activiteitengroepen betreffen:

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

C-2010-1-Beugelaar-05

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

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

C-2010-1-Beugelaar-06

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

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

C-2010-1-Beugelaar-07

Figuur 7. Prioritymatrix voor GRC.

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

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

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

Praktijkcasus

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

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

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

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

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

Conclusie

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

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

Literatuur

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

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

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

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

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

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

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

SAS 70 herzien, focus ISAE 3402 blijft op beheersingsmaatregelen financiële verantwoording

Inmiddels is het bij velen bekend dat de SAS 70 huidige standaard ingrijpend zou worden gewijzigd, waarmee er naar verwachting andere (en meer) mogelijkheden zouden komen om zekerheid te geven bij diverse verantwoordingen op het gebied van interne beheersing, ten behoeve van derden. Deze nieuwe standaard, de ISAE 3402 ‘Assurance Reports on Controls at a Service Organization’, is per september 2009 geaccepteerd door de regelgevende instanties, maar of de wijzigingen inderdaad zo groot zijn, valt te bezien. Op de verschillen met en de impact van deze nieuwe standaard op de praktijk wordt nader ingegaan in het artikel.[De auteurs bedanken de heren Han Boer en Ronald van Langen van KPMG voor hun commentaar op een eerdere versie van dit artikel.]

Inleiding

Serviceproviders die thans gebruikmaken van SAS 70-rapportages krijgen vanaf medio 2011 te maken met een overgang naar een nieuwe standaard voor rapportage over interne beheersing ten behoeve van derden. Deze nieuwe standaard – op basis van de nu geratificeerde ISAE 3402-standaard – zal in de praktijk de huidige SAS 70-standaard vervangen en krijgt daarmee een internationale basis, gedragen door het IFAC (International Federation of Accountants) en de ASB (Auditing Standards Board, US). In Nederland zal deze standaard worden opgenomen in de COS-standaarden. De US-uitwerking zal naar verwachting niet veel verschillen van de IFAC-standaard. De vraag is in hoeverre deze nieuwe standaard inhoudelijk afwijkt van de SAS 70-standaard en wat dit betekent voor de serviceproviders. Zijn er aanpassingen noodzakelijk in en wat zijn de beperkingen en uitdagingen van de nieuwe standaard? Wat zijn alternatieven indien de ISAE 3402 op onderdelen niet voldoet aan de behoeften van de gebruikers?

Tijdtabel invoering nieuwe standaard

De voorgestelde ingangsdatum voor de nieuwe standaard is voor rapportageperioden eindigend na medio 2011 (over de definitieve datum moet nog worden besloten). Aangezien service-auditorrapportages over perioden kunnen gaan van tussen de zes en twaalf maanden, mogen service-auditors gebruikmaken van de nieuwe standaard vanaf het tweede kwartaal van 2010. De IAASB en daarmee de ASB zal early adaption van de nieuw standaard toestaan, zodat we dus rapportages mogen verwachten onder de nieuwe standaard vanaf de tweede helft van 2010.

Achtergrond internationale standaard

Tal van serviceproviders geven met een SAS 70-rapport (Statement on Auditing Standards No. 70) inzicht in hoe zij hun processen intern beheersen. SAS 70 is al jaren dé standaard voor het rapporteren over het internal control framework van een serviceorganisatie.[Officieel bestaat SAS 70 al geruime tijd niet meer: de werkelijk van toepassing zijnde standaard (nu feitelijk de regelgeving) is de AU 324 (Professional Standards, vol. I, AU SEC 324). Toch spreekt men niet over AU 324, omdat de term SAS 70 inmiddels is ingeburgerd.] Hoewel deze standaard specifiek bedoeld is om te rapporteren over interne beheersingsmaatregelen van een serviceorganisatie voor zover van belang bij de jaarrekeningcontrole van een gebruikersorganisatie, zien we in de praktijk dat de standaard breder wordt toegepast en eigenlijk verder gaat dan dat SAS 70 aan mogelijkheden biedt.

Wegens het gebrek aan één wereldwijde standaard hebben diverse landen reeds op basis van de standaarden die ten grondslag hebben gelegen aan ISAE 3000 hun eigen standaarden ontwikkeld (zie tabel 1) ([Bell09]).

C-2010-1-Beek2-t01

Tabel 1. Landspecifieke en wereldwijde standaarden voor internecontrolerapportages.

De International Auditing and Assurance Standards Board (IAASB) wilde graag toe naar één wereldwijde standaard voor de rapportering over beheersingsprocessen als onderdeel van uitbestede processen. IAASB heeft een nieuwe standaard ontwikkeld, te weten de International Standard on Assurance Engagements (ISAE) 3402. Betrokkenen konden tot mei 2008 reageren op de eerste concepttekst[De reacties zijn te vinden op: http://www.ifac.org/IAASB/ExposureDrafts.php.] en de IAASB publiceerde vervolgens in juni 2009 een tweede concepttekst. In september 2009 heeft de IAASB de standaard goedgekeurd. De standaard zal op basis van de huidige verwachtingen rond medio 2011 als dé standaard voor rapportage over beheersingsmaatregelen bij uitbesteding van processen met betrekking tot de financiële verantwoording gelden, maar mag reeds ook eerder gehanteerd worden (early adaption). Strikt genomen ligt er nu een internationale template die door de landenorganisaties, al dan niet aangepast, zal worden overgenomen. Naar verwachting zal de US-standaard die SAS 70 gaat vervangen in januari 2010 worden geaccordeerd. Ook in Nederland zijn NIVRA en NOREA begonnen met de voorbereidingen om de ISAE 3402 over te nemen. Bij het NIVRA gaat het daarbij om COS 3402 en bij NOREA om richtlijn 3402.

ISAE 3402: belangrijkste wijzigingen

Na vele jaren van vergaderen is er één internationale standaard als basis. Toch vallen de vernieuwingen voor de gebruikers van het servicerapport wat tegen. Zo blijft de ISAE 3402 voorbehouden voor de beheersing die betrekking heeft op (een gedeelte van) de financiële verantwoording van de gebruiker. In de standaard wordt voor de overige processen verwezen naar ISAE 3000. De nieuwe standaarden staan het gebruik voor rapportage over beheersingsmaatregelen voor niet-financiële processen niet toe, ook niet voor een combinatie van financiële en niet-financiële processen. Het framework en de guidance vanuit de standaard kunnen uiteraard bruikbaar zijn voor rapportages over beheersingsmaatregelen buiten de scope van de financiële verantwoording, maar bij de toepassing moeten de serviceorganisatie en de auditor zich bewust zijn van de mogelijk (aanzienlijke) verschillen op het gebied van suitable criteria, toepassing van het materialiteitsbegrip, gebruik, etc. Wij concluderen dat de inhoud en de vorm van het rapport beperkt zullen veranderen en het toepassingsgebied in zijn geheel niet, ondanks dat de naam mogelijk wel verandert. De naam SAS 70 zal verdwijnen en wordt internationaal mogelijk vervangen door het SAR, het Service Auditors Report. Wij komen later in het artikel terug op het gebruik van ISAE 3000 voor de overige processen.

De belangrijkste verschillen tussen de SAS 70- en de ISAE 3402-standaard zijn:

  • SAS 70 is een auditingstandaard. De nieuwe standaard is een ‘assurance’ standaard (een ‘attestation’ standaard in de Verenigde Staten). De belangrijkste wijzigingen daarbij zijn dat het management een verklaring over de werking van de beheersingsmaatregelen in het rapport dient op te nemen. Op deze wijze wordt de verantwoordelijkheid van het management voor het vastleggen van het stelsel van beheersingsmaatregelen benadrukt. Het is niet de bedoeling dat op grond van de nieuwe standaard het management een aparte functie instelt voor het documenteren en evalueren van de controls. Wel dient de service-auditor in staat te zijn te concluderen dat het management een redelijke basis heeft om zijn conclusie te onderbouwen. Het auditors report zal ‘direct reporting’ zijn en niet voortbouwen op de managementverklaring.

    Verder zijn de onderzoekscriteria (suitable criteria) op basis waarvan het management en de auditor de interne beheersing beoordelen, opgenomen in de ISAE 3402-standaard waar dit bij SAS 70 niet het geval was. In het kader worden de suitable criteria (Fairness of Presentation, Suitability of Design, and Operating Effectiveness) verder toegelicht. De standaard geeft dus een minimale set van criteria waaraan het controleframework van de serviceorganisatie moet voldoen. De service-auditor dient ook een beoordeling uit te voeren op de toereikendheid daarvan. Het effect van deze wijziging moet in de praktijk gaan blijken. Verwacht mag worden dat de criteria meer expliciet aandacht krijgen en de vrijheidsgraad in het formuleren van controls iets zal afnemen, aangezien de criteria duidelijk moeten worden genoemd in de controledoelstellingen. De auteurs verwachten dat het leggen van de relatie tussen de controls en de criteria complex zal blijven en een zaak van professional judgement.
  • Het oordeel van de auditor lijkt oppervlakkig bezien enigszins te gaan veranderen zoals hierna wordt toegelicht. Feitelijk blijven inhoudelijk de verschillen klein met twee opmerkelijke verschillen. In de nieuwe standaard geeft de auditor één oordeel over de beoordeling van drie aspecten uit de criteria. Verder zal voor een Type II-rapport het oordeel betrekking hebben op alle drie aspecten over de gehele periode. Voor een Type II voor een SAS 70 werden alleen de control activities (hoofdstuk III) op hun werking getoetst, onder de nieuwe standaard moeten alle COSO-elementen, zoals monitoring, information & communication, etc., op werking worden getoetst voor zover relevant (dus ook het huidige hoofdstuk ll). Dit zal in de praktijk meer werk kunnen betekenen, afhankelijk van de reeds aanwezige relevantie van hoofdstuk II in relatie tot de beheersingsmaatregelen uit hoofdstuk III.

Suitable criteria

Fairness of Presentation. Hierbij controleert de auditor of de beschrijving getrouw is. Geeft de beschrijving duidelijk en helder weer welke onderdelen niet in scope zijn opgenomen en/of door de gebruiker geïmplementeerd moeten worden? Bevat de beschrijving voldoende mate van detail en accurate informatie om een oordeel te kunnen geven over de beheersingsmaatregelen? Zijn de beheersingsmaatregelen in de beschrijving ook daadwerkelijk geïmplementeerd?

Suitability of Design. Hierbij controleert de auditor of de beheersingsmaatregel zodanig ontworpen is, dat de beheersingsdoelstelling met redelijke mate van zekerheid gehaald kan worden. Ook als een individuele beheersingsmaatregel niet afdoende is, kan de doelstelling nog steeds met een redelijke mate van zekerheid gehaald worden door de effectiviteit van de andere beheersingsmaatregelen.

Operating Effectiveness. Hierbij controleert de auditor of de beheersingsmaatregel effectief werkt. Door diverse bewijsstukken of door het opnieuw uitvoeren van de beheersingsmaatregel kan getest worden of de beheersingsmaatregel functioneert zoals beschreven.

Verder blijven er twee typen van rapportage mogelijk (Type I voor opzet en bestaan beheersingsmaatregelen, en Type II voor werking), moet het rapport minimaal zes maanden bestrijken en moeten de testwerkzaamheden zijn opgenomen in de rapportage, inclusief de gebruikte ‘sample sizes’ bij eventuele relevante afwijkingen. In de huidige SAS 70-standaard is de verspreidingskring van de rapportages beperkt. De nieuwe standaard 3402 vereist dat de auditor de gebruikers en het beoogde gebruik expliciet vermeldt bij zijn oordeel. De auditor kan overwegen om additionele bewoordingen op te nemen ten aanzien van de beperking van de verspreidingskring.

Overzicht overeenkomsten en verschillen ten opzichte van de huidige SAS 70-standaard

Verschillen:

  • De nieuwe standaard wordt een assurancestandaard, niet meer een auditstandaard, wat onder meer wil zeggen dat het management zelf expliciet verantwoording aflegt. Het oordeel van de service-auditor gaat er enigszins anders uitzien omdat er één opinie over verschillende aspecten wordt gegeven.
  • Het management wordt verplicht om bij een Type II een verklaring over de werking van de beheersingsmaatregelen op te nemen in het rapport (bij Type I over opzet en bestaan).
  • In een Type II-rapport zullen alle elementen in het rapport op alle drie criteria worden beoordeeld over de periode waarover het rapport gaat, en dat zal leiden tot één oordeel.

Overeenkomsten:

  • De verwachte controle-inspanning voor management en service-auditor blijft naar verwachting materieel gezien hetzelfde.
  • Er blijven twee typen rapportages (Type I en II).
  • Type II-rapportages moeten een minimumperiode omvatten van zes maanden.
  • Beperkingen in gebruik blijven grotendeels gelijk.
  • Testwerk van de service-auditor blijft onderdeel van het rapport.
  • Vermelden van sample sizes uitsluitend wanneer excepties zijn geïdentificeerd.

Alternatief voor niet-financiële processen: ISAE 3000

Een aantal praktische bezwaren van de reeds bestaande SAS 70 blijft overeind. Zo heeft de ISAE 3402 alleen betrekking op de processen die zijn gerelateerd aan de financiële verantwoording, conform de scope van SAS 70. De huidige praktijk laat echter zien dat serviceproviders graag een bredere scope zouden hanteren. Zij willen eveneens onafhankelijke zekerheid over de uitbesteding van niet-financieel gerelateerde onderdelen, zoals:

  • de continuïteit van de uitvoerder,
  • de naleving van de SLA-afspraken,
  • de accuraatheid van de informatiestromen tussen (bijvoorbeeld) pensioenuitvoerder en bestuur, of
  • de communicatie aan belanghebbenden (governance).

In de praktijk wordt deze uitbreiding van de SAS 70-scope veelal meegenomen in sectie lV van het rapport en wordt zij zodoende niet meegenomen in het oordeel van het service auditors report.

ISAE 3402 is niet bedoeld voor de genoemde uitbreiding, hiervoor is een goed alternatief voorhanden, te weten de ISAE 3000. Deze standaard bestaat reeds en is door het NIVRA opgenomen in COS 3000 en NOREA heeft hier de NOREA-richtlijn 3000 voor. De standaard is, anders dan de ISAE 3402, meer ‘vormvrij’, zolang een aantal verplichte onderdelen maar wordt behandeld. Het gaat hierbij om de definitie van het onderzoeksobject – de geïmplementeerde beheersingsmaatregelen op een bepaald moment of over een periode – en om de kwaliteitsaspecten, zoals betrouwbaarheid, exclusiviteit en continuïteit. De auditor zal in voorkomende gevallen zelf de toepasbaarheid van de kwaliteitscriteria moeten beoordelen. Dit om te voorkomen dat er – in overdrachtelijke zin – een niet-rationele opdracht wordt geaccepteerd. De assurancerapportage kan vrijwel identiek aan de SAS 70-rapportage worden opgesteld, maar dat hoeft niet. Er kan ook worden gekozen voor een ‘korte’ variant ten opzichte van de verplichte SAS 70-onderdelen, waarbij naast het oordeel ook de onderzoeksdoelstellingen en beheersingsmaatregelen worden opgenomen in de bijlage. Het rapport bestaat feitelijk uit de verklaring, waarin wordt verwezen naar de relevante controledoelstellingen en beheersingsmaatregelen in de bijlage. Dit lijkt sterk op de TPM’s (Third-Party Mededeling) die in het verleden meer werden gebruikt.

Deze ‘korte’ variant is ook een alternatief voor die gevallen waarin een intern servicecenter zekerheid verschaft aan de interne gebruikers van zijn diensten. Dit komt veelvuldig voor in die situatie waarin een rekencentrum de ICT- (infrastructurele) diensten verzorgt ten behoeve van diverse divisies. Dit wordt in figuur 1 weergegeven. De auditors van het rekencentrum geven een IT-auditrapport (geen assurance) aan de divisies af ten behoeve van de SAS 70-rapportage die de divisies aan hun klanten verstrekken.

C-2010-1-Beek2-01

Figuur 1. Interne Assurance, intern en extern.

Strikt genomen kan een SAS 70 niet intern worden gebruikt, ook een ISAE 3000 niet. In figuur 1 wordt om die reden ook gesproken over een IT-auditrapport.

Een SAS 70 is veelal omvangrijker en kan daarmee duurder zijn dan een ISAE 3000-rapportage. Bij de ISAE 3000-rapportage, die dezelfde zekerheid verschaft, kan de bijlage bij de verklaring worden beperkt tot de onderzoeksdoelstellingen en beheersingsmaatregelen, en kan sectie ll (van de SAS 70) achterwege worden gelaten, indien gewenst. De testwerkzaamheden voor de auditor kunnen nog wel gelijk zijn, maar deze hoeven niet te worden opgeschreven in het assurancerapport. Zoals gezegd, de ISAE 3000 is vormvrij.

Naast de eerdergenoemde voorbeelden van het gebruik van ISAE 3000 kan ook binnen deze structuur worden gedacht aan nieuwe/andere gebieden waarover zekerheid wordt verschaft, zoals verklaringen omtrent vertrouwelijkheid, privacy, governance en soft controls. In de praktijk is er een toenemende behoefte aan zekerheid op deze gebieden.

De ontwikkelingen rond de nieuwe ISAE 3402-standaard zetten eigenlijk de ISAE 3000 als alternatief opnieuw in het zonnetje. Voor (IT-) serviceorganisaties die meer willen dan standaard wordt toegestaan door de huidige (SAS 70) en de nieuwe (ISAE 3402-) standaard, is daarmee reeds een aanvaardbaar alternatief voorhanden.

Verstandige keuzen voor de serviceorganisatie

Serviceorganisaties staan nu voor de keuze welke standaard het beste voorziet in de behoefte, gebaseerd op de uitwerking van ISAE 3402 of 3000 in de nationale richtlijnen. Indien het rapport overwegend financiële processen relevant voor de jaarrekeningcontrole bevat, is een van ISAE 3402 afgeleide standaard de meest geschikte. In alle andere gevallen verdient het hanteren van de ISAE 3000-standaard de voorkeur, waarbij dezelfde zekerheid en structuur kunnen worden gehanteerd als bij de ISAE 3402.

Indien besloten wordt over te gaan naar de nieuwe standaard zijn de belangrijkste activiteiten voor de serviceorganisatie:

  • Begrijpen van de veranderingen. Dit betreft met name de noodzaak om een managementverklaring in het rapport op te nemen.
  • Overleg met de service-auditor. Het gaat daarbij met name om de verwachte impact op het rapport van de service-auditor, zijn werkzaamheden en de impact op eventuele sub-serviceorganisaties. De nieuwe standaard 3402 stelt dat bij een inclusive rapportage niet alleen de controles van de sub-serviceorganisatie moeten worden beschreven en getest, maar ook de organisatiebrede beheersingsmaatregelen (hoofdstuk II). Daarmee zijn alle voordelen van een inclusive rapportage weg en is het handiger dat een sub-serviceorganisatie haar eigen rapport opstelt. Gericht op de gebruikers van de rapporten is het goed om tijdig de behoefte en consequenties van early adaption te bespreken.
  • Plannen van de transitie. Dit omvat het opzetten van interne training, coördinatie met de eventuele juridische afdeling, het opstellen van een communicatieplan en het reviewen van de huidige rapporten en processen om vast te stellen hoe aan de nieuwe criteria voldaan gaat worden. In ieder geval dient aandacht te worden besteed aan de vraag of er een voldoende onderbouwing aanwezig is waarop de nieuwe management assertion gebaseerd gaat worden. Het is daarbij niet zoals bij SOx 404 dat het verplicht is dat alle management controls door het management eerst worden getest, voordat de auditor dit doet.

Conclusie

De nieuwe ISAE 3402 wordt dé standaard voor rapportage over de beheersing van uitbestede processen die van invloed zijn op beweringen in de financiële verslaglegging van de uitbestedende partij. Deze nieuwe standaard zal nauwelijks afwijken van de SAS 70-standaard, waardoor de serviceorganisatie geen wezenlijke aanpassingen hoeft door te voeren. Indien de serviceorganisatie inzicht en zekerheid wil geven over de niet-financiële processen, kan men beter voor de ISAE 3000-standaard kiezen. Hetgeen overigens een alternatief is dat al bestaat! Naar de mening van de auteurs liggen hier de uitdagingen om serviceorganisaties meer mogelijkheden te geven om over hun dienstverlening verantwoording af te leggen tegen de gewenste zekerheid.

Literatuur

[Bell09]] Sander van Bellen, Marco Francken en Joyce Grotencleas, De pensioenwereld, 2009.

[Hout09] Dennis Houtekamer en Remco de Graaf, ISAE 3402: einde van de SAS 70 in zicht?, januari 2009.

[ISEA09] Proposed New International Standard and amendments on Assurance Engagements ISAE 3402, Assurance Reports on Controls at a Third Party Service Organization, IAASB, July 2009.

IT-beveiligingstesten als onderdeel in IT-audits

Voor beveiligingsonderzoeken worden naast audits steeds vaker beveiligingstesten ingezet. Bij het uitvoeren van beveiligingstesten wordt de effectiviteit van beheersings- en beveiligingsmaatregelen getest. Vreemd genoeg worden audits en beveiligingstesten niet vaak gecombineerd, terwijl zij elkaar een meerwaarde kunnen bieden. Sterker nog, mogelijk dienen beveiligingsonderzoeken gezamenlijk te worden uitgevoerd om de vraag van de klant goed te kunnen beantwoorden.

Inleiding

IT-auditors voeren onderzoeken uit naar IT-omgevingen. Vaak wordt bij een dergelijk onderzoek gekozen voor het uitvoeren van een formele audit. Met een audit is op voorhand een duidelijke structuur van werkzaamheden voorhanden. Bijvoorbeeld is het helder hoe het feitenonderzoek plaatsvindt en op welke wijze conclusies worden getrokken.

In toenemende mate zien wij dat cliënten vragen hebben over de IT-beheersing in combinatie met de aanverwante informatiebeveiliging. Vaak wordt dan gekozen voor een IT-audit van IT-beveiligingsprocessen. Dan kunnen onderwerpen worden geadresseerd zoals het verkrijgen van toegang van gebruikers tot de data en het monitoren van beveiliging.

Naast audits vinden beveiligingstesten plaats. Dit zijn zogenaamde overeengekomen specifieke werkzaamheden waarbij een feitenonderzoek naar beveiligingsmaatregelen plaatsvindt. Feitenonderzoek richt zich niet op getroffen maatregelen, maar op de effectiviteit van een stelsel van maatregelen. Een beveiligingstest maakt dan ook gebruik van een andere aanpak, met andere resultaten.

De reguliere IT-audit heeft een meer procesgerichte aanpak, terwijl de IT-beveiligingstest een meer gegevensgericht onderzoek is. Maar beide onderzoeken worden uitgevoerd om eenzelfde onderzoeksgebied te analyseren. Zouden we de twee onderzoeken dan juist goed kunnen combineren? Hebben beide onderzoeken een grote overlap, of vullen zij elkaar juist aan? Om antwoord te geven op deze vragen is het interessant de beide soorten onderzoeken nader te beschouwen. Vervolgens behandelen we de aanwezige onderlinge versterking om te komen tot inzicht in de synergie.

IT-auditing

IT-auditing is een feitenonderzoek met een vaste structuur en een duidelijke onderzoeksaanpak. Voor het vergaren van de feiten worden de volgende technieken toegepast:

  • interview van het management en personeel;
  • inspecteren en beoordelen van documentatie omtrent proces en organisatie;
  • observatie van getroffen maatregelen;
  • her-uitvoeren van maatregelen.

Tijdens de interviews met management en personeel wordt beoogd helder te krijgen welke processen plaatshebben binnen de organisatie. Binnen de processen wordt beoordeeld of de procedures worden gevolgd zoals in opzet vastgelegd. Dit heeft tot doel om te beoordelen of afdoende maatregelen zijn geïmplementeerd binnen de procedures (in opzet) en of deze ook daadwerkelijk zijn geïmplementeerd en worden uitgevoerd (bestaan). Als laatste kan ook worden gecontroleerd of de maatregelen gedurende een bepaalde periode actief waren (werking). De maatregelen zijn binnen het toetsingskader gevangen in zogeheten controls. De controls tezamen dienen een integraal en afdoend complex van maatregelen te vormen teneinde in control te zijn van de processen en de organisatie. Een IT-audit heeft hierbij een sterke nadruk op de IT.

Door het inspecteren van de documentatie wordt een beeld verkregen van de opzet van processen, controls, evenals van configuratie-instellingen in de IT-omgeving. Door de opzet te toetsen aan het bestaan en vice versa wordt de werkelijke effectiviteit van de geïmplementeerde controls duidelijk.

Ter aanvulling op interviews en het inspecteren van documentatie wordt gebruikgemaakt van observatie en het her-uitvoeren van controls. In beide gevallen test een IT-auditor als het ware zelf de aanwezigheid, en dus de effectiviteit, van de control. Een passend voorbeeld is te zien binnen het onderwerp van de fysieke beveiligingsmaatregelen. Fysieke beveiligingsmaatregelen worden geïmplementeerd om de toegang tot ruimten binnen bijvoorbeeld een datacenter te controleren. Zo dienen bezoekers met een bezoekerspas niet in staat te zijn bepaalde delen van een datacenter te betreden. Wanneer de IT-auditor een bezoekerspas aanvraagt en deze bij een paslezer houdt, kan hij observeren of hem de toegang wordt geweigerd daar waar in opzet bedoeld. Op basis van de uitkomst van deze test stelt de IT-auditor vast of deze control daadwerkelijk effectief is (de toegang wordt geweigerd).

Naast het bevragen van management en personeel om vast te stellen of geïmplementeerde maatregelen overeenkomen met in opzet vastgelegde procedures, is het noodzakelijk om de IT-systemen ook te toetsen. Deze systemen vormen de basis van de geautomatiseerde processen en procedures. De IT-systemen ondersteunen de processen in een bedrijf en dienen dus ook controlemaatregelen geïmplementeerd te hebben. Een deel van de controls is dus geautomatiseerd. Het betrekken van de IT-systemen binnen het onderzoek naar de beheersing van IT is noodzakelijk.

Het onderzoeken van de IT-systemen en de onderlinge samenhang van geïmplementeerde controls als onderdeel van het feitenonderzoek kost veel tijd (en vraagt dus een groot budget). Het onderzoeken van tientallen applicaties, databases, honderden servers en netwerkapparatuur is een noodzaak, echter niet praktisch haalbaar. Om toch een integrale en correcte uitspraak te doen over het bestaan van controlemaatregelen binnen de IT-infrastructuur, wordt een aantal technieken toegepast: scoping en sampling.

Scoping wordt gebruikt om slechts de relevante IT-infrastructuur in het onderzoek te betrekken. Bij een onderzoek naar bijvoorbeeld de informatiebeveiliging van de financiële gegevens worden alleen de financiële systemen meegenomen; andere systemen dus niet.

Sampling wordt gebruikt om binnen de geselecteerde systemen, specifieke systemen en configuraties te bekijken. Sampling wordt zodanig intelligent uitgevoerd dat een uitspraak over de sample iets zegt over de verzameling waaruit deze voortkomt. Zo wordt een sample genomen uit een groep van gelijksoortig ingerichte systemen, bijvoorbeeld fileservers. Door het onderzoeken van de inrichting van één van de file servers is de inrichting van de overige gelijksoortig ingerichte fileservers onderzocht.

Deze aanpak lijkt solide om te komen tot een onderbouwde uitspraak. Echter, deze aanpak introduceert een drietal problemen:

  1. Niet alle systemen worden onderworpen aan een onderzoek.
  2. De systemen worden vervolgens niet in detail onderzocht.

Naast een beperkt feitenonderzoek op systeemniveau speelt nog een ander probleem: de integrale beoordeling van de geautomatiseerde controls. Hoe beoordeelt men de invloed van een netwerkconfiguratie op een geautomatiseerde controlemaatregel in een server of een database?

  1. Een juiste integrale beoordeling van de IT-omgeving is praktisch niet haalbaar door de complexiteit van de IT-omgeving en de onderlinge dynamiek van de geïmplementeerde controlemaatregelen.

De huidige IT-auditaanpak voor het beoordelen van het bestaan van controlemaatregelen binnen de IT-infrastructuur is niet efficiënt en slechts beperkt effectief. Doordat de systemen technisch gezien slechts beperkt worden bekeken, neemt het risico van een foute uitspraak door de IT-auditor toe. Zo kan een IT-auditor ten onrechte claimen dat het IT-beheer op orde is en de informatiebeveiliging op niveau, terwijl het ondersteunende feitenonderzoek beperkt is geweest.

C-2009-4-Kornelisse-01

Figuur 1. Samenhang en complexiteit van IT-omgevingen vormen een uitdaging binnen een IT-audit voor een juiste uitspraak.

Beveiligingstesten

Auditors voeren al lange tijd beveiligingstesten uit. Een beveiligingstest is een technisch onderzoek naar de effectiviteit van de beveiligingsmaatregelen inzake IT-objecten. Deze effectiviteit wordt vastgesteld door te zoeken naar zwakheden en door die zwakheden eventueel uit te buiten. Een dergelijk onderzoek dient te worden uitgevoerd door iemand die kundig is op het gebied van technische IT-beveiliging. Tevens dient deze persoon de gevonden kwetsbaarheden te kunnen vertalen naar bedrijfsrisico’s. Deze vertaling naar bedrijfsrisico’s is cruciaal om een uitspraak te kunnen doen over de effectiviteit van de IT-beveiliging.

De reden van uitvoeren

De klanten die deze dienst afnemen hebben vaak duidelijke vragen, zoals: is mijn IT-omgeving bestand tegen cyberaanvallen? En als men slaagt in een succesvolle aanval, welke bedrijfsgegevens worden gecompromitteerd? Hoe kan de IT-beveiliging van de omgeving verder worden verbeterd? Allemaal valide vragen, temeer omdat IT-objecten continu staan blootgesteld aan hackers en kwaadwillend personeel. De klant heeft behoefte te weten welke risico’s er zijn, wat de kans van optreden van die risico’s is, wat de impact is, en hoe deze risico’s verlaagd kunnen worden.

Maar waarom beantwoorden we deze vragen door middel van een IT-beveiligingstest en niet door middel van een reguliere IT-audit? Het antwoord daarop is goed uit te leggen door een zijstap te maken naar de wereld van brandoefeningen.

Een brandoefening wordt binnen gebouwen met regelmaat uitgevoerd. Een brandoefening wordt voornamelijk uitgevoerd om een ontruiming wegens brand in het gebouw zo echt mogelijk te simuleren. De brandoefening staat niet op zichzelf. Diverse plannen, overleggen en trainingen voor personeel zijn hieraan voorafgegaan. Daarnaast zijn brandvoorzieningen in de gebouwen aanwezig. Echter, de brandoefening is de ultieme test of al het voorbereidende werk ook effectief is. Door alle maatregelen te testen weet men of deze maatregelen in de praktijk echt werken, of dat er toch een en ander misgaat. Meer dan eens komt door de brandoefening naar voren dat er toch nog zaken over het hoofd zijn gezien. Denk hierbij aan elektrische deuren die (toch) niet opengaan, knelpunten van mensenstromen of brandmelders die dienst weigeren.

Een IT-beveiligingstest kan hiermee worden vergeleken. Het is de test of de beveiliging afdoende effectief is door het uitvoeren van een simulatie, of dat toch nog wat zaken over het hoofd zijn gezien.

Soorten van beveiligingstesten

Beveiligingstesten bestaan in vele smaken. Dergelijke testen kunnen als volgt worden gerubriceerd:

  • Black box. De aanvaller heeft geen enkele informatie over de objecten in scope.
  • Grey box. De aanvaller heeft beknopte informatie over het object. Denk hierbij aan een netwerkarchitectuur met verkeersstromen of afgeleide informatie zoals de opzet van een gebruikersnaam.
  • White box. De aanvaller heeft veel informatie over het object en zelfs een bepaalde vorm van toegang. Denk hierbij aan een webapplicatie waar de aanvaller inloggegevens voor heeft. Het doel is om meer rechten te krijgen binnen de applicatie.

Een term die vaker wordt gebruikt is ‘double’. Een double black box-test betekent dat de aanvaller geen enkele informatie heeft over de objecten in scope. Daarnaast is de IT-organisatie niet op de hoogte van de beveiligingstest. Daardoor wordt de effectiviteit van de beheerorganisatie inzake het herkennen, lokaliseren en mitigeren van een aanval ook getest. Deze test simuleert het best een werkelijke aanvalssituatie.

Mogelijke objecten van onderzoek

Beveiligingstesten kunnen zich richten op een veelheid van objecten. Denk bijvoorbeeld aan:

  • externe website;
  • aanwezigheid op het internet (alle systemen aan het internet maar ook de publieke informatie zoals Google en RIPE);
  • het interne netwerk voor kantoorautomatisering;
  • applicaties zoals een intranet of een CRM-systeem;
  • databases;
  • mobiele apparatuur (bijvoorbeeld een telefoon of PDA);
  • personeel.

Hoewel het personeel strikt genomen geen IT-object is, kan het personeel wel object van onderzoek zijn. Om maatregelen op het niveau van het personeel te testen, wordt een zogeheten social engineering test uitgevoerd. Met een dergelijke test wordt onderzocht of het personeel zich houdt aan het beveiligingsbeleid van het bedrijf. Denk hierbij aan het doorlaten van personen zonder pasje bij een elektronisch beveiligde deur, het niet afsluiten van ongebruikte computers, het opschrijven van wachtwoorden bij de computer of het communiceren van wachtwoorden via de telefoon.

Wijze van onderzoek

Beveiligingstesten zijn, op social engineering tests na, technische onderzoeken. Hierbij wordt direct met de techniek gecommuniceerd. Het gebruik van programmatuur ter ondersteuning van het onderzoek is dan ook een logisch gevolg. Dit kan veel tijdwinst opleveren. Bijvoorbeeld: het proberen van een aantal wachtwoorden vindt geautomatiseerd sneller plaats dan met de hand. Tevens kan de tester ondertussen zijn aandacht dan ergens op richten. Maar let op, de programmatuur ten behoeve van IT-beveiligingstesten dient louter ter ondersteuning, want zij kan slechts simpele taken automatiseren. De resultaten van de programmatuur dienen altijd gevalideerd te worden door de tester. Vanwege de complexiteit kan nooit op de pure uitkomst van de programmatuur worden vertrouwd, omdat de programmatuur vaak zogenaamde false-positives (niet bestaande zwakheden) rapporteert. Het bekende credo ‘a fool with a tool is still a fool‘ gaat hier dan ook zeker op.

Het uitvoeringsproces van een IT-beveiligingstest is terug te brengen tot de volgende stappen: mapping, scanning en exploiting. De keuze van deze stappen, samen met de objecten, bepaalt de mate van intrusie. We herkennen hierbij de volgende onderverdeling: vulnerability assessment, penetration testing en red teaming. Het verschil hiertussen is het beste uit te leggen aan de hand van figuur 2.

C-2009-4-Kornelisse-02

Figuur 2. Overzicht van soorten IT-beveiligingstesten.

In de mappingfase wordt gekeken welke systemen überhaupt aanwezig zijn in het netwerk en welke services actief zijn op die systemen. Tevens worden metadata uit zoekmachines of andere publieke bronnen geraadpleegd. In de scanningfase worden versies van software herkend en worden de objecten onderworpen aan scans op zoek naar zwakheden. Deze twee fasen samen zijn onderdeel van een ‘vulnerability scan’. In deze twee stappen wordt veel gebruikgemaakt van geautomatiseerde tools.

Een volledige penetration test omvat ook de derde stap: exploiting. In deze stap worden gevonden zwakheden uitgebuit om zo in de systemen te kunnen inbreken. Dat kan door middel van een exploit, stukken programmacode die een kwetsbaarheid uitbuiten. De aanvaller laat het object in kwestie acties uitvoeren die de aanvaller toegang verschaffen. Na een succesvolle exploitingfase heeft de aanvaller toegang verkregen tot het object met bijbehorende gegevens.

De term red teaming is een uitbreiding op penetration testing en is afkomstig uit de militaire wereld waar het in gevechtsimulaties wordt gebruikt. Bij red teaming is het doel het belangrijkste. De trukendoos mag volledig open; alle acties die men kent mogen worden gebruikt. Bij IT-beveiligingstesting kan men hierbij denken aan een bedrijf dat louter is geïnteresseerd of inbreken mogelijk is, in de brede zin van het woord. Een combinatie van social engineering (manipuleren van mensen), phishing (ontlokken van gevoelige informatie, zoals gebruikersnaam en wachtwoord) en war driving (zoeken naar en toegang verkrijgen tot het draadloos netwerk van het bedrijf) met interne en externe penetratietesten kan dan bijvoorbeeld worden gebruikt om het doel te bereiken.

Wijze van rapporteren

Een beveiligingstest is, net als een IT-audit, een feitenonderzoek. Echter, bij een beveiligingstest worden alleen negatieve feiten gerapporteerd, bijvoorbeeld: ‘De gebruikte wachtwoorden voor het systeemaccount zijn gelijk aan de standaardwachtwoorden van de fabrikant, en daardoor gemakkelijk te raden‘.

Door een zwakheid te vinden of door in te breken op een systeem kan worden aangetoond dat de beveiliging niet afdoende is. Andersom kan niet worden geredeneerd. Als het niet lukt zwakheden te vinden of in te breken, dan betekent dat niet dat deze zwakheden er niet zijn. Een hacker met ongelimiteerde tijd of budget zal vrijwel altijd kunnen inbreken. Immers, een hacker hoeft zich niet te houden aan gemaakte afspraken over de toegestane aanvallen!

Het eindresultaat van een IT-beveiligingstest is een rapport of presentatie met negatieve bevindingen en aanbevelingen ter verbetering.

Overeenkomsten en verschillen van IT-audit en IT-beveiligingstest

Om een beeld te krijgen van de overeenkomsten en verschillen tussen werkzaamheden inzake IT-audits en -beveiligingstesten hebben wij deze uitgezet op basis van een aantal aspecten.

1. Soorten onderzoeken

De soorten IT-audits zijn in te delen op basis van de hoeveelheid assurance: redelijke mate van zekerheid, beperkte mate van zekerheid en feitelijke bevindingen. Daarbij zijn de eerste twee soorten vaak van toepassing als de uitkomst van het onderzoek niet alleen voor de opdrachtgever maar ook voor derden toegankelijk is. Denk bijvoorbeeld aan een SAS70, TPM of jaarrekeningcontrole. De laatste soort (feitelijke bevindingen) wordt vaak gebruikt door bedrijven om een nulmeting uit te voeren of om zichzelf te verbeteren. Deze informatie is niet bedoeld voor derden, omdat er geen conclusie is verbonden aan de feitelijke bevindingen.

De soorten IT-beveiligingstesten zijn terug te brengen tot: vulnerability assessment, penetratietest en red teaming. De eerste test gaat in op het in kaart brengen van geverifieerde zwakheden. De tweede en derde test gaan een stap verder door de gevonden zwakheden daadwerkelijk uit te buiten. Bij red teaming is het arsenaal aan toegestane middelen onbeperkt, terwijl dit bij een penetratietest zich beperkt tot een bepaalde scope. De IT-beveiligingstest lijkt qua soort sterk op het onderzoek van feitelijke bevindingen bij de IT-audit.

2. Publiek

Het publiek van een IT-audit en een IT-beveiligingstest is verschillend. Zoals gezegd kan een rapport van een IT-audit ook voor derden zijn. Bij IT-beveiligingstesting is dit niet het geval. Immers, alle gevonden kwetsbaarheden zijn dan beschikbaar voor de buitenwereld. Dit is niet wenselijk. Een ander verschil is dat het publiek van een IT-beveiligingstest vaak sterke affiniteit heeft met IT (bijvoorbeeld een IT-manager) en niet zozeer met bedrijfsprocessen. Bij een IT-audit bestaat het publiek naast de opdrachtgever soms uit derden en heeft het publiek vaak meer affiniteit met bedrijfsprocessen en risico’s dan met de techniek. Een voorbeeld hiervan zijn CEO’s, CFO’s en CIO’s als opdrachtgever. Derden zijn bijvoorbeeld toezichthouders of (in het geval van outsourcing) de demandorganisatie.

3. Toetsingsnormen van een IT-audit en een IT-beveiligingstest

IT-audits worden uitgevoerd op basis van verschillende toetsingsnormen. Dit is afhankelijk van het precieze doel van het onderzoek en de omgeving waarin het onderzoek plaatsvindt. Op het gebied van IT-beheer en informatiebeveiliging zijn de toetsingsnormen bijvoorbeeld Cobit, ITIL en ISO 27001.

Voor IT-beveiligingstesting echter zijn geen algemeen en internationaal geaccepteerde toetsingsnormen voorhanden. Wel zijn er initiatieven om te komen tot dergelijke toetsingsnormen. Een voorbeeld hiervan is OWASP: Open Web Application Security Project. OWASP is een verzameling toetsingsnormen voor webapplicaties.

4. Uitvoering van een IT-audit en een IT-beveiligingstest

Het onderzoek van een IT-audit vindt plaats op basis van documentatiestudie, interviews en observaties. Er wordt uitgegaan van de bekende maatregelen binnen het bedrijf, waarvan opzet, bestaan en werking van deze maatregelen worden getoetst. De nadruk ligt op de opzet, het bestaan en de werking van het beleid en de procedures. De techniek krijgt slechts beperkte aandacht.

Een IT-beveiligingstest heeft juist de focus op de techniek. Deze vindt plaats op basis van een black box-benadering. Dit betekent dat er wordt uitgegaan van het onbekende in plaats van het bekende: de tester weet niet welke maatregelen er zijn getroffen. De focus ligt op de daadwerkelijke effectiviteit van de maatregelen die in de techniek zijn geïmplementeerd. Deze maatregelen worden getest door te bekijken of deze omzeild kunnen worden.

5. Kwaliteitsaspecten van een IT-audit en een IT-beveiligingstest

Een IT-audit kan zich richten op een groot aantal kwaliteitsaspecten. Denk hierbij aan performance, toekomstvastheid, (beheer)kosten, projectplanning, etc. Daarbinnen wordt een IT-audit ook vaak gebruikt voor beveiligingsonderzoeken. De kwaliteitsaspecten komen precies overeen met die van een IT-beveiligingstest:

Beschikbaarheid

Kernvraag: zijn de systemen altijd beschikbaar? Onderwerpen die aan bod komen zijn bijvoorbeeld het gecontroleerd laten verlopen van wijzigingen in de IT-omgeving, redundantie van IT-systemen en reservekopieën van gegevens.

Bij een IT-audit worden voor dit aspect vaak het beleid en de procedures rondom change management, redundantie en back-up & recovery bekeken.

Bij een IT-beveiligingstest wordt getracht om IT-objecten onbeschikbaar te maken in de omgeving, door deze bijvoorbeeld te overstelpen met bevragingen of juist gegevens toe te sturen.

Vertrouwelijkheid

Kernvraag: kan iemand bij gegevens die hij/zij niet mag zien? Hierbij wordt vaak gekeken naar de autorisaties die gebruikers hebben op de gegevens. Zo zouden de medewerkers van een verkoopafdeling geen inzicht moeten hebben in de gegevens van de HR-afdeling.

Bij een IT-audit ligt de nadruk op de procedures rond het aanmaken, wijzigen en verwijderen van gebruikersaccounts en de autorisaties die bij de gebruikersaccounts horen. Ook wordt aandacht besteed aan de periodieke controle van die accounts en autorisaties. Tevens is er aandacht voor de opzet en het bestaan van beveiligingsinstellingen in de IT-omgeving.

Bij een IT-beveiligingstest wordt getracht die geïmplementeerde maatregelen te testen en waar mogelijk te omzeilen.

Integriteit

Kernvraag: kan iemand gegevens zonder toestemming aanpassen? Ook hierbij wordt vaak gekeken naar de autorisaties die gebruikers hebben op de gegevens.

Voor zowel een IT-audit als een IT-beveiligingstest gelden dezelfde aandachtsgebieden als bij vertrouwelijkheid. Echter, hier wordt ook gekeken naar de daadwerkelijke mogelijkheid voor gebruikers om gegevens te manipuleren.

6. Onderzoeksobjecten van een IT-audit en een IT-beveiligingstest

De onderzoeksobjecten bij een IT-audit bestaan in hoofdzaak uit mensen, processen en (zij het beperkt) IT-systemen. Hierbij ligt de focus op de samenhang van deze drie objecten.

Bij een IT-beveiligingstest is het accent juist omgekeerd. De onderzoeksobjecten bij een IT-beveiligingstest zijn de IT-systemen. Soms zijn dit ook mensen (bijvoorbeeld bij een social engineering test), waarmee er dus een overlap is met een IT-audit, zij het met een andere invalshoek.

7. Reikwijdte van een IT-audit en een IT-beveiligingstest

De reikwijdtes van een IT-audit en een IT-beveiligingstest verschillen onderling. Onder reikwijdte wordt hier verstaan: de objecten die bekeken worden en de mate van detail waarin dit gebeurt.

Een IT-audit dekt voornamelijk het gebied af van beleid en procedures. Er wordt gekeken naar de volledige opzet van het beleid en de procedures. Ook wordt er gekeken naar enkele samples van het bestaan. Tot slot wordt die bestaanscontrole toegepast op gegevens die over een periode zijn verzameld. Hieruit blijkt de werking. De onderliggende techniek krijgt beperkte aandacht en wordt niet in (individueel) detail bekeken.

Een IT-beveiligingstest dekt zoals gezegd andere zaken af. De focus ligt juist niet op het voorgenomen beleid en de procedures, maar op de implementatie van de maatregelen in de techniek. De techniek krijgt veel aandacht. Verder wordt zoveel mogelijk getracht om de techniek tot in individueel detail te bekijken. De geïdentificeerde problemen worden vertaald naar bedrijfsrisico’s en mogelijke root causes. Een harde relatie tussen de geïdentificeerde problemen en het beleid en procedures is niet te geven, zonder het beleid en de procedures onderzocht te hebben.

C-2009-4-Kornelisse-t01

Tabel 1. Aspecten van IT-audit en IT-beveiligingstest vergeleken.

Voordelen van een beveiligingstest als onderdeel van een IT-audit

Uit tabel 1 kunnen we concluderen dat IT-beveiligingstesting voordelen heeft ten opzichte IT-auditing. Een aantal daarvan is goed toepasbaar tijdens IT-audits en levert direct voordelen op voor IT-audits.

Snelheid

Het uitvoeren van een vulnerability scan of een penetratietest gaat relatief snel. Binnen enkele uren ontstaat een eerste beeld. Bijvoorbeeld: is het updaten van software consequent uitgevoerd? Het grote aantal objecten dat tegelijk kan worden bekeken (geautomatiseerd) biedt ook snelheidsvoordeel. Dit heeft als bijkomend voordeel dat men zou kunnen kiezen om periodiek een, deels geautomatiseerde, test uit te voeren. Hierdoor ontstaat een beeld over een langere periode en kan mogelijk meer gezegd worden over de werking van de maatregelen in de loop van de tijd.

Controle van bestaan van objecten

Bij een IT-securityscan wordt begonnen met te onderzoeken welke objecten daadwerkelijk aanwezig zijn op een netwerk, in tegenstelling tot het vertrouwen op de lijst van systemen aangereikt door de klant. Hierdoor kan het voorkomen dat objecten worden (her)ontdekt. Denk bijvoorbeeld aan een systeem dat men vorig jaar al dacht te hebben uitgefaseerd of aan een niet-geautoriseerde netwerkkoppeling naar internet of een ander bedrijf.

Scopingondersteuning

Een IT-beveiligingstest kan een IT-audit helpen bij het maken van de juiste keuzen omtrent scoping, sampling en de onderwerpen die extra aandacht behoeven binnen de IT-audit. Als uit de IT-beveiligingstest blijkt dat veel Windows systemen niet geüpdatet zijn, is dit voor een IT-audit een goed startpunt om het updatebeleid onder de loep te nemen en daarnaast de Windows beheerorganisatie extra aandacht te geven.

Verminderde complexiteit

IT-omgevingen groeien en zullen vooral nog meer blijven groeien. Tevens worden systemen steeds afhankelijker van de invoer vanuit andere systemen. Deze samenhang en complexiteit van de verschillende maatregelen binnen de IT-omgevingen kunnen verstrekkende gevolgen hebben die op het eerste gezicht niet altijd even duidelijk zijn. Een IT-beveiligingstest kan deze samenhang van technische componenten duidelijk aantonen door te zoeken naar de zwakste schakel in het beveiligingsmodel. Op basis van een dergelijk onderzoek kan blijken dat de functiescheiding in een applicatie niet gewaarborgd is door kwetsbaarheden in onderliggende databases, besturingssystemen of netwerk.

Duidelijke impact

Het resultaat van een IT-beveiligingstest maakt de impact van een kwetsbaarheid heel duidelijk. ‘Wij waren in staat ongeautoriseerde betalingen te verrichten’ is immers duidelijker dan ‘De autorisaties van het betaalsysteem en het controlesysteem zijn onvoldoende gewaarborgd. Dit kan leiden tot ongeautoriseerde betalingen’. Het risico is in beide gevallen gelijk, maar de impact is duidelijker doordat de eerste formulering veel concreter is.

C-2009-4-Kornelisse-03

Figuur 3. IT-beveiligingsonderzoek ondersteunt IT-audit door het versterken van de breedte en diepte van het onderzoek.

Voordelen IT-audit bij een IT-beveiligingstest

IT-auditing heeft ook een aantal voordelen ten opzichte van beveiligingstesten. Deze zijn samen te vatten tot onderstaande punten:

Root cause analyse

Techniek wordt ingericht en bestuurd door mensen. Mensen kunnen fouten maken. Deze fouten komen tot uiting in de implementatie van de techniek. Maar het hoeft niet zo te zijn dat de fout alleen daar ligt. Doordat een IT-audit ook kijkt naar het beleid en naar procedures kan het een grondigere root cause analyse maken.

C-2009-4-Kornelisse-04

Figuur 4. Synergie tussen IT-audit en IT-beveiligingstesting.

Toekomstvastheid

Daar waar een IT-beveiligingstest een momentopname is kan een IT-audit een periode van tijd onderzoeken. Dit heeft tot gevolg dat een IT-audit ook een betere uitspraak kan doen over een toekomstige tijd. Als procedures worden gevolgd en periodieke controles plaatsvinden geeft dat meer waarborgen voor de toekomst dan dat een object op een bepaald moment veilig is ingericht.

Conclusie

Nu we de twee verschillende onderzoeken besproken hebben, is duidelijk dat ze elkaar aanvullen juist op de plekken waar zij zwaktes vertonen. Wanneer we de combinatie van IT-audit en IT-beveiligingstesting gebruiken ontstaan er twee voordelen:

  1. Efficiëntie (budget). Door de juiste onderzoeksaanpak te kiezen voor de verschillende onderzoeksobjecten kan het onderzoek veel efficiënter worden uitgevoerd.
  2. Verlaging audit risk. Door de juiste onderzoeksaanpak te kiezen voor de verschillende onderzoeksobjecten kan het onderzoek veel meer in de diepte en breedte worden uitgevoerd en wordt de IT integraler getoetst.

Bovenstaande voordelen tonen aan dat een technische IT-audit dan ook veel baat heeft bij een IT-beveiligingstest.

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

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

Introduction

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

Project Definition – Defining the Objective and Scope of the Project

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

Business Case – Where to Start?

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

C-2009-3-Wilpshaar-t01

Table 1. The business case.

Approach

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

Phase 0 “Establish Foundation”

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

Phase 1 “Current State Assessment”

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

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

C-2009-3-Wilpshaar-t02

Table 2. Current state assessment – questionnaire.

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

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

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

Phase 2 “Desired State Design”

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

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

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

Phase 3 “Implementation”

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

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

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

Phase 4 “Operations and Review”

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

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

C-2009-3-Wilpshaar-t03

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

Conclusion

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

About Unibail-Rodamco

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

Contractuele en fiscale aspecten bij outsourcing van ICT-beheer & systeemontwikkeling

Outsourcing van ICT is een complexe aangelegenheid waarbij over het algemeen complexe contracten passen. Partijen gaan voor een langere termijn een relatie aan. Hierbij moeten niet alleen voor het begin van de samenwerking afspraken worden gemaakt, maar is het van belang dat partijen vooruitkijken en de gehele sourcingcycle overzien. Contracten dienen de samenwerking te ondersteunen door compleet te zijn voor wat betreft juridische en fiscale afspraken, flexibel waar het gaat om het maken van aanpassingen en helder voor wat betreft de doelstellingen van betrokkenen.[De fiscale aspecten in het artikel zijn afgestemd met de heren M. van Dun en A.G.A. van der Fits, werkzaam bij KPMG Meijburg & Co.]

Inleiding

Het opstellen van een outsourcingscontract is voor veel bedrijven een lastige klus. Hoe vind je de weg in het oerwoud van juridische en fiscale voorwaarden? Hoe leg je als partijen je samenwerking nu adequaat vast en hoe gaat dat in de toekomst? Er zijn verschillende factoren waar je als partijen rekening mee dient te houden. Deze factoren betreffen zowel interne, dat wil zeggen betreffende de outsourcing zelf, als externe aspecten.

Een belangrijk aspect is de complexiteit van outsourcing: hoe complexer de outsourcing, hoe meer risico’s afgedekt moeten worden. Daarnaast zijn zaken als het verloop van een outsourcingsrelatie en het voortschrijdende inzicht van partijen aspecten waarmee rekening gehouden moet worden. Het gaat bij het afsluiten van een outsourcingscontract immers om afspraken voor langetermijndienstverlening. Al te vaak blijkt dat een goede overgang van de dienstverlening naar de nieuwe ICT-leverancier niet in één transitie afgerond kan worden. Gedurende de looptijd van het contract zullen nog tal van activiteiten moeten worden ondernomen om de dienstverlening op een goed niveau te brengen en partijen op een efficiënte manier te laten samenwerken.

Een externe factor is het huidige economische klimaat, dat organisaties noopt om op korte termijn kostenbesparingen te realiseren. Naast deze besparingen gaan bedrijven voor meer zekerheid en minder afhankelijkheid. Deze zaken dienen vertaald te worden naar de af te sluiten overeenkomst.

Ten slotte is er in een aantal gevallen externe regelgeving waar één of beide partijen aan moeten voldoen. Van deze regelgeving is het zaak de impact op het contract vast te stellen en een plek te geven in de overeenkomst.

Dit artikel geeft een handreiking aan organisaties die bezig zijn met het voorbereiden van een outsourcingsdeal. Naast een korte uitleg van de verschillende factoren die van invloed zijn, is een overzicht opgenomen van juridische en fiscale kwesties waar partijen zich op dienen te bezinnen en waarover schriftelijke afspraken moeten worden gemaakt. Tot slot wordt een drietal risico’s beschreven dat zich voor kan doen in de relatie tussen klant en leverancier met een aanbeveling hoe hier contractueel mee om te gaan.

C-2009-3-Sauer-01

Figuur 1. Factoren die van invloed zijn op een outsourcingsovereenkomst.

Factoren die van invloed zijn op de overeenkomst

Invloed van marktomstandigheden

De IT-outsourcingsmarkt staat, gezien de huidige economische omstandigheden, onder druk. Bedrijven zullen bij het uitbesteden vaker op korte termijn een kostenbesparing willen realiseren, hetgeen druk legt op zowel klant als leverancier. Van de leverancier wordt verwacht dat hij IT-diensten van hoge kwaliteit voor een lage prijs levert. Aan de klantzijde heeft de regieorganisatie de verantwoordelijkheid om het outsourcingsproces in goede banen te leiden en om te gaan met de verwachtingspatronen van de interne klant waarbij er minder IT-budget beschikbaar is.

Juist in deze tijden, waarin de focus ligt op kostenbesparing, is het (her)contracteren van outsourcingsdienstverlening een buitengewoon delicate zaak. In een ruimer economisch klimaat zal door partijen minder naar de letter van het contract worden gekeken terwijl dat, nu het economisch slechter gaat, vaker het geval zal zijn.

(Veranderende) regelgeving

Voor organisaties die aan regelgeving onderhevig zijn, bijvoorbeeld de financiële toezichtwetten, is het van belang om de impact van deze wet- en regelgeving op het kavel dat uitbesteed wordt, te bepalen. Van belang is om overeen te komen dat toepasselijke wet- en regelgeving in alle gevallen zal worden gerespecteerd en nageleefd.

Het is zaak dat elke partij de verantwoordelijkheid ten aanzien van de wetconformiteit van haar eigen aandeel in de dienstverlening aanvaardt. In geval van een outsourcing van systeembeheer zal dit voor wat betreft de functionaliteit bij de klant liggen en voor wat betreft het technische beheer bij de leverancier.

Bovendien dienen partijen een voorziening op te nemen hoe omgegaan wordt met wijzigingen in wet- en regelgeving. Wanneer een leverancier zich moet aanpassen om aan de regelgeving te voldoen, kan dit een effect hebben op de kosten van de dienstverlening. Hoe met een dergelijk gegeven om te gaan dient schriftelijk overeengekomen te worden.

Veranderende relatie

Niet alleen de marktomstandigheden hebben invloed op de houding van partijen. Bij het opstellen van een overeenkomst tussen insourcer en outsourcer wordt van beide partijen verwacht dat zij de gehele lifecycle van de sourcing kunnen overzien. Al met al wordt van contractpartijen gevraagd om op basis van een onzekere toekomst een toekomstvast contract af te sluiten. Zeker gezien het feit dat outsourcingsdeals een looptijd hebben van circa vijf tot zeven jaar, is dit een lastige opgave. Samenwerkingsafspraken die bij het afsluiten van het contract adequaat leken, blijken na verloop van tijd inefficiënt of zelfs onwerkbaar.

Juridische & fiscale aspecten in de sourcingcycle

Gedurende de loop van een outsourcingstraject zijn er vele zaken die op juridisch en fiscaal vlak getoetst en nader beschreven dienen te worden. Deze juridische en fiscale aspecten kunnen gekoppeld worden aan een aantal van de fasen van de sourcingcycle. Volledigheidshalve wordt de gehele sourcingcycle (figuur 2) kort omschreven.

C-2009-3-Sauer-02

Figuur 2. De sourcingcycle.

Strategie

In de strategiefase definieert de klant zijn visie op sourcing en een strategie. Vervolgens wordt een business case gemaakt voor een beoogde outsourcing.

Scope & plan

Bij scope & plan wordt de huidige situatie in kaart gebracht en een eventuele belastingstructuur opgezet.

Ontwerp & selectie

Nadat helder is wat de doelstellingen zijn wordt door de klantorganisatie het ‘target operating model’ gedefinieerd en kan de leveranciersselectie plaatsvinden. Wanneer de klantorganisatie zich in de (semi)publieke sector bevindt, is een groot aantal regels van toepassing waaraan deze organisatie zich dient te houden bij het uitbesteden van IT-diensten en het selecteren van een leverancier. Dit betreft voorschriften op basis van zowel Europese als nationale wetgeving op het gebied van aanbestedingen. Dit heeft ook gevolgen voor de leveranciers die willen inschrijven op een aanbesteding, omdat in de regelgeving een groot aantal eisen aan de leveranciers wordt gesteld op bijvoorbeeld financieel gebied of maatschappelijk verantwoord ondernemen.

Nadat marktpartijen hun aanbiedingen hebben gedaan, vindt de leveranciersselectie plaats. Hierbij kan het raadzaam zijn om een due diligence-onderzoek uit te laten voeren om vast te stellen of er geen juridische, fiscale of operationele risico’s zijn die een succesvolle uitvoering van het outsourcingscontract in de weg zouden staan. Indien er geen belemmeringen zijn kunnen partijen overgaan tot het vastleggen van afspraken in een IT-outsourcingscontract.

Raamwerk outsourcingscontract

De definitie van IT-outsourcing geeft een basis voor waar het in een IT-outsourcingscontract over gaat:

Bij IT-outsourcing is sprake van een langdurige contractuele relatie tussen een externe leverancier en een klant, waarbij de externe leverancier, voor een afgesproken tijd en prijs de uitvoering van systeemontwikkeling en/of onderhoud, exploitatie en beheer van één of meer componenten van informatiesystemen van de klant op zich neemt.

Met betrekking tot de dienstverlening wordt door de leverancier een inspanningsverplichting aangegaan of worden, in het beste geval, prestatiegaranties afgegeven, en heeft de klant de verantwoordelijkheid voor de uitbestede dienst(en) en dient hij de controle over de dienstverlening te behouden.

Enkele uitgangspunten voor een raamwerk van een werkbaar outsourcingscontract zijn:

  • Beschrijf in een outsourcingsovereenkomst wat de doelstellingen van partijen zijn, wat de verplichtingen over en weer zijn en onder welke juridische voorwaarden de outsourcing plaatsvindt. Dit document is een statisch document waarbij het doorvoeren van wijzigingen een bewerkelijk proces is.
  • Stel (indien van toepassing) een producten-dienstencatalogus (PDC) op waarin per dienst omschreven staat wat er functioneel geleverd wordt, wat de bijpassende service levels zijn en wat de kosten van de diensten zijn. Dit document zal eveneens via een bewerkelijke changeprocedure moeten kunnen worden gewijzigd.
  • Indien geen PDC wordt opgesteld, wordt vaak één service level agreement geformuleerd waarin uitgeschreven staat welke diensten worden geleverd met welke kwaliteitsafspraken en tegen welke kosten.
  • Stel een dossier ‘afspraken en procedures’ op met hierin werkprocedures en governancestructuren. Dit is een dynamisch werkdocument waarin op een eenvoudige manier wijzigingen kunnen worden aangebracht.
Juridische en fiscale aspecten in een outsourcingscontract
Externe regelgeving

Het kan voorkomen dat het deel van de werkzaamheden dat uitbesteed wordt, onderhevig is aan externe regelgeving. Voor bijvoorbeeld bedrijven in de financiële markt zijn de regels van de toezichthouders AFM en DNB van belang die specifieke eisen stellen aan ICT-systemen en daarmee aan outsourcingscontracten. De leverancier zal in dat geval moeten garanderen dat de klant kan blijven voldoen aan financiële-toezichtwetten.

Intellectueel eigendom & escrow

Zowel bij outsourcing van het beheer van applicaties als van systeemontwikkeling is het van belang om goede afspraken te maken betreffende het intellectueel eigendom van applicaties. Dit geldt in het bijzonder voor gevallen waarin, op kosten van de klant, een leverancier software ontwikkelt. Wanneer standaardsoftware wordt afgenomen, lijkt er niets aan de hand. In de praktijk wordt zeker voor grotere ERP-systemen maatwerk geschreven waarvoor de klant betaalt. Zolang er niets is afgesproken, is de ‘maker’, in dit geval de leverancier, de rechthebbende. In voorkomende gevallen is dat geen wenselijke situatie: de klant betaalt voor het ontwikkelen en de leverancier kan de software vrijelijk exploiteren. Partijen kunnen hiervan afwijken door schriftelijk overeen te komen dat het intellectueel eigendom overgedragen wordt aan de klant.

Mocht afgesproken zijn dat het intellectueel eigendom aan de leverancier toebehoort, dan is het de vraag wat er gebeurt wanneer de leverancier failleert. In dat geval kunnen door middel van een escrowvoorziening afspraken worden gemaakt dat onder bepaalde omstandigheden, zoals faillissement, het intellectueel eigendom overgaat naar de klant. Deze krijgt dan de beschikking over de broncode die door een derde onafhankelijke partij worden gehouden. In een escrowcontract wordt afgesproken wie de partijen zijn, wat er in bewaring wordt gegeven, onder welke omstandigheden het in bewaring gegevene wordt vrijgegeven en worden de gewenste zekerheden vastgelegd.

Privacy en de Wet bescherming persoonsgegevens

Wanneer een onderneming besluit om data te laten hosten en daarmee buiten de deur te plaatsen, zijn onderwerpen als privacy en de Wet bescherming persoonsgegevens (Wbp) van belang. De verwerking van persoonsgegevens, bijvoorbeeld door middel van een personeelsinformatiesysteem, is geregeld in de Wbp. Deze wet stelt regels voor de verzameling en het verdere gebruik van persoonsgegevens ter bescherming van de persoonlijke levenssfeer van degene die deze gegevens betreffen. De Wbp is echter van toepassing voor zover het verwerking van persoonsgegevens betreft. In het kader van aansprakelijkheid dient vastgelegd te worden wie de verwerker van de persoonsgegevens is.

Informatiebeveiliging en geheimhouding

De toegang van een externe partij tot informatie of het verzenden van data over het publieke internet vraagt om goede afspraken omtrent informatiebeveiliging. Daarnaast kent de Wbp een plicht tot informatiebeveiliging.

Informatiebeveiliging wordt in de eerste plaats in een geheimhoudings- en vertrouwelijkheidsclausule vastgelegd, eventueel aangevuld met een boetebepaling. Hiermee worden interne bedrijfsprocessen, klantgegevens of concurrentiegevoelige informatie beschermd. De clausules hebben een werking jegens de medewerkers of de door partijen ingezette derden. Omdat er voor het aangaan van een relatie en tijdens de relatie vertrouwelijke informatie tussen partijen wordt uitgewisseld, is het gewoon om dergelijke clausules ook na eventuele beëindiging van de overeenkomst te eerbiedigen.

Naast de geheimhoudingsclausules biedt de Code voor Informatiebeveiliging 2000 (ISO/IEC 2000) een duidelijke structuur op het gebied van informatiebeveiliging bij outsourcing. Dit is tevens terug te vinden in Itil v3, waarin binnen Informatie Security Management aangegeven is dat contracten en SLA’s moeten refereren aan de Information Security Policy (ITP). Indien van toepassing, voornamelijk bij outsourcing van systeembeheer, zullen partijen het ITP van de klant van toepassing moeten verklaren op de outsourcing.

Inlenersaansprakelijkheid, zelfstandig of in fiscale dienstbetrekking?

Indien een onderneming een outsourcingsdienst inkoopt ofwel IT’ers inleent bij een IT-outsourcingsbedrijf, dan kan de onderneming geconfronteerd worden met de inlenersaansprakelijkheid. Van belang is allereerst om vast te stellen wanneer er sprake is van inlening. Van inlening is sprake indien:

  1. een IT’er zijn dienstbetrekking behoudt bij het IT-outsourcingsbedrijf (de uitlener), en
  2. door het IT-outsourcingsbedrijf ter beschikking wordt gesteld aan een derde (de inlener)
  3. om onder het toezicht of de leiding van de inlener werkzaamheden te verrichten.

Bij de terbeschikkingstelling van de IT’er factureert de uitlener (het IT-outsourcingsbedrijf) aan de inlener. De factuur van het IT-outsourcingsbedrijf omvat met name de loonkosten van de IT’er, een opslag voor kosten en winst, en btw. Het IT-outsourcingsbedrijf moet de op het loon van de ter beschikking gestelde IT’er verschuldigde loonheffingen (loonbelasting, premies volksverzekeringen, premies werknemersverzekeringen en de inkomensafhankelijke bijdrage Zorgverzekeringswet) en de in rekening gebrachte btw afdragen aan de Belastingdienst. Op het moment dat het IT-outsourcingsbedrijf niet aan zijn fiscale verplichtingen voldoet, zal de Belastingdienst in eerste aanleg naheffingsaanslagen loonheffingen en omzetbelasting opleggen aan het IT-outsourcingsbedrijf. Als dit bedrijf deze naheffingsaanslagen niet betaalt, zal de Belastingdienst de inlener aansprakelijk stellen voor de niet-betaalde loonheffingen en omzetbelasting die het IT-outsourcingsbedrijf in verband met het verrichten van de werkzaamheden is verschuldigd. Een dure aangelegenheid voor de inlener, omdat deze de factuur van de uitlener nu ook deels (voor zover deze betrekking had op de loonheffingen en de btw) moet betalen aan de Belastingdienst!

  • Risicobeperkende maatregelen

De inlener kan maatregelen treffen om het risico op aansprakelijkstelling op grond van de inlenersaansprakelijkheid te beperken. Hierbij kan men onder andere denken aan een zorgvuldige selectie van het IT-outsourcingsbedrijf (KvK, NEN 4400-I-certificaat, etc.), opvragen van een accountantsverklaring en het opvragen van een verklaring van betalingsgedrag bij de Belastingdienst. Het treffen van deze maatregelen leidt overigens niet tot de garantie dat de inlener niet aansprakelijk kan worden gesteld. Om dat te bereiken, moet de inlener vrijwarende maatregelen treffen.

  • Vrijwarende maatregelen

De inlener heeft op dit moment twee mogelijkheden tot zijn beschikking om de aansprakelijkstelling (deels) te beperken. De eerste mogelijkheid is het storten van een deel van de factuur van het IT-outsourcingsbedrijf (namelijk het deel dat betrekking heeft op de verschuldigde loonheffingen en btw) op de G-rekening van de uitlener. Dit is echter alleen mogelijk wanneer de uitlener beschikt over een G-rekening. De tweede mogelijkheid is het rechtstreeks storten van het gedeelte van de factuur dat betrekking heeft op de door de uitlener verschuldigde loonheffingen en btw op een rekening van de Belastingdienst. De vrijwaring is beperkt tot ten hoogste het bedrag dat de inlener heeft betaald op de G-rekening dan wel rechtstreeks heeft gestort bij de Belastingdienst. Daarnaast moet een aantal voorwaarden in acht worden genomen voordat de storting op een G-rekening of de rechtstreekse storting tot vrijwaring kan leiden.

Het systeem van G-rekeningen en rechtstreeks storten zal in de toekomst worden vervangen door een depotstelsel. Het wetsvoorstel hiervoor ligt op dit moment voor verdere behandeling bij de Eerste Kamer. De ingangsdatum van het wetsvoorstel is nog niet bekend.

  • De aansprakelijkstelling

De Belastingdienst[Aansprakelijkstelling voor de premies werknemersverzekeringen die betrekking hebben op de jaren vóór 2006, gebeurt door het Uitvoeringsinstituut werknemersverzekeringen.] stelt de inlener aansprakelijk door middel van een beschikking. De inlener kan vervolgens binnen zes weken na de dagtekening van deze beschikking bezwaar maken tegen de aansprakelijkstelling. Tevens kan de inlener bezwaar maken tegen de aan de aansprakelijkstelling ten grondslag liggende belastingaanslag(en). Tegen een afwijzende uitspraak op het ingediende bezwaarschrift kan beroep worden ingesteld bij de rechtbank. Tegen de uitspraak van de rechtbank kan hoger beroep worden ingesteld bij de Belastingkamer van het Gerechtshof. Tegen de uitspraak van het Gerechtshof kan beroep in cassatie worden ingesteld bij de Hoge Raad.

Zelfstandigen zonder personeel
  • Beoordeling arbeidsrelatie

Het kan voorkomen dat een bedrijf IT’ers inschakelt die hun vak als zogenoemde zelfstandige zonder personeel (zzp’er/freelancer etc.) uitoefenen. Zulke freelance IT’ers kunnen tegenover een opdrachtgever een dermate zelfstandige positie innemen dat deze niet verenigbaar is met een dienstbetrekking. Het kan ook zijn dat de omstandigheden waaronder zij werken een dusdanig afhankelijke positie van de opdrachtgever met zich meebrengen dat een dergelijke arbeidsverhouding gelijkgesteld wordt met een dienstbetrekking.

De feiten moeten uitwijzen of er sprake is van een dienstbetrekking en of loonheffingen moeten worden ingehouden en afgedragen. Als uitgangspunt geldt vrijwel altijd dat het inlenende bedrijf te allen tijde wil voorkomen dat het bij inhuur van freelance IT’ers achteraf als inhoudingsplichtige wordt aangemerkt.

  • Verklaring Arbeidsrelatie (VAR)

Als een inlenend bedrijf gaat werken met freelance IT’ers, ligt het voor de hand dat het inlenende bedrijf de freelance IT’er vóór aanvang van de werkzaamheden verzoekt om een VAR te overleggen.

Op verzoek van de freelance IT’er verstrekt de Belastingdienst namelijk een beschikking die aangeeft of bepaalde inkomsten naar het oordeel van de Belastingdienst voor de toepassing van de loonheffingen zijn te kwalificeren als: a. winst uit onderneming, b. inkomsten die voor rekening en risico zijn van een vennootschap, c. loon uit dienstbetrekking of d. resultaat uit overige werkzaamheden. Het verzoek aan de Belastingdienst kan leiden tot vier verschillende Verklaringen Arbeidsrelaties:

  1. een verklaring van de inspecteur dat de voordelen die de opdrachtnemer geniet uit arbeidsrelaties met dezelfde soort werkzaamheden en die onder overeenkomstige condities zijn aangegaan worden aangemerkt als ‘winst uit onderneming’ (VAR-WUO);
  2. een verklaring van de inspecteur dat de voordelen voor rekening en risico zijn van de vennootschap (VAR-DGA);
  3. een verklaring van de inspecteur dat de voordelen die de opdrachtnemer geniet uit arbeidsrelaties met dezelfde soort werkzaamheden en die onder overeenkomstige condities zijn aangegaan, worden aangemerkt als resultaat uit overige werkzaamheden (VAR-resultaat);
  4. een verklaring van de inspecteur dat de voordelen die de opdrachtnemer geniet uit arbeidsrelaties met dezelfde soort werkzaamheden en die onder overeenkomstige condities zijn aangegaan, worden aangemerkt als loon uit dienstbetrekking (VAR-loon).

De VAR-verklaring geeft zekerheid aan het inlenende bedrijf en de freelance IT’er. Het inlenende bedrijf wordt gevrijwaard van naheffingen loonheffingen als aan de volgende voorwaarden is voldaan:

  1. de freelance IT’er heeft voor de werkzaamheden die bij het inlenende bedrijf worden uitgevoerd, een VAR-WUO of een VAR-DGA getoond;
  2. het inlenende bedrijf beschikt over een kopie van die VAR; en
  3. het inlenende bedrijf heeft de identiteit van de freelance IT’er vastgesteld aan de hand van een geldig identiteitsbewijs en heeft een afschrift van dat geldige identiteitsbewijs in zijn administratie opgenomen.

Als aan vorenstaande voorwaarden wordt voldaan, dan wordt geen (fictieve) dienstbetrekking aangenomen met uitzondering van de gevallen waarin:

  1. een VAR is gebruikt waarvan de geldigheidsperiode is verstreken;
  2. de VAR is afgegeven voor andere opdrachten dan waarvoor hij is gebruikt;
  3. een vervalste VAR is gebruikt.

In deze gevallen kan alsnog de aanwezigheid van een (fictieve) dienstbetrekking worden geconstateerd.

Let op!

Slechts als een VAR-WUO of VAR-DGA is afgegeven, wordt de freelance IT’er niet geacht in (fictieve) dienstbetrekking te staan tot het inlenende bedrijf. Dit betekent dat slechts wanneer een geldige VAR-WUO of VAR-DGA wordt overgelegd, geen loonheffingen worden ingehouden en afgedragen door het inlenende bedrijf. In alle andere gevallen (VAR-resultaat of VAR-loon) is het aan te raden om loonheffingen in te houden.

  • Schriftelijke overeenkomst van opdracht

Het is aan te raden dat een overeenkomst met een freelance IT’er schriftelijk wordt overeengekomen. In de schriftelijke overeenkomst worden de gemaakte afspraken tussen de freelance IT’er en het inlenende bedrijf bekrachtigd.

Transitie

In de transitiefase wordt de dienstverlening overgezet naar de leverancier. De servicemanagementprocessen en het governancemodel krijgen hun definitieve vorm. Naast het implementeren van een riskmanagementplan kan vorm worden gegeven aan een transformatieplan. Een specifieke situatie die zich in transitie voordoet is wanneer naast activiteiten en/of systemen, ook medewerkers overgaan.

Overgang van onderneming

Bij outsourcing kan er sprake zijn van overgang van onderneming volgens artikel 7:662 BW, hetgeen grote gevolgen heeft voor zowel inbesteder als uitbesteder. Een overgang van onderneming heeft als belangrijkste gevolg dat overgang van arbeidsovereenkomsten van medewerkers in bereik van de over te nemen dienstverlening, van rechtswege plaatsvindt. Hierbij geldt dat zowel de overnemer als overdrager een aantal verplichtingen moet naleven.

De overnemer heeft de plicht om de medewerkers die overkomen hun rechten en plichten uit arbeidsovereenkomst en cao te garanderen. De overdrager is hoofdelijk aansprakelijk voor verplichtingen tegenover medewerkers die zijn ontstaan voor de datum van de overname. Een medewerker kan tot een jaar na de overname niet alleen de nieuwe werkgever aanspreken maar ook de vorige werkgever voor het niet nakomen van verplichtingen van voor de overname.

Het is van groot belang om de afspraken omtrent personeel in een vroeg stadium goed vast te leggen zodat helder is om welke medewerkers het gaat, en welke arbeidsvoorwaarden van toepassing zijn met de daaraan verbonden kosten.

Levering

Voor de levering is het van belang om in het contract aandacht te besteden aan afspraken over de dienstenniveaus en governance-afspraken.

Tevens dient te worden voorzien in herhaaldelijke evaluaties ten aanzien van de governancestructuur, de service levels en klantentevredenheid. Compliancy ten aanzien van het contract en interne & externe regelgeving wordt eveneens op regelmatige basis gemeten.

Verbetering

In de fase van verbetering is er een drietal mogelijkheden waaruit verschillende acties voortvloeien en waarin contractueel dient te worden voorzien.

De eerste constatering kan zijn dat de uitvoering en naleving van het contract naar inzicht van partijen naar wens verlopen. In dat geval is geen actie noodzakelijk.

Een andere constatering, en dat is meestal van toepassing, is dat de uitvoering en naleving van het contract niet (geheel) naar tevredenheid van één of beide partijen verloopt. In dat geval worden hernieuwde afspraken gemaakt en dienen contractuele verbeteringen te worden doorgevoerd. Hiervoor is de eerdergenoemde flexibiliteit in het contract noodzakelijk zodat er ruimte is om te verbeteren en partijen niet tegen beter weten in elkaar aan eerder gemaakte en niet haalbare afspraken gaan houden.

Door flexibiliteit te faciliteren kan tevens rekening worden gehouden met zich wijzigende omstandigheden die invloed hebben op de outsourcingsrelatie. In het bijzonder het laatste is een punt dat regelmatig wordt genegeerd. Bij het aangaan van een dergelijk groot en risicovol contract is naast een transitietraject vaak sprake van een transformatietraject waarbij een groot aantal (proces)verbeteringen wordt doorgevoerd. Dit kan impact hebben op dienstenniveaus, op kosten of op governance-afspraken. Een contract dient zodanig opgesteld te worden dat het kan meegroeien met de relatie.

De laatste constatering kan zijn dat het niet zinvol is om de outsourcingsrelatie in stand te houden. Eén van de partijen of beide partijen beëindigen de overeenkomst of laten deze ontbinden via een gerechtelijke procedure. Op dat moment treedt een exitscenario in werking. Bij het afsluiten van het contract is het raadzaam dit goed uitgewerkt te hebben. Zeker wanneer partijen niet in goede harmonie – en dat is meestal het geval – uit elkaar gaan en zaken betreffende exit niet goed geregeld zijn, escaleert de situatie en kunnen kosten en ergernis hoog oplopen. Goede exitafspraken omvatten minimaal de volgende aspecten:

  • de datum waarop de exit gereed moet zijn en (financiële) afspraken over continuering van de dienstverlening wanneer deze datum niet gehaald wordt;
  • een overzicht van zaken die overgedragen moeten worden, waarbij te denken valt aan hardware, software, data, processen, procedures, blauwdrukken en alle intellectueel eigendom van de klant en eventueel personeel indien sprake is van overdracht van onderneming;
  • de verdeling van de kosten van de transitie;
  • de inzet van de leverancier bij de transitie naar de klant of een derde partij.

Risico’s in de relatie

Bij het contracteren van outsourcingsdiensten maar ook gedurende de looptijd van de dienstverlening kunnen zich, naast risico’s in de operationele sfeer, risico’s manifesteren in de relatie tussen klant en leverancier. Ook deze kunnen door goede contractuele afspraken worden voorkomen.

Risico: waardetoevoeging

Het blijkt lastig om de daadwerkelijke waardetoevoeging van een outsourcing te bepalen. Organisaties blijken nauwelijks in staat te bepalen in welke mate de outsourcing bijdraagt aan het halen van de bedrijfsdoelstellingen, laat staan het vertalen daarvan naar betrokken afdelingen. Dit bemoeilijkt het creëren van een goed draagvlak om daarmee de outsourcing soepel te laten verlopen. Zeker als de geleverde diensten en dienstenniveaus niet in lijn zijn met de verwachtingen van de organisatie wordt het enthousiasme om de outsourcing te laten slagen al snel minder.

Om duidelijkheid te scheppen tussen partijen en ten behoeve van het creëren van een draagvlak zijn het hebben van een heldere strategie waaraan een business case ten grondslag ligt en een goede communicatie naar de interne organisaties noodzakelijk. Het delen van deze strategie en de wederzijdse doelstellingen vormen de basis van de samenwerking tussen partijen. Contractueel worden wederzijdse afspraken gemaakt waarin partijen gedurende de looptijd de business case bijstellen, deze delen en in onderling overleg treden indien bij één of beide partijen grote afwijkingen ontstaan. Door afspraken hieromtrent schriftelijk vast te leggen, wordt partijen minimaal een platform geboden om afwijkingen bespreekbaar te maken.

Risico: verlies van kennis en skills

Een ander risico is het verlies van kennis en skills binnen de klantorganisaties. Door de outsourcing lijkt de noodzaak om kennis in huis te houden niet meer aanwezig. Hiermee is het voor de klantorganisatie onmogelijk om op korte of middellange termijn zelf de dienstverlening weer ter hand te nemen. Dit creëert een afhankelijkheid van de leverancier en vermindert de flexibiliteit om van leverancier te wisselen. De leverancier heeft hiermee een machtsmonopolie, waarbij het risico bestaat dat de kosten toenemen zonder dat de klant hierop invloed kan uitoefenen.

Dit noopt een klantorganisatie om goede afspraken te maken, waarbij leverancier en klant zoveel mogelijk kennis met betrekking tot het contract, de processen, procedures, werkafspraken en techniek gezamenlijk beschikbaar en geactualiseerd houden. Deze kennis wordt vastgelegd in een centraal kennissysteem waartoe alle partijen toegang hebben. De afspraken dienen afdoende vastgelegd te worden in de overeenkomst tussen partijen waarin duidelijk beschreven is om welke kennis het gaat, wat de kwaliteit van de vastlegging moet zijn, met welk tijdsinterval de kennis geactualiseerd moet worden en hoe en wanneer audits plaatsvinden.

Risico: interpretatieverschillen

Door onduidelijke contracten en SLA’s ontstaan vaak interpretatieverschillen die leiden tot discussies over verdeling van kosten en aansprakelijkheid. Discussies over meerwerk zijn dan aan de orde van de dag en waar een organisatie denkt een goede deal te hebben gedaan door strakke prijsafspraken te maken, blijkt de financiële teller aan het einde van de looptijd hoger te staan dan bedoeld.

Door het maken van afspraken over het uitvoeren van audits en evaluaties op regelmatige basis, worden onduidelijkheden of misinterpretaties helder en kan er naar een oplossing worden gezocht. Dit laatste wordt ondersteund door een volwassen manier van dispuutoplossing. Een goede mogelijkheid hiervoor is het bijhouden van een issuelog en de procedure inzake dispuutoplossing vast te leggen in de overeenkomst. Een praktische invulling daarvan is partijen een ‘negotiation dispute document’ te laten opstellen bevattende a. het issue, b. de opinie van beide partijen met referentie naar de betreffende contractclausules, en c. een aantal scenario’s die leiden tot oplossing met daarbij de financiële consequenties. Het oplossen van deze kwesties kan dan plaatsvinden in een commerciële setting waarbij de dagelijkse dienstverlening niet vertraagd of verstoord wordt.

Conclusie

Het opstellen van outsourcingscontracten behoeft veel aandacht en voorbereiding. Hoe meer voorbereiding er tijdens de ‘ontwerpen en selecteren’-fase wordt gedaan, hoe eenvoudiger het maken van een contract is. Een groot aantal zaken kan al in een Request for Proposal of offertetraject geadresseerd worden zodat potentiële leveranciers er reeds op kunnen inspelen.

Hierbij is het raadzaam om op juridisch en fiscaal vlak een goede analyse te laten uitvoeren om vast te stellen welke aspecten van toepassing zijn en waarover derhalve met een leverancier afspraken gemaakt dienen te worden.

Voor het vormgeven van afspraken betreffende het samenwerkingsmodel, regelmatige audits en evaluaties, is het zaak om dit in een vroeg stadium aan de orde te stellen. Juist deze afspraken mogen geen sluitstuk van het contract worden om risico’s als gevolg van interpretatieverschillen en inflexibiliteit te voorkomen. Deze risico’s zullen zich wellicht niet direct manifesteren maar gezien de lange looptijd en het strategisch belang dienen partijen de afspraken adequaat vast te leggen en te blijven evalueren.

Literatuur

Platform Outsourcing Nederland, Juridische aspecten van outsourcing, Rapportage werkgroep juridisch PON, 2006.

Mr. Robert Grandia, Juridische kant van informatiebeveiliging, ICT Office, 2008.

Louk Peters, Maarten Bordewijk en Jeroen Ermers, De kleine ITIL v3, Academic Services, 2008.

André Faas en Hans Hendriks, Strategische (out)sourcing van ICT, Academic Services, 2005.

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

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

Inleiding

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

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

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

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

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

Horizontaal toezicht en handhavingsconvenant

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

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

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

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

Tax Control Framework

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

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

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

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

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

Voordelen TCF

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

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

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

Het ontwikkelen van een Tax Control Framework

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

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

C-2009-3-Peters-t01

Tabel 1. TCF-methodiek.

Fase 1 Planning

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

Fase 2 Inzicht

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

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

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

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

Fase 3 Ontwerp

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

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

Fase 4 Implementatie

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

Fase 5 Monitoring

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

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

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

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

Integratie TCF en BCF tot één platform

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

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

C-2009-3-Peters-01

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

Ondersteuning door geautomatiseerde tools

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

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

C-2009-3-Peters-02

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

C-2009-3-Peters-03

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

De rol van ERP-systemen

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

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

C-2009-3-Peters-04

Figuur 4. Speelveld van fiscale controls.

C-2009-3-Peters-t02

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

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

Praktische tips voor het succesvol opzetten van een TCF

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

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

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

Literatuur

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

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

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

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

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

Older posts
Newer posts