Skip to main content

Globalisering, een opportunity voor de IT-auditor

Organisaties krijgen steeds meer een internationaal en globaal karakter. Deze trend heeft invloed op de IT-omgeving en dus op de (IT-)audit en advisering hiervan. Het kan echter ook zijn dat technologische ontwikkelingen ook mogelijkheden scheppen op het gebied van globalisering. Denk bijvoorbeeld aan de invloed van breedbandinternet op de samenleving en organisaties.

Globalisering zal dus aanpassingen van de IT-auditor vragen, maar zeker ook leiden tot nieuwe mogelijkheden en uitdagingen op het IT-auditvakgebied.

Inleiding

Globalisering en internationalisering zijn tegenwoordig vaak gebruikte termen om aan te geven dat de wereld steeds kleiner wordt en bijna iedereen met elkaar in verbinding staat. Dit is vooral het gevolg van de voortdurende technologische ontwikkelingen, die leiden tot nieuwe mogelijkheden, zoals goedkoop breedbandinternet en een wereldwijde 24 maal 7 ‘BlackBerry’-werkplek. Ook de ontwikkelingen in en invloed van de emerging markets, waaronder de BRIC-landen (Brazilië, Rusland, India en China), hebben globalisering bij veel organisaties op de kaart gezet.

Globalisering en technologische ontwikkelingen hebben natuurlijk ook invloed op de wijze waarop organisaties met hun strategie en IT omgaan. Doordat breedbandinternet, opslagmedia en snellere IT-systemen steeds goedkoper worden, kiezen organisaties er bijvoorbeeld meer en meer voor om hun IT (bijvoorbeeld ERP-systemen) verder te standaardiseren en centraliseren. Deze ontwikkelingen hebben vaak ook een verandering van risicoprofiel tot gevolg. Bij veel kleine lokale systemen zal de op het optreden van een probleem of calamiteit groter zijn, maar is de impact op de totale bedrijfsvoering kleiner. Bij grote gecentraliseerde systemen is de kans op optreden wellicht kleiner, maar is de impact des te groter. Deze standaardisatie en centralisatie van IT zal ook invloed hebben op de wijze waarop de IT-audit- of advieswerkzaamheden worden uitgevoerd.

In dit artikel worden de invloed en eventuele uitdagingen van globalisering met een IT- en IT-auditinvalshoek toegelicht. Hierbij zal tevens kort worden ingegaan op de artikelen die in dat kader in deze Compact zijn opgenomen.

Gevolgen van en mogelijkheden voor globalisering ten aanzien van IT en audit

Om een analyse te maken van de status van de IT-omgeving of een groeipad van (IT-)veranderingen te definiëren wordt vaak het Nolan Norton-groeiprocessenraamwerk gebruikt ([Nola79]). Dit raamwerk is reeds gepubliceerd in de jaren tachtig, lang voordat de term globalisering bestond, maar wordt tegenwoordig nog veelvuldig toegepast.

Het raamwerk bestaat uit een viertal processen, namelijk Management & Organisatie, Processen & Applicaties, Infrastructuur en Mensen & Cultuur. De mate van beheersing en volwassenheidsniveau van deze processen afzonderlijk en de balans tussen de processen heeft invloed op de performance dan wel kosten/baten van IT binnen een organisatie. Het raamwerk kan ook worden gebruikt in het kader van globalisering. De vier groeiprocessen zullen invloed hebben op de globalisering (bijvoorbeeld breedbandinternet), maar ook zal globalisering invloed hebben op de ontwikkelingen van deze vier groeiprocessen (internationalisering strategie van een organisatie). In figuur 1 is deze wisselwerking afgebeeld met behulp van de pijlen van en naar het blokje ‘Globalisering’.

C-2006-3-Veld-01

Figuur 1. Globalisering: impact én trigger.

(Naar [Nola79].)

Globalisering en de ontwikkelingen op de vier groeiprocessen zullen invloed hebben op hoe organisaties met hun IT omgaan en dus ook invloed hebben op en uitdagingen zijn voor het IT-auditberoep.

Management & Organisatie

Groeien is het strategische sleutelwoord voor organisaties, hetzij via autonome groei, dan wel via fusies of overnames. Organisaties kunnen ook niet achterblijven bij het uitbreiden naar de emerging markets. Niet alleen voor het outsourcen van bedrijfsprocessen of IT-afdelingen (bijvoorbeeld India), maar ook voor de productie of afzetmarkt (bijvoorbeeld China). Deze expansiedrift heeft natuurlijk impact op de IT-strategie. Hierbij zijn efficiency en kostenreductie essentieel door niet alleen de IT-omgeving, maar ook bedrijfsprocessen verder te concentreren en te centraliseren in onder meer shared service centers. Deze ontwikkelingen hebben invloed op de wijze waarop IT-auditwerkzaamheden worden uitgevoerd. Was het vroeger zo dat alle organisatieonderdelen een afgebakende auditscope hadden, tegenwoordig zien we dat het factuurafhandelingsproces uitgevoerd wordt door een shared service center in Polen, de ERP-applicatie beheerd wordt in Nederland en het datacenter fysiek in Brazilië staat, maar remote beheerd wordt vanuit India. Dit opknippen van processen heeft een zeer directe invloed op de wijze van beheersing door de organisatie, maar natuurlijk ook op de scope en aanpak voor de IT-audit van de general IT en de application controls. In het artikel ‘Internationalisatie van leasemaatschappijen: groeien én snoeien’ belicht Wolters deze trend vanuit de leasemarkt. Hierbij wordt de impact van de internationale bedrijfsstrategie op de IT-strategie beschreven en de impact daarvan op de IT-audit van deze organisaties.

Globalisering is ook van toepassing op IT-projecten, bijvoorbeeld voor de implementatie van internationale wet- en regelgeving zoals Sarbanes-Oxley, grote procesverbeteringsprojecten of wereldwijde ERP-implementaties. Deze projecten vinden per definitie op ‘corporate’niveau plaats. De beheersing en het welslagen van zulke corporateprojecten vragen om een gedegen aanpak en vaak ondersteuning van een IT-auditor.

Ook nog dichter bij het IT-auditberoep heeft de globalisering toegeslagen. Tijdens de extra Algemene Vergadering van NOREA op 13 juli 2006 is ingestemd met de aanvaarding van de ‘Code of Ethics voor IT-auditors’ ter vervanging van het Reglement Gedrags- en Beroepsregels Register EDP-Auditors (GBRE). In het artikel van Kloosterman en De Kiewit wordt deze code, die is afgeleid van de Code of Ethics van de International Federation of Accountants (IFAC), toegelicht. In het artikel wordt ingegaan op het feit dat de code uitgaat van een sterke verantwoordelijkheid van de IT-auditor zelf, waardoor de implementatie meer is dan alleen het uitgeven van een boekje aan de register IT-auditors.

Processen & Applicaties

De reeds aangehaalde concentratie en centralisatie van organisatieonderdelen en daardoor bedrijfsprocessen heeft natuurlijk een directe invloed op de applicaties en IT-systemen. Organisaties willen de bedrijfsprocessen verder standaardiseren en uniformeren en met behulp van een ‘template’ de (ERP-)applicatie gestandaardiseerd uitrollen over de gehele wereld. Vaak wordt aan een dergelijk ERP-systeem de term kernel gegeven, omdat tachtig procent van de functionaliteit voor alle organisatieonderdelen gelijk is en niet meer snel zal veranderen. De overige twintig procent functionaliteit zal specifiek gecustomized dienen te worden om aan de lokale specificaties voor fiscale en wettelijke regelgeving te kunnen voldoen.

De implementatie van een dergelijk ERP-pakket vraagt naast een beheerst project (zie ook onder Management & Organisatie) een flexibele, schaalbare en internationaal georiënteerde applicatie. In het artikel ‘Leasingsoftware: een internationaal gezelschap op een internationaal speelveld’ geven Hoffman, Peeters en Wolters een overzicht van het aanbod van automotive- en equipement-leasesoftware en gaan zij kort in op het internationale karakter.

Grote internationale applicaties brengen navenante risico’s met zich mee. Het belang van een effectieve beheersing van processen binnen dergelijke applicaties is dan ook uitermate groot. Vooral als het kritieke processen betreft zoals het gecentraliseerde betalingsproces. In het artikel ‘Elektronisch bankieren met OfficeNet’ van Van Houwelingen wordt in eerste instantie vanuit een praktische invalshoek ingegaan op de risico’s en maatregelen van een kleine betalingsorganisatie. Het blijkt namelijk dat de meeste risico’s blijven bestaan bij de inrichting van een gecentraliseerde betalingsorganisatie, echter de implementatie van de maatregelen is complexer. Een mooie uitdaging als audit- of ondersteuningstraject voor een IT-auditor.

Infrastructuur

In de inleiding is reeds aangegeven dat technologische ontwikkelingen een aanjager kunnen zijn voor de globalisering. Als voorbeelden zijn het breedbandinternet en de ‘BlackBerry’-werkplek genoemd. Deze ontwikkeling kan echter ook risico’s met zich meebrengen voor de beveiliging en beheersing van de technische infrastructuur. Dat geldt vooral op het gebied ‘wie ben jij’ en ‘wat mag jij’, de simpele betekenis van ‘Identity & Access Management’, afgekort ‘I AM’. In het artikel ‘Globalisering en de complexiteit van logische toegang’ gaan Hermans, Van Ham en Ter Hart onder andere in op het inzetten van ‘I AM’ om operational excellence (efficiënt autorisatieaanvragen automatiseren) en compliance (voldoen aan regelgeving) te bereiken. Wellicht kan zelfs gesteld worden dat een globaal ‘I AM’-concept kan worden gezien als een randvoorwaarde voor het verder globaliseren van organisaties.

Een andere ontwikkeling is het verder onderbrengen van IT-processen binnen shared service centers of zelfs het outsourcen van de processen. Beide vormen hebben invloed op de wijze van beheersing door de organisaties. De concentratie van IT-processen op een en dezelfde plek kan net als bij de applicaties leiden tot een hogere impact en dus risico. In dat kader zullen de noodzakelijke ‘in control’-statements, zoals een SAS70-verklaring voor onder andere Sarbanes-Oxley, ook hoog op het ‘to do’-lijstje van de IT-auditor blijven staan.

Mensen & Cultuur

Bij globalisering wordt vaak in eerste instantie gedacht aan verre reizen en culturen. Het succesvol uitvoeren van internationaal project valt of staat met de samen- en wisselwerking tussen verschillende culturen. De eigenwijze Nederlander, de hiërarchische Duitser, de geregelde Chinees, de patriottistische Amerikaan, de degelijke Engelsman, enzovoort dienen in een internationaal project samen te werken. De Grooth belicht de bedrijfscultuur vanuit zijn meer dan veertigjarige internationale ervaring. Hij sluit zijn betoog af met een drietal praktische adviezen, die iedere internationale werknemer ter harte dient te nemen.

Ook integer handelen is een randvoorwaarde voor samenwerking in en tussen organisaties. Echter, door het internationale karakter van organisaties is het vaststellen van dé ‘integriteit’ en het managen ervan binnen een organisatie vaak niet eenvoudig. Kloosterman en De Kiewit lichten integriteit vanuit verschillende invalshoeken toe. Er wordt ook ingegaan op de integriteitthermometer, een geautomatiseerde tool die binnen een organisatie internationaal de integriteit kan vaststellen en monitoren. Eventuele afwijkingen van de benchmark kunnen worden geïdentificeerd en worden aangepakt.

Conclusie

Bij de term internationale IT-audit wordt vaak in eerste instantie gedacht aan het aspect reizen inclusief de kennismaking met andere culturen, en in mindere mate aan de mogelijkheden en uitdagingen op het gebied van de IT-audit zelf.

Door de internationalisering en globalisering zullen organisaties hun IT-omgeving ‘globaliseren’ op het gebied van Management & Organisatie, Processen & Applicaties, Mensen & Cultuur en Infrastructuur. Deze ontwikkeling zal een verandering opleveren voor de aanpak en methodieken van de IT-auditor en -adviseur, maar zij zal zeer zeker ook tot opportunities kunnen leiden op het vakgebied van de IT-audit.

Literatuur

[Nola79] R.L. Nolan, Managing the Crises in Data Processing. Harvard Business Review 57, no. 2, March-April 1979.

NOREA Code of Ethics globaal toepasbaar?

In juli 2006 is de vernieuwde Code of Ethics ingevoerd voor alle register EDP-auditors. De Code of Ethics vervangt de gedrags- en beroepsregels voor EDP-auditors. Integriteit, onafhankelijkheid en objectiviteit zijn belangrijke waarden voor auditors. Dit artikel gaat na hoe deze code kan bijdragen aan het vasthouden van het integriteitsniveau van de IT-auditors. Daarnaast komt aan de orde hoe een goede implementatie van de Code of Ethics nog verder kan bijdragen tot een groter integriteitsbesef binnen de beroepsgroep van register EDP-auditors.

Inleiding

Een integere reputatie wordt door veel ondernemers als belangrijke bestaansvoorwaarde gezien. Desondanks zijn er diverse voorbeelden van ondernemingen die zich toch te buiten gaan aan fraudes, boekhoudschandalen, witwasoperaties, corruptie en dergelijke. Een standaardreactie op dit soort incidenten is om over te gaan tot het instellen van nieuwe interne en externe regelgeving. Binnen een bedrijf worden dan bijvoorbeeld naar aanleiding van een incident de AO-beschrijvingen uitgebreid met extra controles en regels. Een vorm van uitbreidende externe regelgeving is de Sarbanes-Oxley wet. Als reactie op de geruchtmakende boekhoudfraudes in de Verenigde Staten werd deze wet geïntroduceerd. De Sarbanes-Oxley wet stelt vele verplichtingen aan bedrijven die beursgenoteerd zijn.

Een andere reactie op incidenten is dat er gedragscodes worden ingesteld. Een voorbeeld hiervan is de NOREA Code of Ethics voor register EDP-auditors. Deze code sloot aan bij de internationale IFAC Code of Ethics. Voor de NOREA waren het dus niet zozeer incidenten in Nederland die de aanleiding vormden voor het opstellen van een gedragscode, maar het zoeken van aansluiting bij een internationaal aanvaarde code. Door het uitvaardigen van deze code weten register EDP-auditors wat er van hen verwacht wordt op basis van een internationaal breed geaccepteerde standaard. Een code schept op deze manier dus duidelijkheid voor de beroepsbeoefenaren maar ook voor de externe omgeving. Alhoewel een gedragscode een goed instrument is om integriteit te bevorderen zijn hier ook wel wat opmerkingen bij te plaatsen. Een code is natuurlijk alleen nog maar een stuk papier, het gaat om de toepassing in de praktijk. Daarnaast is het de vraag of regels wel zo uniform toegepast kunnen worden als op het eerste gezicht lijkt. In de praktijk blijkt namelijk keer op keer dat mensen binnen organisaties zich niet zozeer door regels laten leiden, maar door hun eigen morele oordeel, of het morele oordeel van hun leidinggevende. Het zou natuurlijk ideaal zijn als de nieuwe code de auditors kan helpen om die morele afweging beter te maken.

In juli 2006 is de nieuwe Code of Ethics ingevoerd voor alle register EDP-auditors. Dit artikel gaat na hoe deze code kan bijdragen aan de integriteit van de IT-auditors. Hoe een goede implementatie van de Code of Ethics kan stimuleren tot een groter integriteitsbesef binnen de beroepsgroep van register EDP-auditors, komt eveneens aan de orde.

Integriteit als kwaliteitsbegrip en als ethisch uitgangspunt

Integriteit is als begrip lastig te definiëren. Het begrip integriteit is afgeleid van het Latijnse woord ‘in-tangere’, dat kan worden vertaald als ‘niet aanraken’ of ‘niet aangeraakt zijn’. Het verwijst met andere woorden naar iets wat, of iemand die, onbesmet, onaangetast en ongekreukt is. Het woordenboek spreekt van ‘rechtschapenheid’, ‘onomkoopbaarheid’ en ‘ongeschondenheid’. Integriteit wordt vaak in één adem genoemd met voorbeelden van wat het niet is: fraude, corruptie. Dit maakt van integriteit al snel een beladen onderwerp. Integriteit is echter juist ook een positief begrip omdat het gaat om zaken als authenticiteit, oprechtheid en heelheid.

EDP-auditors kennen integriteit vaak als kwaliteitsbegrip. Hierbij gaat het om een aspect waaraan toetsing kan plaatsvinden. Met het kwaliteitsaspect (data-) integriteit wordt de consistentie en juistheid van gegevens bedoeld. Integriteit wordt dan gedefinieerd als de mate waarin het object (gegevens en informatie-, technische en processystemen) in overeenstemming is met de afgebeelde werkelijkheid.

Binnen de beroepsgroep van EDP-auditors is er natuurlijk ook aandacht voor integriteit als ethisch uitgangspunt. Dit is zelfs opgenomen in de Code of Ethics voor EDP-auditors (zie kader 1).

Kader 1. De Code of Ethics in Nederland aanvaard.

Algemene Vergadering NOREA stemt in met Code of Ethics

Tijdens de extra Algemene Vergadering op 13 juli 2006 is ingestemd met de aanvaarding van de Code of Ethics voor IT-auditors ter vervanging van het Reglement Gedrags- en Beroepsregels Register EDP-Auditors (GBRE). Daarnaast heeft het bestuur een mandaat gekregen om de statuten en overige reglementen overeenkomstig aan te passen, d.w.z. verwijzingen naar de GBRE worden vervangen door verwijzingen naar de Code of Ethics. De Code of Ethics geldt derhalve met ingang van 14 juli 2006.

In deze code staat het begrip integriteit als apart artikel vermeld (Section 110). Het is zeer toe te juichen dat er binnen de beroepsgroep van register EDP-auditors wordt gestreefd naar uniforme, breed gedragen ethische uitgangspunten. Toch is het belangrijk om zich te realiseren dat de wereldwijde toepasbaarheid van een code gebonden is aan de specifieke context van elke auditor.

De context als bepalende factor voor het handelen

Het begrip integriteit als ethisch richtsnoer is zeer bewonderenswaardig, het is echter belangrijk te bedenken dat integriteit tegelijkertijd toch een wat subjectief begrip is. Wat de ene persoon volstrekt integer vindt zal voor iemand anders ‘not done’ zijn. Het begrip wordt dus door personen anders ervaren en ingevuld. Iedereen heeft er een beeld bij maar dit beeld is niet voor iedereen gelijk. Daar komt nog eens bij dat wanneer mensen geconfronteerd worden met een lastige beslissing, zij die keuze vaak maken op basis van intuïtie en gevoel, en niet zozeer op basis van regelgeving. Het meest treffende voorbeeld hiervan is het experiment van de psycholoog Milgram. Hij liet zien dat wanneer mensen in een bepaalde context geplaatst worden ze dingen doen die volstrekt niet-integer zijn (zie kader 2). Het stellen van regels wil dus geenszins zeggen dat daarmee er voldoende waarborgen zijn voor ethisch gedrag.

Kader 2. Het experiment van Milgram.

Vanuit de psychologie is op verschillende manieren onderzoek gedaan naar het volgen van autoriteit. Het beste en misschien wel meest extreme voorbeeld is het experiment van Milgram. In dit experiment werd de bereidheid van deelnemers gemeten om aanwijzingen op te volgen van een autoriteit, zelfs als die aanwijzing in strijd was met het eigen geweten.

Milgram vroeg proefpersonen om mee te werken aan een onderzoek naar het effect van elektrische shocks op het geheugen. De proefpersoon moest daarbij stroomschokken toedienen aan een andere proefpersoon (die in werkelijkheid een acteur was: er werden helemaal geen stroomschokken toegediend). Het onderzoek wilde bekijken tot op welk niveau mensen hun eigen geweten ondergeschikt maakten aan de autoriteit van de onderzoeker die het experiment leidde. De proefpersoon werd dus door de onderzoeker verteld wat de proefpersoon moest doen. Het experiment onderzocht dus in werkelijkheid de relatie tussen gehoorzaamheid en autoriteit en tot welk niveau men het eigen morele geweten boven de autoriteit zou stellen.

Verbazingwekkend veel mensen zouden de proefpersoon blootstellen aan zeer hoge, gevaarlijke en zelfs dodelijke stroomschokken.1 Alhoewel andere psychologen vooraf dachten dat slechts een paar sadisten bereid zouden zijn om het maximumvoltage van 450 volt te geven, waren de resultaten zeer schokkend. Bij de eerste reeks experimenten gaf 65 procent van deelnemers de maximumschok van 450 volt, hoewel velen zich er zeer ongemakkelijk bij voelden. Geen deelnemer hield op vóór het 300 volt-niveau!2

Het onderzoek toonde daarmee aan dat wanneer een autoriteit geaccepteerd wordt, het persoonlijke geweten daarbij ondergeschikt wordt. Belangrijk om zich te realiseren is dat de context dus zeer bepalend is voor het handelen van mensen. Dit betekent dus ook dat regels (gij zult niet doden!) in bepaalde situaties niet worden opgevolgd. Het experiment toonde daarmee meteen de beperking aan van ‘regels’.

Bronnen:

  1. Milgram, S., Obedience to authority, New York, Harper and Row, 1974.
  2. Blass, T., The Milgram paradigm after 35 years: Some things we now know about obedience to authority, in: Journal of Applied Social Psychology, 29, 1999, p. 955-978.

Het hebben van een gezamenlijke Code of Ethics is derhalve een mooi uitgangspunt, maar de toepassing ervan kan per context verschillen. Wanneer we naar de IFAC Code of Ethics kijken, zien we hier bijvoorbeeld in staan dat integriteit belangrijk is als waarde voor accountants en auditors. Letterlijk staat er: ‘The principle of integrity imposes an obligation on all professional accountants to be straightforward and honest in professional and business relationships. Integrity also implies fair dealing and truthfulness.’[IFAC Code of Ethics, , section integrity, p. 9, versie 2005 (p .9 verwijst naar de versie waarin de oorspronkelijke IFAC-tekst staat naast de NOREA-vertaling).] Een mooie uitspraak en niemand zal het hiermee oneens kunnen zijn. Wie is er immers tegen eerlijkheid? Moeilijkheden ontstaan er echter pas wanneer iemand in de dagelijkse praktijk tegen een probleem aanloopt. Want wat is ‘honest business relationships’? Hoeveel marge mag je nog ‘eerlijk’ maken? Daar hebben mensen toch vaak heel uiteenlopende ideeën over. Dit is natuurlijk al in Nederland zo, maar wanneer we ‘eerlijk zakendoen’ over de grens nemen, dan zullen we zien dat in andere landen er andere normen gelden ten aanzien van het zakendoen. Kortom: wat is ‘eerlijk’? Dit wordt bepaald door de specifieke omstandigheden die er op dat moment gelden, ofwel: de ‘context’.

Een ander voorbeeld vanuit de internationale context is de manier waarop medewerkers omgaan met de hiërarchie binnen hun eigen organisatie. Wanneer Nederlandse medewerkers het bijvoorbeeld niet eens zijn met het oordeel van hun baas zullen zij dit over het algemeen makkelijker kenbaar maken dan medewerkers in Angelsaksische of Aziatische landen. Voor IT-auditors is het altijd erg belangrijk om hun eigen objectiviteit te blijven waarborgen. De hiërarchische context zoals die hiervoor werd geschetst, geeft al aan dat dit in bepaalde landen misschien moeilijker is dan in andere landen. In de NOREA-code staat daarom ook geschreven: ‘De IT-auditor accepteert niet dat zijn professioneel of zakelijk oordeel wordt aangetast door een vooroordeel, belangentegenstelling of ongepaste beïnvloeding door een derde.’[NOREA Code of Ethics, Hoofdstuk A-120 Objectiviteit, p. 10, versie 2006.] Tegelijkertijd heeft de code er oog voor dat dit vooral in de praktijk op de proef zal worden gesteld: ‘De IT-auditor kan in een situatie komen te verkeren waarin zijn objectiviteit in het gedrang komt. Het is onmogelijk al deze situaties te beschrijven.’[NOREA Code of Ethics, Hoofdstuk A-120 Objectiviteit, p. 10, versie 2006.] De NOREA Code of Ethics geeft dus nadrukkelijk het uitgangspunt weer (objectiviteit) maar heeft tegelijkertijd oog voor het feit dat dit altijd in de context van de praktijk dient te worden vormgegeven. De verantwoordelijkheid om de objectiviteit te waarborgen wordt daarmee neergelegd bij de individuele IT-auditor.

Het belang van een goede implementatie van de NOREA Code of Ethics

De Code of Ethics laat duidelijk een eigen verantwoordelijkheid bestaan bij de IT-auditor zelf en dit is goed. We kunnen immers niet vooraf alle mogelijke zaken beschrijven in een code. Dit zou de code enorm omvangrijk maken. Bovendien hebben we gezien dat de context soms zeer bepalend kan zijn voor het handelen van mensen. Integriteit kan dus niet worden gezien als een fait accompli: als louter een kwestie van goed- of kwaadwillende mensen waarover een organisatie nu eenmaal wel of niet beschikt. Zoals het experiment van Milgram al liet zien kunnen goede mensen bijvoorbeeld heel slechte dingen doen als ze in een bepaalde context worden geplaatst. Ook ‘goede’, nette IT-auditors kunnen dus heel verkeerde dingen gaan doen als zij in een bepaalde context komen te staan.

Bij het uitvaardigen van regels dient er daarom ook rekening te worden gehouden met de context. De NOREA heeft hier nadrukkelijk ook oog voor gehad en heeft een belangrijke stap gezet door de vertaling van de IFAC Code of Ethics naar de Nederlandse IT-auditcontext en in de Nederlandse taal.

Desondanks liet het voorbeeld van objectiviteit al zien dat de NOREA ook erkent dat de code nooit vooraf alle antwoorden zal kunnen geven. De NOREA Code of Ethics is daarmee dus geen wet van Meden en Perzen geworden! De eigen verantwoordelijkheid van IT-auditors staat centraal. Bij de implementatie van de code dient dit kenmerkende aspect duidelijk te worden benadrukt. Het enkel communiceren van een document is niet voldoende! Het vragen naar de eigen verantwoordelijkheid van IT-auditors vereist ook dat er wat gedaan wordt aan bewustwording en training van de beroepsgroep.

Het op schrift stellen van een mooi document met goed geformuleerde uitgangspunten is slechts het begin. Zonder een goede implementatie kan een code zelfs schade toebrengen aan de geloofwaardigheid en het imago van de beroepsgroep. Als de code een eendagsvlinder blijft, niet meer dan een lege huls of slechts window-dressing, kan hij namelijk zelfs averechts werken. De code verdwijnt dan onder in de bureaula of in het ronde archief ([Kapt02]). Daarom is het van belang dat er structureel aandacht, toelichting en training wordt gegeven over de code.

‘Maar IT-auditors zijn mensen met een post-doctorale opleiding! Daarvan zou toch verwacht kunnen worden dat zij verstandig genoeg zijn om zelf in te schatten hoe zij kunnen werken met een code?’ Dit is slechts ten dele waar. De kracht van een code ligt juist in het bespreken van ethische vraagstukken uit de praktijk en het van daaruit werken aan verbeteringen. Op die manier zullen IT-auditors getraind worden in hun bewustwording wat het juiste ethische handelingsalternatief is en wat mooie termen als ‘integriteit’ en ‘objectiviteit’ voor hun dagelijkse praktijk betekenen. De werkgevers van de IT-auditors zouden hierin een leidende rol moeten spelen, een goed ethisch klimaat is immers ook en vooral voor hen van belang.

Daarnaast dient de code het begin te zijn van maatregelen die de integriteit van de beroepsgroep bevorderen (zie ook kader 3). Naast het hebben van een code is het bijvoorbeeld ook van belang dat:

  • leiderschap wordt getoond;
  • er aandacht is voor de organisatieculturen waarin IT-auditors hun werk moeten doen;
  • de borging van integriteit binnen de organisaties waarin IT-auditors werkzaam zijn en binnen de NOREA is vormgegeven;
  • er een vangnet voor ongewenst gedrag is;
  • er een toets op naleving plaatsvindt;
  • er monitoring plaatsvindt.

Kader 3. Inrichting van integriteitmanagement.

Integriteitmanagement: inrichting

Er bestaat niet een eenduidige methodiek op basis waarvan inrichting van integriteitmanagement kan plaatsvinden. Voor elke organisatie is integriteitmanagement verschillend. Wel zijn er basiselementen die van belang zijn bij de inrichting van integriteitmanagement. Deze elementen zijn bijvoorbeeld:

  • Gedragscode en regelingen. Zoals reeds aangegeven is het bepalen van gemeenschappelijke waarden en normen in een internationale context niet eenvoudig, maar wel zeer belangrijk. Een succesvolle code komt vanuit de organisatie zelf waarbij nationale en regionale verschillen inzichtelijk worden en bespreekbaar zijn.
  • Leiderschap. Wie integer handelen verlangt, zal zelf een goed voorbeeld moeten zijn. De integriteit van een internationaal opererend bedrijf begint bij de integriteit van de top.
  • Organisatiecultuur. Zoals eerder in dit artikel uiteengezet kan de organisatiecultuur worden gezien als het fundament waarop procedures en maatregelen kunnen bouwen. In deze visie kan organisatiecultuur als resultante worden gezien van integriteitmanagement.
  • Borging van integriteit. Om een gewenste organisatiecultuur te bereiken en te behouden is het van belang gewenst gedrag te verankeren in de bedrijfsprocessen. Belangrijke elementen hierbij zijn bijvoorbeeld de beloningssystematiek en wervings- en selectieprocedures.
  • Vangnet. Goed integriteitbeleid en verantwoord bestuur bieden mensen ruimte om ongewenst gedrag en dilemma’s te melden en bespreekbaar te maken. De meest gewenste situatie is dat medewerkers dilemma’s of schendingen melden in de eerste lijn, bij de eigen leidinggevende. Een organisatie waarin integriteit bespreekbaar is, leert continu van de integriteitsbeleving van medewerkers, in alle lagen van de organisatie, in binnen- en buitenland. Als medewerkers om een bepaalde reden niet in de eerste lijn willen of kunnen melden, is de implementatie van een meldstructuur voor incidenten en vragen over integriteit is van groot belang.
  • Naleving. Geloofwaardige aandacht voor integriteit kan niet zonder een toets op de naleving van gestelde normen en correctie op ongewenst gedrag. Hiertoe dient sanctiebeleid te worden ontwikkeld.
  • Monitoring. Meten is weten. Een veelheid aan initiatieven om een bepaalde organisatiecultuur te bereiken biedt organisaties nog geen inzicht in de mate waarin ze ‘in control’ zijn. Het wordt steeds belangrijker om verantwoording af te kunnen leggen over maatregelen ten aanzien van organisatie-integriteit. Er zijn inmiddels beproefde methodieken om deze zogenaamde ‘soft controls’ in kaart te brengen en zodoende periodiek verantwoording over integriteit te kunnen afleggen.

Concrete acties vanuit de NOREA voor een goede implementatie van de Code of Ethics

De NOREA heeft ook oog voor het belang van een goede implementatie. Daarom zijn er al enkele acties ontplooid. Allereerst is de NOREA-code verplichte stof in de opleiding voor toekomstige RE’s. De bestaande RE’s zijn via de eis van permanente educatie ook formeel verplicht om kennis te nemen van de inhoud van de vernieuwde code. De NOREA faciliteert dit ook door het uitgeven van een boekje dat alle RE’s zullen ontvangen. Belangrijk is ook dat de NOREA het belang inziet dat informeren alleen niet voldoende is. Men moet ook met elkaar spreken over de inhoud van de code en wat die voor eenieder betekent in het dagelijks werk. Hiervoor organiseert de NOREA voorlichtingssessies in alle regio’s.

Resumé

De vernieuwde NOREA Code of Ethics is in juli 2006 ingevoerd voor alle register EDP-auditors ter vervanging van de bestaande gedrags- en beroepsregels. Het is belangrijk zich te realiseren dat de code vooral in de context van de praktijk zal worden geïnterpreteerd en dat regels niet zo eenduidig zijn als ze vooraf lijken. De NOREA heeft zich dit vooraf ook gerealiseerd door de code naar de Nederlandse context te vertalen en ook iedereen te informeren via opleiding en regiobijeenkomsten. Daarnaast geeft de NOREA ook expliciet aan dat de code een sterke nadruk legt op de eigen verantwoordelijkheid. Het zou goed zijn als deze eerste stap van het formuleren van een goede code en het informeren een vervolg krijgt door een goede implementatie in samenhang met andere integriteitbevorderende maatregelen. Hierbij is ook een belangrijke taak weggelegd voor de werkgevers van de IT-auditors.

Literatuur

[IFAC05] IFAC Code of Ethics, versie 2005.

[Kapt01] Kaptein, M., De integriteitbarometer voor organisaties, Bedrijfskunde, jaargang 73, 2001, nummer 3.

[Kapt02] Kaptein, M., H. Klamer en A. Wieringa, De Bedrijfscode, Stichting NCW, Ethicon, Stichting Beroepsmoraal en Misdaadpreventie, Den Haag.

[NORE06] NOREA Code of Ethics, versie 2006.

[Pleu06] Pleunes-Caljouw, J. en M. de Kiewit, Monitoren en auditen van softcontrols als sluitstuk van de compliancecyclus, Tijdschrift voor compliance, 2006, nummer 2.

Elektronisch bankieren met OfficeNet

Voor het uitvoeren van elektronische betalingen wordt door veel bedrijven gebruikgemaakt van de ABN AMRO-betalingsapplicatie OfficeNet. Twee verschillende soorten betalingen kunnen hiermee worden verricht: batchbetalingen en losse betalingen. Aan beide typen betalingen kleeft een aantal specifieke risico’s. Ook het gebruik van OfficeNet brengt risico’s met zich mee. Deze risico’s worden in dit artikel beschreven, samen met de te nemen controlemaatregelen. Tevens worden de aandachtspunten voor de auditor belicht.

Inleiding

Binnen organisaties vinden verschillende processen plaats, afhankelijk van het type organisatie. Eén proces dat in iedere organisatie plaatsvindt, ongeacht het type of de grootte van het bedrijf, is het betalingsproces. De mate van complexiteit van dit proces kan echter aanzienlijk variëren, afhankelijk van de omvang van het bedrijf en de bedrijfstak. Ook de mate van internationalisatie van een organisatie is van invloed op de complexiteit van het betalingsproces. Een organisatie die internationaal opereert, heeft te maken met grensoverschrijdende betalingen. Ook moeten internationale organisaties voldoen aan diverse buitenlandse wet- en regelgeving die van invloed kan zijn op de interne bedrijfsprocessen. Internationale organisaties hebben dikwijls een gecentraliseerde betalingsorganisatie, ook wel geïntegreerd met een treasuryafdeling. Lokale organisaties hebben echter een kleinschaliger, minder complexe betalingsorganisatie.

In dit artikel wordt ingegaan op de betalingsprocessen binnen een lokaal georganiseerde organisatie, met een kleinschalige betalingsorganisatie. Dit artikel streeft na inzicht te verschaffen in de specifieke risico’s van het uitvoeren van elektronische betalingen. Een veelgebruikt programma voor het uitvoeren van elektronische betalingen is OfficeNet van ABN AMRO. Verschillende pakketten van OfficeNet zijn beschikbaar, met ieder pakketspecifieke beveiligingsmogelijkheden. Daarnaast is er nog een aantal procedurele controles die binnen de organisatie gehanteerd kunnen worden ter waarborging van de juistheid, de volledigheid en de autorisatie van betalingen. In dit artikel worden allereerst de verschillende betalingsprocessen binnen OfficeNet beschreven. Vervolgens worden per processtap de risico’s geïdentificeerd. Daarna wordt een overzicht gegeven van de te nemen maatregelen om deze risico’s af te dekken. Ten slotte worden de aandachtspunten voor de auditor weergegeven in een controlematrix. Voor deze controlematrix is specifiek gekeken naar het pakket OfficeNet Extra. Voor andere pakketten van OfficeNet kunnen de beschreven instellingen afwijkend zijn.

Aansluitend is een korte paragraaf gewijd aan de verschillen tussen een lokaal georiënteerde organisatie en een internationale organisatie, waarbij enkele invloeden van globalisering op het betalingsproces worden aangeduid.

OfficeNet Extra

OfficeNet Extra is opgebouwd uit OfficeNet Direct met, afhankelijk van de betreffende versie, een aantal additionele modules, die ieder optioneel te installeren zijn. De meest recente versie, OfficeNet Direct 1.5, heeft drie modules. Versie 1.4 heeft er vier. Met OfficeNet Direct is het mogelijk een directe koppeling te maken met een financieel systeem. Door middel van deze koppeling kunnen betalingsopdrachten worden ingelezen. Met de modules ‘Binnenland betalen’, ‘Buitenland betalen’ en ‘Incasso’ kunnen zelf betalingsopdrachten worden aangemaakt. Daarnaast worden in versie 1.4 met de module ‘Rapportage’ rapportagemogelijkheden geboden ([AVEB]). In versie 1.5 is deze functionaliteit geïntegreerd in OfficeNet Direct. OfficeNet kan op het netwerk geïnstalleerd worden, daarnaast kan OfficeNet apart op een pc worden geïnstalleerd. Batchbestanden kunnen via het netwerk worden ingelezen, of via een floppy of USB-stick worden overgebracht. De structuur van OfficeNet Extra 1.4 is in figuur 1 weergegeven.

C-2006-3-Houwelingen-1

Figuur 1. Structuur OfficeNet Extra 1.4. (Bron: Pakketspecifieke aanvullingen op de richtlijnen ‘Veilig elektronisch bankieren bij ABN AMRO’.)

Beveiliging

Aan het betalingsproces zijn verschillende inherente risico’s verbonden (zie paragraaf ‘Risico’s’). Een inadequate beheersing van de betalingsapplicatie is er één van. Om dit risico te reduceren zijn door ABN AMRO diverse maatregelen genomen binnen OfficeNet. Daarnaast kan de organisatie zelf controlemaatregelen implementeren. Deze maatregelen zijn zowel op applicatieniveau als op netwerkniveau van toepassing. Hieronder worden de belangrijkste beveiligingsmaatregelen opgesomd.

Om toegang te verkrijgen tot OfficeNet moet worden ingelogd met een gebruikersnaam en wachtwoord. OfficeNet dwingt niet af dat wachtwoorden periodiek gewijzigd moeten worden, dit moet procedureel worden afgedwongen. Wel dienen wachtwoorden minimaal acht karakters lang te zijn en minimaal een cijfer en een letter te bevatten. Alleen de hoofdgebruiker (dit is de gebruiker met alle bevoegdheden binnen OfficeNet) heeft de mogelijkheid om wachtwoorden van andere gebruikers te resetten.

Voordat betalingsopdrachten naar de bank verstuurd kunnen worden, moeten deze in OfficeNet door een of twee gebruikers gefiatteerd worden. Voor het fiatteren van betalingsopdrachten in OfficeNet kan men kiezen uit twee beveiligingsmiddelen, een calculator en een smartcard. De smartcard bevat een sleutel die correspondeert met een sleutel van de server bij ABN AMRO. Op deze server zijn de bevoegdheden opgeslagen die aan een specifiek gebruikersnummer zijn gekoppeld. Deze bevoegdheden betreffen rechten om betalingsopdrachten ‘alleen’ of ‘samen’ te fiatteren en/of te verzenden naar de bank. In het Electronic Banking Contract met ABN AMRO zijn de bevoegdheden per smartcard beschreven en wordt een overzicht gegeven van de in gebruik genomen smartcards. In OfficeNet moet vervolgens door de hoofdgebruiker worden vastgelegd welke gebruiker van welk gebruikersvolgnummer met bijbehorend beveiligingsmiddel gebruikmaakt. Bovendien kan de hoofdgebruiker in OfficeNet aan gebruikers beperkende bevoegdheden opleggen, zoals fiatteringslimieten en schermprocuraties. Het is weliswaar mogelijk in OfficeNet andere rechten toe te kennen aan een gebruiker, deze opdrachten zullen echter niet kunnen worden gefiatteerd of worden verzonden naar de bank.

De smartcard biedt extra mogelijkheden in vergelijking met de calculator, zoals het autoriseren van opdrachten met twee handtekeningen en het op afstand laten tekenen van opdrachten (de zogenaamde ‘remote sign’-mogelijkheid) ([VEB]).

Als men gebruikmaakt van een smartcard voor het fiatteren van opdrachten, is ook een viercijferige pincode vereist. Iedere smartcard heeft een unieke initiële pincode, die vervolgens in OfficeNet kan worden gewijzigd. Het is mogelijk dergelijke wijzigingen af te dwingen in OfficeNet.

Ten slotte is ook een apart bankwachtwoord vereist om betalingsopdrachten te kunnen verzenden naar de bank.

Een andere beveiligingsmaatregel is functiescheiding. Binnen OfficeNet kunnen de volgende functies worden onderscheiden ([VEB]):

  • data entry functie: het invoeren van betalingsopdrachten. Autoriseren en verzenden zijn niet mogelijk. Hierbij is geen beveiligingsmiddel nodig (smartcard of calculator).
  • autorisatiefunctie: het elektronisch ondertekenen (fiatteren) van ingevoerde betalingsopdrachten. Hierbij is een beveiligingsmiddel (smartcard) nodig.
  • verzendfunctie: het verzenden van de betalingsopdrachten naar de bank, nadat deze zijn geautoriseerd. Hierbij is een beveiligingsmiddel nodig. Bij het gebruik van een calculator zijn de autorisatie- en de verzendfunctie gecombineerd.

Binnen het betaalproces is het van essentieel belang dat er functiescheiding is tussen het invoeren en het autoriseren van betalingsopdrachten. In principe kan deze functiescheiding niet technisch worden afgedwongen; daarom is het van belang dat organisatorische maatregelen zijn geïmplementeerd om op deze wijze de functies invoeren en autoriseren van betalingsopdrachten te scheiden. OfficeNet biedt de mogelijkheid om functiescheiding af te dwingen tussen het autoriseren en verzenden van betalingsopdrachten.

Daarnaast is het ook mogelijk beveiligingsmaatregelen op netwerkniveau te implementeren om zodoende de verschillende modules en directories van OfficeNet af te schermen van ongeautoriseerd gebruik.

Procesbeschrijvingen

Binnen OfficeNet kunnen twee typen betalingen plaatsvinden, losse betalingen en batchbetalingen. In figuur 2 is het verloop van beide processen schematisch weergegeven.

C-2006-3-Houwelingen-2

Figuur 2. Procesdiagram betalingen in OfficeNet.

In onderstaande subparagrafen worden beide processen beschreven.

Batchbetalingen

1 Betaallijst

In externe financiële systemen (bijvoorbeeld Exact, FIS2000 of Oracle Financials) worden de betalingen ingevoerd. Vervolgens worden deze in een batch klaargezet om te worden geëxporteerd naar een betalingsbestand.

2 Clieop03-betalingsbestand

Het financieel systeem genereert een Clieop03-bestand (binnenlandse betalingen of incasso) of een BTL91-bestand (buitenlandse betalingen) met hierin de betalingsopdrachten. Een Clieop03-bestand is een onversleuteld tekstbestand dat met bijvoorbeeld de tool Notepad kan worden geopend. Dit Clieop03-bestand dient in een specifieke directory van OfficeNet te worden geplaatst. Standaard geldt de volgende directory: C:Program FilesOfficeNet ExtraClieop03.

3 Import file

De opdrachten uit de directory worden automatisch geïmporteerd zodra OfficeNet wordt opgestart en in de map ‘Opdrachten’ de optie ‘Geïmporteerd’ wordt aangeklikt. Deze map is alleen toegankelijk als de gebruiker hiervoor geautoriseerd is (via de schermprocuraties); is de gebruiker niet geautoriseerd, dan is de map niet zichtbaar.

Na import van het Clieop03-bestand in OfficeNet wordt het bestand automatisch uit de directory verwijderd.

In OfficeNet kan na import de mate van correctheid van de geïmporteerde bestanden worden gezien. Indien een opdrachtbestand één of meer fouten bevat, kan dit bestand niet worden verwerkt door de bank. Ook kunnen foutieve bestanden niet worden geautoriseerd in OfficeNet. Deze betalingsopdracht heeft dan de status ‘geweigerd’. Tevens kan de reden van weigering worden weergegeven. Een geweigerd bestand kan worden verwijderd; de gebruiker dient hier wel voor geautoriseerd te zijn ([OND]).

Ook kan de status ‘gecorrigeerd’ worden getoond. Dit bestand bevat dan betalingen waarin bij het importeren aanpassingen zijn gemaakt door OfficeNet. Deze aanpassingen zijn niet van invloed op de ‘kritische’ gegevens (bedrag, rekeningnummers) van de opdracht, maar zijn wel noodzakelijk om het opdrachtenbestand te kunnen laten verwerken door de bank. Het betreft dan bijvoorbeeld de lengte van de naam van de begunstigde. De tekenbevoegde gebruiker heeft dan de mogelijkheid om de correctie te accepteren en de opdracht te tekenen of de gehele opdracht te verwijderen. Indien de gebruiker niet geautoriseerd is, zijn deze opties niet mogelijk en blijft het bestand aanwezig ([OND]).

4 Controle betaallijst

Na import van het Clieop03-bestand zijn de geïmporteerde gegevens in detail of als totalen zichtbaar onder het scherm ‘Geïmporteerd’. Deze gegevens dienen te worden vergeleken met de betaallijst uit de boekhoudapplicatie. De gegevens die vergeleken kunnen worden, zijn:

  • Som rekeningnummers;
  • Totaalbedrag;
  • Aantal opdrachten.

Hiervoor kan een verslag van de ingelezen bestanden bekeken worden in OfficeNet (onder ‘Import verslagen’). Tevens kan de gebruiker individuele opdrachtbestanden uit een batch bekijken. Een voorbeeld van een importverslag is in figuur 3 weergegeven, waarbij de te vergelijken items zijn omcirkeld.

C-2006-3-Houwelingen-3

Figuur 3. Importverslag in OfficeNet.

5 Autorisatie batch

Na controle wordt de betalingsopdracht klaargezet voor autorisatie. Binnen OfficeNet kan per rekening worden ingesteld of betalingsopdrachten door één of twee personen moeten worden geautoriseerd. Autorisatie vindt plaats door middel van een smartcard of calculator, waarbij het opdrachtbestand wordt voorzien van een (of twee) elektronische handtekening(en). Ook kan per gebruiker een fiatteringslimiet worden aangegeven.

Daarnaast bestaat de mogelijkheid om betalingsopdrachten op afstand te laten tekenen, de zogenaamde ‘Remote Sign’-optie. Hierbij worden betalingsopdrachten door twee personen geautoriseerd, waarbij de eerste autorisatie ‘lokaal’ plaatsvindt. De tweede persoon haalt met OfficeNet vanaf een andere locatie de geautoriseerde bestanden op, waarna hij deze voor de tweede maal autoriseert ([OND]).

6 Verzending batch

Na autorisatie kan de betalingsbatch worden verzonden naar de bank. Naast de smartcard moet voor de communicatie met de bank een bankwachtwoord worden ingevoerd. De communicatie vindt alleen plaats bij een juiste combinatie van pincode en bankwachtwoord of calculator en respons.

7 Ontvangst bank

Na verzending wordt de betalingsopdracht ontvangen door de bank. Het transport van de gegevens naar de bank is beveiligd door middel van encryptie. Hierbij wordt gecontroleerd of de gegevens bij de bankcomputer aankomen zoals ze zijn verzonden.

8 Controle dagafschrift

Na ontvangst van het dagafschrift van de bank dient dit afschrift vergeleken te worden met de uitdraai uit OfficeNet van ‘verzonden opdrachten’. In OfficeNet versie 1.5 is het tevens mogelijk de status van de verzonden opdrachten te bekijken (verstuurd, goed ontvangen, etc.).

Losse betalingen

In het geval van losse betalingen kan gebruik worden gemaakt van een vast adresboek. Deze crediteuren zijn vooraf geregistreerd in OfficeNet. Het is echter ook mogelijk geen gebruik te maken van dit vaste adresboek. In deze situatie worden de naam en het rekeningnummer direct in de betalingsopdracht ingevoerd. Het is in OfficeNet niet mogelijk af te dwingen dat betalingen alleen naar deze geregistreerde crediteuren worden overgemaakt. Ook als gebruik wordt gemaakt van het adresboek is het mogelijk direct naam en rekeningnummer in de betalingsopdracht in te voeren. Het gebruik van bestemmingsrekeningen kan wel bij de bank worden vastgelegd in een afzonderlijk contract, namelijk het Electronic Banking Contract. Als er betalingsopdrachten worden gegeven, verwerkt de bank deze uitsluitend als de rekening van de crediteur is opgenomen als bestemmingsrekening ([VEB]).

1 Factuur

Een medewerker ontvangt de factuur. In het geval dat gebruik wordt gemaakt van een vaste crediteurenlijst, wordt gecontroleerd of de crediteur al geregistreerd staat in OfficeNet. In het geval dat de crediteur niet geregistreerd staat in OfficeNet, kan deze eerst worden toegevoegd aan de vaste crediteurenlijst, of kan direct een betalingsopdracht worden aangemaakt.

2 Aanmaken betalingsopdracht

Als de crediteur geregistreerd is in OfficeNet, wordt de betalingsopdracht aangemaakt. Hiervoor wordt de crediteur geselecteerd en het bedrag wordt conform de factuur ingevoerd.

Als er geen gebruik wordt gemaakt van het adresboek, wordt op basis van de gegevens van de factuur de betalingsopdracht aangemaakt. Hiertoe worden het rekeningnummer, NAW-gegevens en het bedrag ingevoerd.

3 Import file

Net als bij batchbetalingen uit financiële systemen maakt OfficeNet bij een losse betalingsopdracht een zogenaamd ‘Cliaab’ (Clieop03 ABN AMRO-bestand) aan dat in een specifieke directory wordt geplaatst. Dit is dezelfde directory als de directory waarin de Clieop03-bestanden met batchbetalingen worden opgeslagen. De losse betalingsopdrachten in het Cliaab zijn, in tegenstelling tot de batchbetalingen, standaard voorzien van een ‘hash’-controlegetal. Dit controlegetal wordt volgens een bepaald algoritme berekend op basis van de betalingsinformatie in het bestand. Bij het inlezen van de betalingsopdrachten in OfficeNet wordt het ‘hash’-getal opnieuw berekend. Indien dit berekende ‘hash’-getal afwijkt van het ‘hash’-getal dat in het Cliaab is opgeslagen, wordt het bestand door OfficeNet geweigerd en wordt het bestand niet geïmporteerd.

4 Autorisatie

Bij losse betalingen moeten de betalingsopdrachten voor autorisatie worden vergeleken met de facturen, waarbij controle moet plaatsvinden op naam en rekeningnummer van de crediteur en op het bedrag. Technisch verloopt de autorisatie vervolgens identiek aan de autorisatie van de batchbetalingen.

De stappen ‘Verzenden’, ‘Ontvangst bank’ en ‘Controle dagafschrift’ verlopen ook identiek aan de batchbetalingen.

Risico’s

Binnen de beschreven processtappen is een aantal risico’s te onderscheiden die van invloed zijn op de juistheid, de volledigheid en de autorisatie van betalingen. Ook hierbij kan een onderverdeling worden gemaakt naar batchbetalingen en losse betalingen. In tabel 1 wordt een overzicht gegeven van de risico’s en de te treffen controlemaatregelen binnen de organisatie, welke zijn toegespitst op het gebruik van OfficeNet. Algemene computercontroles (general IT controls) vormen een onderdeel van de te treffen beheersingsmaatregelen. Gezien het algemene karakter van de general IT controls zijn deze in dit artikel buiten beschouwing gelaten.

C-2006-3-Houwelingen-t1

Tabel 1. Risico’s en controlemaatregelen betalingsproces. [Klik hier voor grotere afbeelding]

De loggingfunctie van OfficeNet biedt beperkte mogelijkheden voor controle. Er zijn zeven verschillende ‘log levels’ waarop logging kan plaatsvinden. Logging van beveiligingsgerelateerde informatie is beperkt tot de maximumgrootte van het logbestand. Dit kan worden ingesteld door de hoofdgebruiker. Daarnaast is de gebruiker in staat het logbestand te wissen.

Gezien de aard van het proces is het daarom raadzaam te steunen op de detectieve maatregelen, zoals die in tabel 1 zijn beschreven.

Globalisatie

Binnen het betalingsproces dienen de betrouwbaarheid en de rechtmatigheid van betalingen te worden gewaarborgd. Echter, een internationale organisatie met grensoverschrijdende betalingen wordt behalve aan bovenstaande risico’s ook blootgesteld aan risico’s die zijn ontstaan als gevolg van de globalisering. Schaalvergroting en een toename van wet- en regelgeving zijn hier enkele voorbeelden van.

Wijzigingen in wet- en regelgeving kunnen aanleiding zijn tot aanpassing van bestaande applicaties, door bijvoorbeeld toenemende rapportage-eisen ([Beug06]).

Schaalvergroting van een organisatie kan ertoe leiden dat de betalingsorganisatie centraal wordt georganiseerd, en eventueel wordt gecombineerd met een treasuryafdeling. De betalingsorganisatie heeft hierdoor een grotere omvang dan wanneer zij lokaal zou zijn georganiseerd. Dit geldt zowel voor de personele omvang als voor de hoeveelheid betalingen die worden verricht. Hierdoor ontstaan er additionele uitdagingen aan de technische instellingen van de betalingsapplicatie. Er dienen voldoende waarborgen te worden geïnstalleerd om functievermenging te voorkomen ([Piep99]). Autorisatiebeheer (functiescheiding en betalingslimieten) dient dan ook voldoende aandacht te krijgen.

Een ander gevolg van globalisatie is 24 × 7. In vergelijking met lokaal opererende bedrijven stellen internationaal georiënteerde organisaties andere eisen aan de beschikbaarheid van gegevens en toeleverende processen, zoals het aanleveren van koers- en valuta-informatie ([Beug06]). Daarnaast dient een betalingsapplicatie te kunnen voldoen aan de eisen van de organisatie, rekening houdend met verschillende valuta en het hierbijbehorende marktrisico (valutaschommelingen). Tevens dienen maatregelen te worden genomen ten aanzien van back-up- en disaster recovery-faciliteiten ([Beug06]). Door dit toenemende aantal eisen aan een applicatie bestaat het risico dat de betalingsapplicatie zeer complex wordt.

Niet alleen het pakket, ook de keuze van de leverancier is belangrijk ([Beug06]. De leverancier dient over voldoende kennis te beschikken van zowel de organisatie als van de markt waarin zij opereert.

Conclusie

Binnen het betalingsverkeer is betrouwbaarheid het belangrijkste kwaliteitsaspect. Betrouwbaarheid wordt hierbij opgedeeld naar integriteit, exclusiviteit, authenticiteit en controleerbaarheid ([Piep99]). Deze aspecten zijn op iedere betalingsorganisatie van toepassing, zowel lokaal als internationaal georiënteerd. De maatregelen die organisaties dienen te nemen om deze kwaliteitsaspecten te kunnen waarborgen, kunnen echter wel verschillen. Internationale organisaties zijn aan additionele risico’s blootgesteld en dienen hier ook voldoende aandacht aan te besteden. Echter, de belangrijkste maatregel om de betrouwbaarheid van het betalingsverkeer te kunnen garanderen is functiescheiding. Dit is van toepassing op zowel lokale als internationale organisaties.

Een voordeel van een grotere betalingsorganisatie is dat procedurele functiescheiding eenvoudiger te implementeren is (vierogenprincipe). Een kleine betalingsorganisatie kan uit enkele personen bestaan, waardoor organisatorische functiescheiding tussen invoer, fiattering en verzending van betalingen niet in alle gevallen eenvoudig is te implementeren. Echter, autorisatiebeheer is aanzienlijk complexer binnen een organisatie van grote omvang; hier dient dan ook voldoende aandacht aan te worden besteed.

Tijdens een audit van de betalingsorganisatie moeten de beschreven controlemaatregelen worden getoetst om de betrouwbaarheid en rechtmatigheid van de betalingen te kunnen vaststellen. Daarnaast wordt duidelijk dat, hoewel OfficeNet goede beveiligingsmogelijkheden biedt, een goede inrichting en naleving van het betalingsproces noodzakelijk is. Tevens dienen ook de general IT controls effectief te zijn. Bij batchbetalingen is het bovendien essentieel om de controles in en rondom de aanleverende systemen te toetsen. Het vierogenprincipe bij het wijzigen van crediteuren, periodieke controles op nieuwe en gewijzigde crediteuren, en autorisaties voor het blokkeren (en opheffen van blokkades) van crediteuren zijn hierbij van cruciaal belang om de juistheid, volledigheid en autorisatie van batchbetalingen te kunnen waarborgen.

Om de controlemaatregelen uit tabel 1 te kunnen toetsen is een werkprogramma opgezet. In dit werkprogramma worden per controlemaatregel de uit te voeren activiteiten beschreven. Onderdelen hiervan zijn bijvoorbeeld het opvragen van het contract met de bank, controle op speciale instellingen, etc. Dit werkprogramma kan een praktische handleiding vormen tijdens een audit naar de betalingsorganisatie waarbij gebruik wordt gemaakt van OfficeNet.

De auteur heeft een aanzet gegeven tot een overzicht van de maatregelen die kunnen worden geïmplementeerd om de risico’s tijdens het betalingsproces af te dekken. Het overzicht is echter niet uitputtend. Daarnaast zijn ook de specifieke instellingen van OfficeNet Extra van invloed op de aanwezige risico’s en de te nemen maatregelen. Voorbeelden hiervan zijn de keuze tussen een netwerk-pc of een stand-alone-pc, en de keuze tussen gedeeld datagebruik of individueel datagebruik. Bij installatie van OfficeNet is het dan ook van belang de verschillende instellingen aan te passen aan de specifieke bedrijfsbehoeften. Advies van een ABN AMRO-accountmanager is hierbij aan te bevelen.

Literatuur

[AVEB] Pakketspecifieke aanvullingen op de richtlijnen ‘Veilig Elektronisch Bankieren bij ABN AMRO’.

[Beug06] Mw. B. Beugelaar RE RA en drs. H.B. Moonen RE MBA, Valkuilen bij implementatie van bankpakketten, Compact 2006/1.

[OND] Handleiding OfficeNet Direct 1.4.

[Piep99] Mw. drs. M. Pieper en R.P. Schouten, De ontwikkelingen in het betalingsverkeer, in: Compact & ICT-auditing, 25 jaar Compact, jubileumuitgave, 1999.

[VEB] ‘Veilig Elektronisch Bankieren bij ABN AMRO’.

Globalisering en de complexiteit van logische toegang

Wie heeft toegang tot welke informatie en welke zekerheden hebben organisaties hierover? Dit is een fundamentele vraag die we ons al sinds de komst van mainframes stellen. Echter anno 2006, in een wereld die gekenmerkt wordt door ‘any place, any time’, is deze vraag nog prangender geworden. Hoe dienen steeds internationaler opererende organisaties nu om te gaan met logische toegang en controle hierop? In dit artikel wordt uitgelegd dat het hebben van een strategie op gebied van Identity & Access Management onontbeerlijk is. Daarnaast wordt een (theoretisch) denkkader gepresenteerd over de opkomst van een shared service center op dit gebied en welke diensten een dergelijk organisatieonderdeel kan bieden.

Inleiding

Vanuit ICT-perspectief is globalisering allang geen ver-van-mijn-bedshow meer. Wie belt er bijvoorbeeld tegenwoordig nog naar een helpdesk en krijgt een collega van vier deuren verderop aan de lijn? En als je op zakenreis moet, is het ook normaal dat je direct je laptop inplugt en gewoon kunt werken zonder al te veel moeite (conform het Martini-concept ‘any place, any time’). En wat te denken van integratie van informatievoorzieningen bij fusies en overnames? Hoe belangrijk is het om zorg te dragen dat in de nieuwe bedrijfssituatie de juiste mensen toegang hebben tot de juiste informatie?

Dergelijke voorbeelden illustreren de toenemende complexiteit op het gebied van gebruikers en autorisatie. Het managen van gebruikers en autorisaties wordt dan ook steeds complexer. Hierdoor neemt de vraag toe naar een oplossing om als organisatie ‘in control’ te zijn of te blijven wat betreft de vraag wie nu daadwerkelijk toegang heeft (gehad) tot welke informatie. Het is dan ook niet verwonderlijk dat er een steeds grotere behoefte ontstaat aan efficiënt en effectief toegangsbeheer en om dit vanuit een globaliseringsvisie in te steken.

Dit artikel richt zich vanuit het perspectief van globalisering op het nut, de noodzaak en mogelijkheden van een oplossing, te weten Identity & Access Management (I AM). Er wordt een (theoretisch) denkkader gepresenteerd dat aangeeft dat juist nu, in de huidige dynamische omgeving waarin de meeste organisaties zich bevinden, het verstandig is een strategie te hebben op het gebied van ‘wie ben je?’ en ‘wat mag je?’.

Wat is I AM?

Allereerst is het belangrijk om toe te lichten wat I AM precies inhoudt. I AM is een paraplubegrip voor een veelvoud van termen. In dit artikel hanteren we de volgende definitie ([Herm05]):

I AM is het beleid, de processen en ondersteunende systemen die managen welke gebruikers (personen, applicaties en systemen) toegang verkrijgen tot informatie, ICT-middelen en fysieke resources en wat iedere gebruiker gerechtigd is hiermee te doen.

Kortweg houdt dit in dat het beheer van gebruikers(rechten) in brede zin centraal staat, en daarbij ook centraal wordt gemanaged. Binnen dit kader laat I AM zich vertalen in een serie componenten en bijbehorende processen (zie figuur 1).

C-2006-3-Hermans-01

Figuur 1. Samenhang I AM-componenten.

User management

Met behulp van de user-managementcomponent wordt de werknemerscyclus van in- en uitdiensttreding, maar worden ook functiewijzigingen volledig beheerd. Hiermee wordt de basis gelegd voor de registratie van de gebruikers van informatie, ICT-middelen en fysieke resources.

Authenticatiemanagement

Wanneer duidelijk is welke gebruikers er zijn, dienen zij geauthenticeerd te kunnen worden. Met behulp van authenticatiemanagement worden elementen als passwords, tokens, etc. beheerd en uitgereikt aan gebruikers. Hiermee wordt bereikt dat de gebruiker ook echt is wie hij zegt dat hij is, en er dus vanuit de organisatie controle is over ‘wie ben je?’.

Autorisatiemanagement

Geauthenticeerde gebruikers moeten gekoppeld worden aan bepaalde rechten voor informatie, ICT-middelen en fysieke resources, voordat zij toegang kunnen krijgen tot die objecten. Autorisatiemanagement biedt beheer van die rechten van gebruikers teneinde volledige controle te hebben over ‘wat mag je?’.

Provisioning

Uiteindelijk dienen de rechten van gebruikers te worden gerouteerd naar (ICT-)objecten die benaderd worden. Het doorvoeren van de gebruikers- en autorisatiegegevens kan zowel handmatig als automatisch geschieden.

Monitoring & audit

Eén van de grote voordelen van I AM is de mogelijkheid om continu te monitoren en dus te auditen. Met behulp van monitoring wordt het mogelijk om elk gewenst moment zicht te krijgen op de effectiviteit van het gebruikers(rechten)beleid ofwel real-time audit.

Met behulp van bovenstaande componenten kan I AM inspelen op de toegenomen noodzaak om het complexe landschap van gebruikers, autorisatie en informatieobjecten te managen dan wel te beheersen met als doel als organisatie in control te geraken en operational excellence te bereiken. Dit wordt gerealiseerd door enerzijds het reduceren van (operationele) risico’s en dus het verhogen van informatiebeveiliging, en door anderzijds het realiseren van kostenbesparingen (verhogen productiviteit en lagere autorisatiebeheerkosten) en het verbeteren van gebruikersgemak.

Mogelijkheden van I AM

De ervaring leert dat er meerdere redenen zijn waarom organisaties overwegen I AM in te voeren[KPMG heeft hiernaar in 2004 onderzoek gedaan en de resultaten hiervan zijn in een eerdere editie van Compact gepubliceerd ([Koor04]).]. Daarbij is elke organisatie uniek en bestaat er niet zoiets als een ‘one-size-fits-all’ business case. Tabel 1 geeft een overzicht van de redenen (drivers) waarom organisaties de bijbehorende waardetoevoegende functionaliteiten van I AM overwegen.

Om te beginnen is er natuurlijk veel te doen rondom het onderwerp compliance. Dit wordt door veel organisaties als belangrijke reden genoemd om te beginnen met I AM ([Koor04]). De waarde van I AM zit dan in het bijzonder in het feit dat veelal handmatige processen om compliance aan te tonen (deels) worden geautomatiseerd. Bijvoorbeeld het vergelijken van daadwerkelijke toegang tot systemen ten opzichte van het gestelde beleid. Door deze geautomatiseerde afdwinging en rapportagemogelijkheden is het management ook echt in staat verantwoording af te leggen over de rechten van zijn gebruikers.

Vervolgens zien wij risk management als een belangrijke reden om I AM toe te passen. Nu is dit een thema dat zeker niet nieuw is voor organisaties en waar men al langere tijd toenemend systematisch mee bezig is. In dat kader implementeren organisaties wel meer maatregelen die bijdragen aan het verkrijgen van betere beheersing over hun informatievoorziening. Echter, juist de huidige stand van zaken rondom diverse I AM-oplossingen en technologieën biedt hier nieuwe mogelijkheden, bijvoorbeeld ten aanzien van het real-time afdwingen van functiescheiding.

Procesverbetering (process improvement) gaat in op hoe I AM organisatorische veranderingen, zoals reorganisaties of verbetering van administratieve processen, kan faciliteren. Door toepassing van I AM kunnen bijvoorbeeld gemakkelijk en betrouwbaar gebruikers aan een nieuwe business unit worden toegewezen met bijbehorende nieuwe rollen en permissies. Ook het proces van toekennen van autorisaties kan door middel van geautomatiseerde workflows worden gestandaardiseerd en daardoor sneller worden uitgevoerd.

Ten slotte is er een duidelijke driver te onderkennen onder de noemer technology improvement ofwel algemene vernieuwing of modernisering van infrastructuren en applicatielandschappen. Na een periode van reorganisaties en kostenreducties is er een trend waarneembaar dat organisaties weer investeren in vernieuwing van IT-voorzieningen. Informatiebeveiliging in het algemeen is veelal een integraal onderdeel van een dergelijke vernieuwing en zeker aspecten rondom identity en access komen dan al snel naar voren bij het maken van investeringsvoorstellen en daaruit voortvloeiende architectuurkeuzen.

C-2006-3-Hermans-t01

Tabel 1. Drivers van I AM. [Klik hier voor grotere afbeelding]

I AM in optima forma

Figuur 2 geeft de ‘optima forma’ van I AM weer in termen van de eerder beschreven componenten. I AM start met wijzigingen in de bronregistratie van gebruikers (authoritative source). In dit voorbeeld is de bronregistratie van medewerkers de HR-administratie. In deze HR-administratie staan als het ware de stamgegevens van een medewerker. Tevens worden alle van belang zijnde gebeurtenissen, zoals indiensttreding (new employee), functiewijziging (change) en uitdiensttreding (resign), in deze bron geadministreerd.

C-2006-3-Hermans-02

Figuur 2. I AM in ‘optima forma’.

Deze gebeurtenissen zijn voor I AM van wezenlijk belang, aangezien zij initiërend werken voor het gehele user management. Zo ‘triggeren’ zij acties van leidinggevenden voor het uitgeven/intrekken van gebruikersaccounts en bijbehorende autorisaties. Het daadwerkelijk uitgeven/intrekken van de autorisaties wordt uitgevoerd door technisch en applicatiebeheer. Een geautomatiseerd hulpmiddel (I AM-tool) initieert deze acties en faciliteert het uitvoeren ervan, gebruikmakend van workflow. De leidinggevende krijgt op basis van een ‘trigger’ het signaal dat autorisaties goedgekeurd dienen te worden voor de betreffende medewerker op basis van een voorgedefinieerd autorisatiemodel (dat normaliter is gebaseerd op het gebruik van rollen en regels). Na akkoord zal de gebruiker voorzien worden van het juiste authenticatiemiddel en worden de noodzakelijke gebruikersaccounts en -autorisaties op een al of niet geautomatiseerde wijze gecreëerd en/of gemuteerd (provisioning) binnen de ICT-resources.

Ten slotte wordt er in de ‘optima forma’-situatie voortdurend gecontroleerd of de gebruikersaccounts en -autorisaties zoals doorgevoerd binnen de ICT-resources (actual situation) nog steeds in overeenstemming zijn met de gewenste situatie (to be situation). Bij eventuele afwijkingen zal een zogenaamd incident-managementproces worden opgestart met als doel het evenwicht tussen actual en to be wederom te bereiken.

I AM in optima forma! I AM gericht op het bereiken van enerzijds maximale efficiency en anderzijds maximale control! De wens van iedere CIO, CFO, compliance officer en manager!

Impact van globalisering op het I AM-concept

Conceptueel staat het geschetste model als een huis. Echter, hoe valt dit te implementeren binnen een wereldwijd opererende organisatie, waarbij verscheidenheid een gegeven is? Verscheidenheid in tijdzones, geografische locaties, gebruikers (intern en extern), wetgeving, IT-middelen (platformen en applicaties) en IT-beheerconcepten.

De belangrijkste vraag die dan ook door een organisatie dient te worden beantwoord, is: ‘Wat is het ambitieniveau dat de organisatie wenst en kan bereiken, rekening houdend met de (wereldwijde) IT-strategie van de organisatie?’

Figuur 3 geeft het spectrum van het ambitieniveau weer in termen van mogelijke scenario’s (van minimaal tot maximaal). Deze scenario’s kunnen desgewenst tevens gezien worden als een groeimodel waarbij opschuiving van minimaal naar maximaal uiteraard voor de hand ligt (ook vanuit budgetteringsperspectief). Het is belangrijk op te merken dat het ambitieniveau en de haalbaarheid ervan in sterke mate worden bepaald door het I AM-governancemodel van een organisatie, dat antwoord geeft op vragen als wie het autorisatiemodel bepaalt en beheert (dus inclusief een wijzigingsprocedure).

C-2006-3-Hermans-03

Figuur 3. Scenario’s voor het ambitieniveau, gebaseerd op het I AM-governancemodel.

We onderkennen de volgende vier scenario’s:

  1. Gemeenschappelijk beleid en richtlijnen ten aanzien van I AM. Hierbij wordt de implementatie van I AM-processen en -systemen overgelaten aan de verschillende organisatie-eenheden. Het resultaat is lokaal verschillende manieren van organisatie en ondersteuning van technologie, maar wel op basis van een gemeenschappelijk raamwerk.
  2. Gemeenschappelijk beleid, richtlijnen en I AM-processen. Hoewel dit scenario al behoorlijk centralistisch van opzet is, worden er nog steeds afzonderlijke I AM-systemen per organisatie-eenheid opgezet en beheerd. Qua gemeenschappelijkheid gaat dit scenario al een stap verder dan het eerste door ook dezelfde processen af te spreken (dus niet alleen strategisch maar ook op tactisch en operationeel niveau).
  3. Gemeenschappelijke I AM-oplossing bestaande uit beleid, richtlijnen, processen en infrastructuur. In dit scenario wordt I AM-functionaliteit aangeboden als een shared services center[Een shared service center (SSC) is volgens de definitie van Strikwerda ‘een resultaatverantwoordelijk samenwerkingsverband dat tot taak heeft het leveren van diensten op een specifieke specialisatie aan de afzonderlijke moederorganisaties op basis van een overeenkomst tegen een verrekenprijs’.], waarbij de dienstverlening zich richt op een beperkt aantal gemeenschappelijke, organisatiebrede systemen evenals bedrijfskritische toepassingen. Het inrichten van een shared service center ontslaat een organisatieonderdeel echter niet van de verantwoordelijkheid voor de juiste inrichting van de autorisaties. Een shared service center kan hierbij faciliterend optreden, maar het ontwikkelen en beheren van het autorisatiemodel is een verantwoordelijkheid van de business zelf. Het shared service center I AM is niet per definitie een zelfstandige organisatie-eenheid en zal vaak deel uitmaken van een overkoepelend shared service center.
  4. Organisatiebrede gemeenschappelijke I AM-oplossing. Dit scenario is vergelijkbaar met de onder 3 genoemde vorm, met dien verstande dat het I AM-shared service center zich richt op alle organisatieonderdelen, platformen en toepassingen binnen een organisatie.

Om nu vervolgens de strategie ten aanzien van I AM en de invulling ervan te kunnen bepalen, biedt tabel 2 een vergelijking op basis van de volgende elementen of criteria:

  • Operational excellence: kwaliteit en professionaliteit van de I AM-processen. Naast kwaliteit (en betrouwbaarheid als onderdeel daarvan) is snelheid van juiste toewijzing van autorisaties een factor in het verhogen van arbeidsproductiviteit van gebruikers die immers sneller toegang zullen verkrijgen tot de juiste informatie.
  • Mate van ‘control’: in hoeverre kunnen het geldende beleid en richtlijnen worden afgedwongen. Dit element wordt sterk bepaald door het governancemodel van de organisatie ofwel hoe autonoom zijn landenorganisaties in relatie tot het hoofdkantoor. En meer in IT-termen gesteld: bestaat er een referentiearchitectuur?, is er een preferred-supplierbeleid?, etc.
  • Benodigde investeringen: hoe verhouden de benodigde investeringen zich tot beschikbare budgetten en ook in relatie tot budgetten voor informatiebeveiliging en upgrade van IT-infrastructuur in het algemeen.
  • Te realiseren besparingen (‘benefits’): hoe gedetailleerd zijn te verwachten besparingen doorgerekend en hoe kunnen ze worden gemeten. Denk hierbij aan het verminderen van werkzaamheden van (lokale) applicatiebeheerders maar ook aan vermindering van kosten gerelateerd aan de helpdesk.

In de praktijk komen de eerdergenoemde scenario’s allemaal voor. Het scenario wordt voornamelijk bepaald door (IT-)strategie, governance en cultuur binnen de organisatie. Immers, in een gedecentraliseerde organisatie met grote lokale bevoegdheden en onafhankelijkheden, is scenario 1 en/of 2 maximaal haalbaar, terwijl een sterk gecentraliseerde organisatie met strikte governance het mogelijk maakt scenario 3 of zelfs 4 te realiseren.

C-2006-3-Hermans-t02

Tabel 2. Vergelijking scenario’s op basis van vier criteria.

De conclusie uit tabel 2 is dat indien een organisatie het optimale rendement wil behalen ten aanzien van I AM op de criteria operational excellence en mate van control (compliance) voor de gehele organisatie (zoals beschreven in de paragraaf ‘Mogelijkheden van I AM’) scenario 1 zeker niet nagestreefd dient te worden. Scenario 2 is de situatie die we in de praktijk nog het meeste aantreffen. Er wordt dan al zeer nadrukkelijk gezocht naar synergievoordelen door gemeenschappelijkheid, maar tegelijkertijd wil men veelal nog lokale technische oplossingen instandhouden. Dit gebeurt niet in de laatste plaats door hoge werkdruk van IT-organisaties en schaarse kennis op het vlak van informatiebeveiliging, IT-infrastructuren en I AM.

Opkomst van I AM-shared service centers binnen internationaal opererende organisaties

Als we bovenstaande scenario’s toepassen op een grote internationaal opererende organisatie, zien we scenario 3, het realiseren van een zogenaamd I AM-shared services center (I AM-SSC) als het maximaal haalbare. Vergelijkbaar met reeds meer in zwang geraakte SSC’s voor HR en financiële processen kunnen de onderstaande voordelen worden gerealiseerd door gelijksoortige functies, systemen, processen en resources te bundelen en deze vervolgens optimaal te ontwikkelen en exploiteren.

De volgende drie doelstellingen van een dergelijk I AM-SSC kunnen worden onderkend:

  • schaalvoordelen realiseren;
  • kwaliteit en professionaliteit van de dienstverlening verbeteren (operational excellence);
  • regie krijgen en behouden (‘in control‘).

De volgende bijbehorende diensten van een I AM-SSC kunnen worden onderkend (in relatie tot de I AM-processen zoals reeds beschreven in de paragraaf ‘Wat is I AM?’):

  • het inrichten van de workflow benodigd voor de geautomatiseerde interactie tussen autorisatieaanvragers en I AM-SSC;
  • het optreden als I AM-loket/supportfunctie voor zowel de autorisatieaanvragers als de eindgebruikers (user management);
  • het technisch beheren van de autorisatiemodellen op basis van rollen en regels die zijn vastgesteld door de organisatieonderdelen (deel van het autorisatiemanagement);
  • het realiseren van benodigde geautomatiseerde koppelingen naar de verschillende systemen (provisioning);
  • het verstrekken van de benodigde informatie aan de organisatieonderdelen, benodigd voor het aantonen van compliance (monitoring & audit).

I AM-SSC: wat is de rol van de organisatieonderdelen?

Zoals in de vorige paragraaf beschreven kan door het I AM-SSC een groot aantal, met name technische en operationele I AM-processen worden uitgevoerd, op een zo efficiënt mogelijke wijze. Wat echter zeker niet onderbelicht dient te worden is rol van de verschillende organisatieonderdelen. Wil een organisatieonderdeel gebruik kunnen maken van de diensten van het I AM-SSC, dan dient het I AM-SSC te beschikken over het autorisatiemodel van het organisatieonderdeel. Immers, in het ‘optima forma’ I AM-model zal een manager gebruikmaken van een geautomatiseerde workflow voor het aanvragen en wijzigen van autorisaties, waarin hij kan kiezen uit een voorgedefinieerde set van rollen, beschreven in het autorisatiemodel.

Het ontwerpen van dit autorisatiemodel, waarin daadwerkelijk bepaald en beschreven is wat iemand nu eigenlijk mag, is iets wat te allen tijde door de bedrijfsonderdelen zelf dient te geschieden. Het I AM-SSC kan hiervoor nooit verantwoordelijk worden gesteld, aangezien het I AM-SSC niet beschikt over de benodigde bedrijfs- en proceskennis om te kunnen bepalen hoe deze autorisatiemodellen dienen te worden opgesteld voor de verschillende bedrijfsonderdelen.

De maximale rol die het I AM-SSC kan spelen, is het totstandkomings- en onderhoudsproces van deze autorisatiemodellen[In de Compact-special over informatiebeveiliging, welke medio 2007 verschijnt, zal het opstellen van een autorisatiemodel op basis van rollen diepgaand worden behandeld.] te faciliteren om te komen tot de benodigde autorisatiemodellen.

Conclusie

Het verstrekken van autorisaties en de controle hierop worden steeds complexer voor internationale organisaties, vanwege onder andere steeds mobieler wordende medewerkers (Martini-concept), stringente wet- en regelgeving en de stroom aan organisatiewijzigingen. Organisaties kunnen voordelen realiseren door hierop te anticiperen in de vorm van het ontwikkelen en implementeren van een I AM-strategie.

Bij het definiëren van de I AM-strategie staan het bepalen van het ambitieniveau en de (on)mogelijkheden vanuit internationaal perspectief ten aanzien van I AM centraal. Allereerst dient de organisatie te bepalen wat de belangrijkste drijfveren voor I AM zijn, te weten compliance of operational excellence. Uiteraard kan een organisatie beide nastreven, maar uit de praktijk blijkt dat toch de nadruk wordt gelegd op één van de twee aspecten. Dit onderscheid kan ook naar voren komen in een groeimodel, waarbij een organisatie eerst een aantal quick wins behaalt door zaken als wachtwoordsynchronisatie en elektronische autorisatieaanvragen (operational excellence) te realiseren en vervolgens aan de slag te gaan met het verbeteren van het autorisatiemodel (compliance).

Na het bepalen van de focus ten aanzien van I AM dient de organisatie het meest optimale scenario te selecteren. Het spectrum loopt hierbij van alleen een gemeenschappelijk I AM-beleid tot een gecentraliseerde of geconcentreerde (gezamenlijk ten behoeve van organisatorische eenheden) I AM-oplossing waarbij gebruik wordt gemaakt van een I AM-shared service center voor alle organisatieonderdelen, platformen en applicaties.

Onze conclusie is dat voor een internationale organisatie het optimale scenario een gemeenschappelijke I AM-oplossing is, gebruikmakend van een I AM-shared service center voor een beperkt aantal gemeenschappelijke, organisatiebrede systemen evenals voor de bedrijfskritische toepassingen.

Literatuur

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

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

‘Zoveel functiescheidingsconflicten in SAP – dat kan nooit’, en waarom is dat eigenlijk een risico?

In Compact 2001/6 hebben wij in het artikel ‘Richt jij de autorisaties even in?’ de complexiteit van het SAP R/3-autorisatieconcept beschreven. In dat artikel is door middel van een vergelijking van veertig SAP R/3-beveiligingsonderzoeken gebleken dat op alle onderzochte gebieden, van de basismaatregelen tot de inrichting als het beheer, veel tekortkomingen zijn geconstateerd. De laatste jaren hebben veel organisaties, mede vanuit de druk van de Sarbanes-Oxley Act en de code-Tabaksblat, de SAP-autorisaties onder de loep genomen en verbeteracties doorgevoerd. Daarnaast zien wij op het gebied van ondersteunende tooling duidelijk meer aanbod in de markt van volwassen producten. Voor ons een goede aanleiding om het onderzoek te herhalen.

Inleiding

In 2001 is door middel van onderzoek aangetoond dat de kwaliteit van de logische toegangsbeveiliging in SAP op dat moment voor veel organisaties van onvoldoende niveau is. Wij zullen die resultaten eerst kort herhalen. De aandacht voor de logische toegangsbeveiliging in SAP is door de introductie van de code-Tabaksblat en de Sarbanes-Oxley Act toegenomen. Organisaties worden nu door wet verplicht aan te tonen dat ze orde op zaken hebben gesteld. Daarnaast zijn ook migraties, het gebruik van tooling en het opbouwen van meer kennis voor ons aannames geweest om te verwachten dat er verbetering moet zijn opgetreden. Voor ons daarom aanleiding om het onderzoek van 2001 in 2006 te herhalen, op basis van achtentwintig audits en quick scans, uitgevoerd in 2005 en 2006 op het gebied van de logische toegangsbeveiliging in SAP. Daarbij hebben wij ons de volgende vragen gesteld:

  • Zijn de resultaten op het gebied van de logische toegangsbeveiliging voor SAP verbeterd?
  • Wat zijn de belangrijkste oorzaken, zijn onze tips opgevolgd? Op basis van onze praktijkervaring hebben wij namelijk in 2001 een aantal tips gegeven. Wij zullen deze tips kort de revue laten passeren.

Op basis van de uitkomsten van ons onderzoek in 2006 wordt door ons wederom een aantal praktische tips gegeven voor het gebruik van ondersteunende tooling en het definiëren van de functiescheidingsregels. Bij het geven van de ‘nieuwe’ tips baseren wij ons niet alleen op de resultaten van het onderzoek, maar ook op onze observaties in de praktijk tijdens onze advieswerkzaamheden.

De resultaten uit 2001

De resultaten van het onderzoek in 2001 naar de kwaliteit van de SAP-autorisaties (logische toegangsbeveiliging) laten zich als volgt samenvatten:

  • De basisbeveiliging is niet in orde. Eenvoudige instellingen op het gebied van identificatie en authenticatie zijn niet geactiveerd. Er zijn veel gebruikers met ‘super’-rechten.
  • Op het gebied van functiescheiding is het niveau slecht. De toegang tot kritieke technische en functionele transacties is niet eenduidig belegd. Ook combinaties van ongewenste transacties komen te veelvuldig voor.
  • Organisaties hadden hun gebruikers- en autorisatiebeheer op redelijk voldoende niveau georganiseerd, al waren de documentatie en het beheer van de inactieve gebruikers weer ver onder de maat. De transparantie kan worden verbeterd.
  • Organisaties hadden vaak voor een slecht beheersbare autorisatiestructuur gekozen, die met name was gebaseerd op ‘enkele rollen’ (of zoals dat toen heette ‘activiteitgroepen’).

In figuur 1 ziet u de resultaten uit 2001 per deelgebied van dat betreffende onderzoek. Deze figuur laat bijvoorbeeld zien dat bij zeventig procent het beheer van inactieve gebruikers onvoldoende plaatsvindt (rood), bij twintig procent wordt dit redelijk uitgevoerd (oranje) en slechts tien procent heeft het beheer van inactieve gebruikers onder controle.

C-2006-2-Vreeke2-1

Figuur 1. Bevindingen uit de praktijk – juni 2001.

De belangrijkste oorzaken van de bovengenoemde slechte resultaten waren volgens ons:

  • De opzet en inrichting van de autorisaties vindt vaak te geïsoleerd door technisch beheerders plaats. Er is te weinig afstemming met de processpecialisten. Ook ontbreekt er vaak een procesgebaseerde risicoanalyse om te komen tot de eisen van de autorisaties.
  • Het haastwerk waarmee autorisaties vaak in projecten zijn opgezet, veelal door onervaren of door te druk bezette personen in het project.
  • Het belang van een goed werkend autorisatieconcept als maatregel van interne controle werd onderschat.
  • De complexiteit van het autorisatieconcept in SAP, zowel in de opzet en inrichting van de autorisaties als op het gebied van goede rapportages. Een fout is snel gemaakt. Beide schrijvers van dit artikel hebben vaak ongelovige reacties gekregen naar aanleiding van de uitkomsten van hun onderzoeken.

In het algemeen kan worden gesteld dat er op het gebied van autorisaties weinig voldoendes werden gegeven. Of het is een ‘goed‘ of het is een ‘zware onvoldoende‘. Het is namelijk de attitude en de professionaliteit van de organisatie die bepalend is voor de kwaliteit van de autorisaties. Een beetje goed beveiligd bestaat dan niet.

Aandacht voor SAP-autorisaties opgekrikt door externe wetten en codes

Door de invoering van de code-Tabaksblat en de Sarbanes Oxley Act is het SAP-autorisatieconcept door veel organisaties flink onder de loep genomen. Dit omdat er vanuit deze wetgeving hogere eisen werden gesteld aan de transparantie en kwaliteit van de autorisaties, inzake de rapportage over functiescheidingen, maar ook voor wat betreft de effectiviteit van autorisaties als maatregel van interne controle.

De wetgeving eist dat de bestuurders aangeven ‘in control’ te zijn over hun processen. Met andere woorden, dat de maatregelen van interne controle over een periode effectief zijn geweest. Omdat één van die belangrijke typen maatregen van interne controle ‘de functiescheiding’ is, hebben veel ondernemingen de afgelopen jaren aandacht geschonken aan de autorisaties in de systemen. Functiescheiding als het scheiden van opeenvolgende taken en bevoegdheden in de waardekringloop om fraude te voorkomen. Door het realiseren van functiescheidingen in het systeem wordt het gewenste tegengestelde belang van functies verankerd in de systemen.

Daarnaast vormen autorisaties in het systeem naast een heel effectieve controle, vanwege het preventieve geautomatiseerde karakter, ook een heel efficiënte controle. Efficiënt in het licht van de ‘total costs of compliance’. Om aan te tonen dat internecontrolemaatregelen effectief zijn geweest over een bepaalde periode moet het management tests uitvoeren. De grootte van de steekproef, lees het aantal tests, is afhankelijk van het type en de periodiciteit van de controle. Een controle uitgevoerd door het systeem (zoals autorisaties) vereist veel minder testwerk. Om het systeem van interne controle zo effectief en efficiënt te maken is de applicatie steeds meer als middel centraal komen te staan om controles uit te oefenen. Waar organisaties vroeger maatregelen om SAP hadden geïmplementeerd, hebben zij duidelijk geïnvesteerd om steeds meer controlemaatregelen in SAP in te richten. Een trend die binnen KPMG wordt aangeduid als ‘controls transformation’. Controls transformation om uiteindelijk de ‘total costs of compliance’ te reduceren. Naast autorisaties zijn andere bekende voorbeelden van ‘application embedded controls’ specifieke configuraties, customizing op het gebied van toleranties, validaties, automatische boekingsgangen en verplichte velden.

Vanwege bovenstaande ontwikkelingen (1) de introductie van codes en wetten, die eisen dat de interne controle wordt verscherpt en (2) de wens om controles in de applicatie te verankeren, kan verwacht worden dat er tevens meer aandacht is geschonken aan logische toegangsbeveiliging. Omdat organisaties ook dienen te rapporteren over de autorisaties, zien wij een toenemend gebruik van tools. De zojuist geschetste ontwikkelingen zouden moeten resulteren in een positiever beeld over de logische toegangsbeveiliging in SAP.

Migraties en leereffecten

Een andere belangrijke ontwikkeling die zich de laatste vijf jaar heeft doorgezet, is het gebruik van ‘nieuwe’ SAP-specifieke functionaliteiten om autorisaties in te richten en te beheren. Zo is er nagenoeg niet één organisatie meer, die zonder ‘profile generator’ werkt. Eerlijkheidshalve moet gezegd worden, dat wij ze nog steeds tegenkomen, maar slechts heel af en toe. Ook maken steeds meer organisaties gebruik van het afleiden (‘deriven’) van de (samengestelde) rollen. Bij migraties naar nieuwe versies zijn vaak ook de autorisaties niet één op één overgenomen, maar hebben ze vaak een facelift gekregen. Met name omdat met het gebruik van de nieuwe tools ook efficiency in het beheer kan worden bereikt. En met autorisaties in SAP geldt des te sterker dat als je het één keer fout gedaan hebt en het daarna hebt mogen beheren, dat je dan weet wat je volgende keer anders zou willen doen. Misschien is de druk vanuit de codes en wetten voor veel beheerders dan ook een geschenk geweest.

De resultaten uit 2006

In juli 2006 zijn de resultaten van achtentwintig quick scans beoordeeld. In de populatie van onderzochte ondernemingen zitten hoofdzakelijk ondernemingen die ook zijn meegenomen in het onderzoek van juni 2001, daar de auteurs mede in het kader van ondersteuning jaarrekening deze onderzoeken uitvoeren. De ontwikkelingen op het gebied van de externe wetten en codes en die van de additionele functionaliteit in de nieuwe versies van SAP zouden een duidelijke verbetering moeten laten zien. Figuur 2 geeft de resultaten van dit onderzoek weer.

C-2006-2-Vreeke2-2

Figuur 2. Bevindingen uit de praktijk – augustus 2006.

Gelukkig, de eerste blik laat ons meer groen en oranje zien, maar rooskleurig is het zeker nog niet. Wij kunnen dan ook toch de volgende conclusies trekken:

  • Er zijn nog steeds geen grijze gebieden. Organisaties scoren over alle punten of goed of slecht. In 2006 hebben meer organisaties beter gescoord. Er blijven echter organisaties tussen zitten, waarvan het niveau onvoldoende is.
  • De basisbeveiliging is over het algemeen verbeterd, maar laat nog steeds te wensen over. Bij elf van de achtentwintig respondenten zien wij nog steeds een overmaat van ‘super’-gebruikers actief. Ook heeft bijna vijftig procent van de respondenten nog niet de juiste parameters ingericht en gebruikgemaakt van de tabel om zeer kritische transacties te blokkeren. Duidelijk verbeterd zijn de beveiliging van de systeemstatus en het beveiligen van de standaard-user-id’s.
  • Op het gebied van de inrichting zien wij over de hele linie inderdaad de verbetering die wij verwachtten, al is nog steeds bij eenderde van de organisaties de toegang tot kritieke functionele transacties of combinaties van transacties onvoldoende. Bij ongeveer vijftig procent van de respondenten is de inrichting redelijk. Alleen bij tien procent van de respondenten, gelijk aan de score in 2001, is het goed op orde.
  • Op het gebied van het beheer van de autorisaties zien wij over de hele linie een duidelijke verbetering. Hiervan zijn het ontstaan van competence centers en het gebruik van ondersteunende tools de belangrijkste oorzaken.

Opvolging tips 2001

In het artikel in 2001 hebben wij de lezer een aantal tips meegegeven. In het vervolg van dit artikel zullen wij onze tips nog eens kort doorlopen en kijken hoe de ondernemingen met deze aandachtspunten zijn omgegaan. In tabel 1 ziet u de trend in kolom 2, plus een korte verklaring in kolom 3. Het vervolg van deze paragraaf geeft een verdere toelichting hierop.

C-2006-2-Vreeke2-t1

Tabel 1. De tips van 2001, trends en uitleg.

Tip 1. Quick Win Autorisatieprofielen voor beheerders

In veel van de onderzochte SAP-applicaties valt het op dat de beheerders niet standaard meer een SAP_ALL-profiel hebben. Ten opzichte van 2001 zijn er nu wel speciale autorisatierollen gebouwd voor beheerders, interne en externe consultants en auditors. Vaak hebben de beheerders nu zelfs geen mutatiebevoegdheid meer in het productiesysteem en hebben zij alleen weergavebevoegdheid in de applicatie (naast de bevoegdheid voor hun dagelijkse werkzaamheden). Met bijvoorbeeld de KPMG Security Explorer of andere tools is het mogelijk aan te tonen van welke transactiecodes een beheerder gebruik heeft gemaakt. Hierdoor vervalt over het algemeen al snel het argument van de beheerder dat hij alle bevoegdheden nodig heeft voor zijn dagelijkse werkzaamheden. Eventueel kan via de Security audit log worden getraceerd welke transactiecodes een bepaalde beheerder gedurende een bepaalde periode heeft gestart.

Tip 2. Verwijder superusers

Ten opzichte van 2001 is duidelijk waar te nemen dat het aantal SAP_ALL-gebruikers in het systeem is afgenomen. Eén van de belangrijkste redenen hiervoor is ook dat de bevoegdheden van de beheerders zijn ingeperkt. Daarnaast wordt het profiel SAP_ALL niet meer snel tijdelijk uitgegeven. In geval van nood is er vaak een Emergency SAP_ALL-gebruiker aanwezig die gebruikt kan worden en waar de activiteiten van worden gelogd. Moderne tools, zoals Virsa, ondersteunen het actief monitoren van gebruikers die tijdelijk alle bevoegdheden in het systeem hebben (SAP_ALL-bevoegdheid).

Tip 3. Gebruik de kennis van uw externe adviseur voor parameters en tabelwaarden

Bij veel ondernemingen zijn de parametersettings ten opzichte van 2001 geoptimaliseerd. Indien naar een nieuwe SAP-versie wordt gemigreerd, moet men er wel rekening mee houden dat er nieuwe parametersettings mogelijk zijn. Zo zijn er in SAP ECC 5.0 parameters geïntroduceerd waarmee de geldigheidsduur van paswoorden kan worden beïnvloed (een nieuw paswoord is vijf dagen geldig) of de hoeveelheid letters, getallen of speciale karakters die het paswoord minimaal moet bevatten.

Tip 4. Logging

In 2006 hebben de meeste ondernemingen nog steeds geen logging geactiveerd. Belangrijkste reden hiervoor is dat de meeste ondernemingen niet weten welke tabellen er gelogd moeten worden. Daarnaast staan er per default redelijk veel tabellen geactiveerd voor logging.

Tip 5. Test de profielen naast positief ook negatief

Het belang van negatief testen wordt nog vaak onderschat. De negatieve test heeft meestal als insteek om te testen of medewerkers geen toegang hebben tot bepaalde gedeelten van de organisatie. Een goede negatieve test moet echter ook de weergaveprofielen testen. Autorisatieobjecten die in weergaverollen mutatiebevoegdheid bevatten, moeten worden aangepast. Hierbij is het aan te raden om gebruik te maken van transactiecode SU24 om de waarden binnen de objecten voor de profiel generator aan te passen. In 2006 zien we nog steeds dat er redelijk veel negatieve fouten in rollen zitten. Vooral op het gebied van weergaveprofielen zien we dat de rollen vaak ook mutatiebevoegdheden bevatten. Deze rollen an sich werken prima, echter in combinatie met andere rollen kan dit tot gevolg hebben dat gebruikers te veel bevoegdheden krijgen. Zo kan een weergavebevoegdheid systeemoverschrijdend zijn en kunnen de updateprofielen plantspecifiek zijn. Indien een weergavebevoegdheid vervolgens ook mutatiebevoegdheid bevat dan kan door de combinatie van rollen de gebruiker systeemoverschrijdend muteren. De gebruiker krijgt immers de transactiecodebevoegdheid uit de mutatierol en de autorisatieobjectbevoegdheid uit de weergaverol.

Tip 6. Kies een evenwichtige structuur van autorisatieprofielen

In 2006 hebben wij gezien dat veel ondernemingen zijn afgestapt van de rolgebaseerde opzet en hebben gekozen voor een taakgebaseerde opzet (vaak wordt deze keuze gemaakt tijdens een migratietraject wanneer alle rollen toch moeten worden herzien of naar aanleiding van een rapportage van de interne of externe auditor over functievermenging). Belangrijk voordeel van een taakgebaseerde opzet is dat het een flexibele, onderhoudbare en controleerbare structuur is. Indien de taken verder inhoudelijk goed zijn gedefinieerd, kan men zelfs alle mogelijke functiescheidingen inrichten. Tevens geldt voor de evenwichtige autorisatiestructuur dat moet worden voorkomen dat transactiecodes uit de verschillende SAP-modules in een rol worden gestopt. Dit heeft immers een negatieve invloed op het afleiden van de rollen en het invullen van de organisatieniveaus.

Tip 7. Gebruik de autorisatiemogelijkheden zo beperkt mogelijk

Het SAP R/3-autorisatieconcept is zeer complex. Door veel autorisatiemogelijkheden te gebruiken zal een zeer complexe autorisatiestructuur ontstaan. Indien er te veel eisen aan het autorisatieconcept worden gesteld waardoor de autorisatiestructuur te complex wordt, dan dient een onderneming te onderzoeken of er ook andere controlemaatregelen zijn om het mogelijke risico te ondervangen. Hierbij kunnen bijvoorbeeld controlerapportages worden ingezet. Geconstateerd is dat de autorisatiespecialist in projecten beter gepositioneerd is, en dat er kritischer wordt nagedacht over de opzet van de autorisaties.

Tip 8. Combineer een top-down methodiek met een bottom-up methodiek

Met de bottom-up methodiek wordt aan de hand van de gebruikte functionaliteit in SAP een transactietakenmatrix gedefinieerd. De taken die worden gedefinieerd, dienen alleen die transactiecodes te bevatten waarmee een specifieke taak kan worden uitgevoerd. Daarnaast is het belangrijk om te voorkomen dat er functiescheidingen in een taak voorkomen. Op taakniveau kan vervolgens de business impact worden gedefinieerd. Toekenning van taken met een hoge business impact aan gebruikers kan alleen na expliciete toestemming van de verantwoordelijke business process owner. Daarnaast is het mogelijk op taakniveau functiescheidingsconflicten te definiëren.

Binnen de top-down approach worden de businessfuncties gedefinieerd. Hierbij worden de taken aan de hand van workshops en interviews aan functies toegekend. Door de functiescheidingsanalyse op taakniveau is het direct mogelijk om de blueprintfase vast te stellen of er in functies conflicten voorkomen, waarna het mogelijk is direct compenserende maatregelen te definiëren en te implementeren.

In de praktijk zien wij dat redelijk veel ondernemingen reeds gebruikmaken van een taakgebaseerd autorisatieconcept waarbij de taken in functies worden gegroepeerd door middel van verzamelrollen. Ook worden op basis van een procesgebaseerde risicoanalyse de top-down eisen aan de autorisaties gedefinieerd. Nadeel hierbij is dat het flexibele gebruikersmenu niet meer netjes wordt opgebouwd door de SAP-applicatie.

Tip 9. Isoleer kritische transacties in ‘dedicated’ profielen

Uit de resultaten van 2006 blijkt dat de meeste ondernemingen de kritische transactiecodes in aparte profielen hebben opgenomen. Belangrijkste reden hiervoor is ook dat ondernemingen zijn overgestapt van een rolgebaseerde opzet naar een taakgebaseerde opzet. Hierdoor krijgt een gebruiker die een bepaalde rol krijgt gekoppeld, niet meer automatisch toegang tot de technische transactiecodes. Vooral het aantal gebruikers die toegang hebben tot het direct muteren van tabellen is afgenomen. Tevens zien wij in 2006 dat ook de bevoegdheid voor het direct opstarten van ABAP-programma’s vrijwel niet meer aan eindgebruikers wordt gegeven. In plaats hiervan worden maatwerktransactiecodes ontwikkeld die via de normale weg aan rollen worden gekoppeld.

Tip 10. Kies een heldere naamgeving

Bij de meeste onderzochte ondernemingen was uit de definitie van de rol te identificeren wat de inhoud van de rol ongeveer was. In de naamgeving van de rollen is meestal opgenomen voor welke module de rol is gemaakt en wat voor type bevoegdheid de rol bevat. Hierbij wordt vaak onderscheid gemaakt tussen weergave, rapportages en stamgegevens. Tevens valt uit de resultaten van 2006 op dat in de nieuwere versies van SAP (4.7, 5.0) vaak de profielnaam niet meer wordt aangepast. Nadeel hiervan is dat er minder mogelijkheden zijn om te zoeken in tabellen (minder tabellen om goed in te kunnen zoeken).

Tip 11. Beveilig ook het maatwerk

Uit de resultaten van 2006 blijkt dat er meer en meer aandacht wordt geschonken aan het beveiligen van maatwerk. De toegang tot maatwerk wordt steeds vaker afgeschermd door het aanmaken van nieuwe maatwerktransactiecodes, waardoor het eenvoudiger is om alleen aan een beperkt aantal gebruikers toegang te verschaffen tot het maatwerk. Daarnaast zien wij meer geprogrammeerde controles binnen het maatwerk. Dit geldt echter meestal alleen voor maatwerk waarmee gegevens kunnen worden aangelegd of worden gewijzigd. Binnen maatwerkrapportages, queries of COPA-rapportages treffen wij zelden geprogrammeerde controles aan.

Tip 12. Beheer inactieve gebruikers

In 2006 valt het op dat ondernemingen hun inactieve gebruikers goed beheren. De meeste ondernemingen hebben strikte procedures voor het beheren van hun inactieve gebruikers, waarbij na zestig dagen gebruikers worden geblokkeerd en waarbij na negentig dagen de gebruikers uit het systeem worden verwijderd. Een belangrijke reden hiervoor is enerzijds beveiliging, daar inactieve gebruikers niet misbruikt kunnen worden. Daarnaast kan het verwijderen van inactieve gebruikers ook een kostenbesparing opleveren, daar er minder aan licentiekosten hoeft te worden betaald. Tevens zien wij dat veel meer ondernemingen per gebruiker het type licentie aangeven. Het licentietype voor een gebruiker die alleen weergavebevoegdheid heeft of die alleen kan goedkeuren, kost minder dan een gebruiker die ook inkooporders en verkooporders moeten invoeren.

Tip 13. Gebruik en kennis van de tabellen en CATT

Met CATT of E-CATT kunnen in een korte periode veel rollen worden aangepast of worden aangemaakt met behulp van de profiel generator. Het gebruik van tabellen kan dienen om de kwaliteit van de inrichting te beoordelen. Zo kan met behulp van tabel AGR_1251 snel worden gecontroleerd of weergaverollen ook alleen weergavebevoegdheid bevatten op autorisatieobjectniveau. Dit is een controle die een onderneming eigenlijk periodiek zou moeten uitvoeren teneinde het kwaliteitsniveau van de autorisatie-inrichting te verhogen. In 2006 zien wij een toenemend aantal ondernemingen die gebruikmaken van CATT of E-CATT voor het aanleggen van rollen of gebruikers. Veel beheerders kennen echter de belangrijkste autorisatietabellen binnen SAP nog niet (UST-, AGR- en USR-tabellen).

Tip 14. Implementeer een goede impactanalyse op de beveiligingsaspecten als complexe beheerprocedures

Niet in scope van de onderzoeken in 2005 en 2006.

Tip 15. Gebruik van ondersteunende tools

In 2006 zien wij een duidelijk toename van ondernemingen die een geautomatiseerde tool gebruiken of er duidelijk interesse in hebben. Op het gebruik en het implementatietraject van dit soort tools gaan wij in het vervolg van dit artikel nog verder in.

Tip 16. Betrek uw eigen beheerders bij de ontwikkeling

In 2006 zijn wij bij redelijk veel ondernemingen competence centers ten behoeve van autorisatie tegengekomen. In deze competence centers zitten vaak meerdere fulltime beheerders die gespecialiseerde kennis hebben van het SAP R/3-autorisatieconcept. Deze beheerders zijn vaak nauw betrokken bij de inrichting of de uitrol van het SAP R/3-autorisatieconcept.

Tip 17. Genereer uw documentatie

Bij de meeste onderzochte ondernemingen in 2006 was er documentatie aanwezig maar was deze verouderd. Een aantal onderzochte ondernemingen had queries in SAP, SAP BW of MS Access gebouwd voor de documentatie van het autorisatieconcept. Veelal wordt direct naar SAP verwezen waar de documentatie uit kan worden gehaald.

De uitdagingen van nu

Wij hebben absoluut een aantal verbeteringen kunnen constateren. Maar zeker niet bij alle organisaties. Daarnaast zien wij dat organisaties op een aantal gebieden nog steeds problemen ondervinden. Deze observaties hebben wij niet alleen opgedaan gedurende onze auditwerkzaamheden, maar ook tijdens ons advieswerk. Daarnaast hebben wij bijzondere audits uitgevoerd op het gebruik en de inrichting van ondersteunde SAP security tools, zoals Virsa, Approva, SecurInfo en CSI.

Over de volgende onderwerpen geven wij u graag nog enkele praktische adviezen:

  • Het relateren van de SAP-autorisaties met de HR-organisatorische posities is vaak onmogelijk. Vaak is de personeelsafdeling niet betrokken bij de inrichting van de autorisaties. En daarnaast worden de rollen vaak te gemakkelijk gealloceerd aan gebruikers. Een verschijnsel dat wij ‘splitted roles’ noemen, treedt dan op. Dit verschijnsel heeft een negatieve invloed op het resultaat van standaardisatie- en harmonisatie-inspanningen. Zie tip A.
  • Het selecteren van een ondersteunende tool vindt vaak niet vanuit een bredere visie plaats. Ook is te weinig rekening gehouden met de complexiteit van het gebruik. Zie tip B.
  • Het nemen van beslissingen over de functiescheidingsconflicten blijkt een kunst op zich. Poolse landdagen zijn er vaak nodig om te komen tot de functiescheidingsmatrices. De hele wereld praat mee. En zodra ze er zijn, worden ze na elke scan weer in twijfel getrokken. ‘Dat kan nooit!‘ is een uitspraak die wij vaak gehoord hebben na het doen van onze onderzoeken. Zie tip C.
  • De uitspraak ‘Dat kan nooit!’ kan een gevolg zijn van een foutieve inrichting van de ondersteunende tools. De technische inrichting van de tool is namelijk complex. Zie tip D.

Tip A. Steek net zoveel effort (misschien zelfs meer) in het voorkomen van ‘splitted roles’ als in het voorkomen van functiescheidingen. Ken autorisaties eenduidig toe.

Een veelvoorkomende fout bij de allocatie van rollen aan gebruikers is dat men alleen let op de beperking van de functiescheidingen. Het lijkt soms wel een sport om zoveel mogelijk (samengestelde) rollen te koppelen aan eindgebruikers totdat de grenzen van de functiescheidingen zijn genaderd (of zelfs van de user buffer). Dit is een volkomen verkeerd uitgangspunt. Zeker waar het gaat om ook de transparantie van het autorisatieconcept. Bij deze insteek zullen de SAP-autorisaties hoogstwaarschijnlijk niet overeenkomen met wat de daadwerkelijke taken en verantwoordelijkheden van de natuurlijke personen in de organisatie zijn, zoals vastgelegd in de functiebeschrijvingen op de personeelsafdeling.

Wat is een ‘splitted role’?

Stelt u zich voor dat in een inkooprol twee taken zitten (naast allerlei weergaveactiviteiten):

  1. opvoeren contracten;
  2. afroepen orders.

Als u nu aan één persoon deze rol geeft, dan kan deze persoon beide taken uitvoeren in de organisatie en daarvoor dan ook op schrift de taken en verantwoordelijkheden hebben. U heeft een ‘splitted role’ gecreëerd wanneer aan twee natuurlijke personen de inkooprol wordt toegekend, waarbij de ene gebruiker alleen de contracten opvoert en de ander alleen de order afroept. Dit fenomeen is uitermate nadelig voor de transparantie van het concept.

Daar waar u eenduidiger bent in het toekennen van rollen zult u ook minder problemen hebben met functiescheidingen. Begrijpelijk, omdat de units door het accepteren van ‘splitted roles’ minder worden gedwongen het standaardbedrijfsproces te implementeren en hierdoor ook minder worden gedwongen om de eigen bedrijfsprocessen aan te passen.

Om ‘splitted roles’ te voorkomen, en dus echt standaardisatie te realiseren, zult u taken opnieuw moeten toekennen en medewerkers competent moeten maken (trainen) in de nieuwe activiteiten. Indien u dit bereikt is de link tussen SAP-autorisaties en de HR-functiebeschrijvingen transparant, wat een goede basis biedt voor performance management.

Een truc om achter het bestaan van ‘splitted roles’ te komen is te analyseren welke gebruikers van hun bevoegdheden geen gebruik hebben gemaakt gedurende de laatste drie maanden.

Wij zien veel organisaties met ‘splitted roles’, daar waar de uitrol van SAP niet voldoende gericht was op de organisatorische (menselijke) aspecten. De organisaties geven toe dan minder resultaat uit de standaardisatieactiviteiten te halen dan verwacht.

Tip B. Verdiep u en selecteer een ondersteunende tool op basis van een gedegen detailonderzoek. Het verschil zit hem in de details.

Tijdens de uitvoering van de toegangsbeveiligingsonderzoeken bleek dat veel ondernemingen geautomatiseerde tooling voor het beoordelen van functiescheidingsconflicten aan het implementeren zijn, of reeds gebruiken. Voor het efficiënt analyseren van functiescheidingen en het rapporteren over de autorisaties zijn tools eigenlijk een must. In de markt komen wij de volgende shortlist aan tools veelvuldig tegen voor de ondersteuning van het implementeren, beoordelen en continu monitoren van toegang in SAP. Dit type tools vindt u terug onder namen als ‘SAP Security Tools’ of ‘Compliance Management Software’ of ‘Governance, Risk and Assurance Platforms’. Let op! Na even googelen zult u zien dat het aanbod wereldwijd nog veel omvangrijker is. Enkele voorbeelden van tools, zonder volledig te willen zijn, worden in het vervolg kort toegelicht. Dit zijn de tools die wij het meest op de Nederlandse markt tegenkomen.

Virsa Compliance toolset

Een zeer uitgebreide toolset op het gebied van SAP Beveiliging. En sinds kort onderdeel van SAP. Sterke punten zijn de simuleringsfunctionaliteit en het detail van de beveiligingsregels. Daarnaast is ook de functiescheidingscheck tijdens realisatie een sterke functionaliteit. Een ander voordeel is het feit dat de tool nest in SAP en daardoor real-time is. Nadeel is dat de initiële inrichting van de regels complex en foutgevoelig is, dus echt expertwerk. (www.virsa.com)

Approva Bizrights

Een zeer sterke analysetool op het gebied van SAP-beveiliging. Ook is dit platform al ver op het gebied van business process monitoring op basis van SAP-data-extracten. Daarnaast kan deze tool cross-applicatie (zelfs niet SAP) functiescheidingsanalyses uitvoeren. De graphical user interface is mooi. De tool nest echter niet in SAP, is echt weggelegd voor de grotere complexere organisaties en ook het configureren van de regels is complex. (www.approva.net)

CSI Authorization auditor

Dit product van Nederlandse bodem blijft na jaren en ook met de nieuwe versies een zeer goed product. CSI AA is gewoon erg sterk in het doen van analyses. Daarnaast is het maken van de regels eenvoudiger dan bij Virsa en Approva. Zeer sterk en nog steeds daardoor als audit-tool onderscheiden (Virsa en Approva komen hiermee in nieuwere versies) is de functionaliteit van de ‘Varianten’. Zo kunnen de regels voor ranges van company codes gerund worden en hoeven niet per company code de regels te worden gedefinieerd en te worden gestart. De tool nest niet in SAP, en heeft soms moeite met heel grote omgevingen. De tool is meer geschikt als audit- en reporting-tool, dan dat zij het dagelijks beheer goed ondersteunt. (www.csi4sap.com)

SecurInfo

Een tool die buiten SAP draait, maar volledig met SAP geïntegreerd kan worden. In deze tool kunnen de autorisatierollen worden gedefinieerd en worden ingericht. Vervolgens kan met een risicoanalyse worden gecontroleerd of er, aan de hand van voorgedefinieerde regels, functiescheidingsconflicten in de rol zitten. Ook tijdens de toekenning aan de eindgebruiker wordt deze controle uitgevoerd. Indien via een controle conflicten zijn gedefinieerd, kan via workflow goedkeuring worden gevraagd aan de business process owner of aan de betreffende verantwoordelijke manager. Deze manager kan de conflicten alleen accepteren door een mitigerende controle te koppelen aan het conflict. Hierdoor wordt het eigenaarschap bij de business gelegd. Indien vervolgens ook de security manager akkoord is met de mitigerende controle kan de gebruiker worden goedgekeurd en via deze tool in SAP worden aangelegd. (www.securinfo.com)

Synaxion for SAP

Is een nieuw product op de markt op het gebied van SAP en is ook van Nederlandse bodem. Synaxion is al langer een erkend product op het gebied van data-analyse en performance reporting. De tool kan naast allerlei analyses op het gebied van autorisaties ook allerlei voorgedefinieerde analyses maken op het gebied van business controls (zoals openstaande facturen, ongeautoriseerde prijswijzigingen, etc.). Sterk aan de tool zijn de rapportagemogelijkheden. Zo kunt u eenvoudig de units ten opzichte van elkaar benchmarken, of het verloop van de functiescheidingen checken. Ook is deze tool in staat te rapporteren welke personen hoe vaak hun autorisaties gebruikt hebben. En of functiescheidingsconflicten ook echt doorbroken zijn. Dit is ook een functionaliteit die in de nieuwe CSI AA wordt aangeboden. Het inregelen van de regels is echter complex en vindt in de code plaats. (www.synaxion.nl)

Zelfontwikkelde BW-rapportages

Binnen een aantal door ons onderzochte ondernemingen wordt gebruikgemaakt van BW om rapportages over autorisaties en functiescheidingen te maken. Nadeel van dit soort rapportages is dat ze over het algemeen erg veel output genereren, waardoor de bruikbaarheid van de documentatie erg beperkt is. Op het niveau van functiescheidingsconflicten worden vaak rapportages gedraaid op het niveau van conflicterende functies. Hierbij worden vaak minder kritische functies over het hoofd gezien en niet in de uiteindelijke rapportages meegenomen, waardoor het aantal conflicten in het systeem vaak veel groter is dan daadwerkelijk gerapporteerd.

Zelfontwikkelde Excel of MS Access tooling

Net als bij de BW-rapportages kan er gebruik worden gemaakt van Excel of MS Access om rapportages te maken over het SAP R/3-autorisatieconcept.

De bovenstaande tools lijken in eerste instantie op elkaar, ze doen allemaal een goede scan, maar in de details zijn ze echt verschillend. Organisaties moeten daarom goed hun wensen en behoeften bepalen voordat zij een tool selecteren. De standaard-requirementlijst van KPMG’s SAP Advisory telt meer dan 150 criteria. Ook het kostenplaatje loopt tussen de tools zeer sterk uiteen.

Daarnaast zijn andere relevante aspecten van vergelijking van de tools:

  1. Het feit of de tool al dan niet deel uitmaakt van een breder Compliance Management Software Platform.
  2. De ondersteuning die de tool(set) biedt bij het ontwerpen, inrichten, testen, documenteren, monitoren en auditen van de autorisaties. Deze functionaliteiten kunnen gecombineerd voorkomen in de tool, maar de tool kan zich ook op een of enkele daarvan richten.
  3. Bijzondere functionaliteiten:
    • simuleren van functiescheidingsconflicten vanuit een bouwomgeving op gebruikers, composite- en single role-niveau;
    • uitsluiten van gebruikers in analyses bij aanwezigheid van compenserende maatregelen, waarvan de effectiviteit via workflow wordt getoetst;
    • classificatie van regels, bijvoorbeeld naar het kritieke gehalte zoals ‘high’, ‘medium’ en ‘low’;
    • automatisch genereren van een risico alert bij verboden combinaties;
    • geïntegreerde herstelplanning (remediation). Remediation van de risico’s kan op verschillende manieren plaatsvinden. De activiteiten op dit gebied dienen te kunnen worden gedefinieerd en bewaakt:
      • implementeren van een compenserende maatregel, die in de tool dient te kunnen worden beschreven en qua effectiviteit te worden bewaakt;
      • het ontkoppelen van autorisatierollen (een gebruiker heeft twee functies), met als gevolg dat de gebruiker op de volgende lijst niet meer voorkomt;
      • het aanpassen van autorisatierollen (een functie bevat een conflict), waardoor groepen van gebruikers afvallen;
      • het aanpassen van de autorisatieregels;
    • scenario’s/varianten bij autorisatiescanning (lijsten van regels afspelen voor meerdere organisatie-eenheden);
    • Change Tracking op de beveiligingsregels, waardoor u achteraf precies kunt vaststellen welke wijzigingen, wanneer en door wie hebben plaatsgevonden op de beveiligingsregels;
    • continue auditing of monitoring, waardoor de tool in staat is bijvoorbeeld de beheerder via sms of mail te alarmeren indien SAP_ALL gekoppeld wordt, of zodra heel kritische transacties worden opgestart;
    • functiescheidingschecks bij de realisatie, waardoor het systeem al bij de realisatie van enkele en samengestelde rollen waarschuwt zodra transacties worden gecombineerd.
  4. De kwaliteit van de tabelextractie, en daarmee direct samenhangend de kwaliteit van de analysemogelijkheden en de rapportage.
  5. De benodigde infrastructuur en de kwaliteit en snelheid van de data-extractie (indien niet real-time).
  6. De ‘levensvatbaarheid’ en de omvang van de leverancier.
Tip C. Het opzetten van de functiescheidingsmatrix

Proceseigenaren dienen actief betrokken te worden in het opzetten van de functiescheidingsregels. Het meest praktische hulpmiddel in de praktijk is het opzetten van een matrix, waarin u zowel in de eerste kolom als in de rij de rollen zet. Daar waar de rollen conflicteren zijn, zet u kruisjes. Een vereenvoudigd voorbeeld van een dergelijke (niet volledig ingevulde) matrix staat in figuur 3 weergegeven.

C-2006-2-Vreeke2-3

Figuur 3. Vereenvoudigd voorbeeld van een functiescheidingsmatrix. [Klik hier voor grotere afbeelding]

Tijdens workshops met business process owners en het verantwoordelijke management kunnen de functiescheidingsregels worden gedefinieerd. U doet dit tot op het niveau van de SAP-transacties. Anders kunt u niet de link naar de rollen maken. Over het algemeen is dit een behoorlijk tijdsintensieve activiteit waar het management verantwoordelijk voor is. Om van dit soort workshops een succes te maken is het van groot belang ze op te splitsen naar processtreams (Purchase-to-Payment, Order-to-Cash, Hire-to-Retire, Finance-to-Management) en vooraf matrices met conflicterende activiteiten voor te bereiden met een kleine groep van specialisten.

Nadat de functiescheidingsmatrix duidelijk is opgesteld, dienen de conflicten verder te worden uitgewerkt. Per conflict dient duidelijk en in ‘business’-termen te worden gedocumenteerd wat exact het bijbehorende risico is. Hiermee kan worden voorkomen dat business process owners of lokale managers achteraf gaan vragen waarom iets een risico is. Het risico moet hierbij ook duidelijk doch eenvoudig worden beschreven en onderdeel zijn van het validatieproces. Voorbeelden zijn:

  • Indien een persoon in staat is de recepturen aan te passen en de gereedmelding van producten te verzorgen, dan is hij in staat het productieresultaat te beïnvloeden.
  • Indien een persoon in staat is prijzen aan te passen en orders in te voeren, dan kan hij om zijn klanten tegemoet te komen, de geldende richtlijnen omzeilen.

Het verdient aanbeveling om voor elk kruisje in de functiescheidingsmatrix een heldere uitleg, in normale mensentaal, te geven van het risico voor het bedrijf. En deze uitleg ook als onderdeel van de matrix te valideren.

Ten aanzien van de matrix moet worden voorkomen dat men denkt dat de matrix onvolledig is, of dat de kruisjes een resultaat van willekeur zijn. Daarom moeten de organisatiespecifieke uitgangspunten achter de kruisjes in de matrix eenduidig worden vastgelegd, worden gecommuniceerd en ook worden gevalideerd. U moet eigenlijk met deze stap beginnen.

Voordat wordt begonnen met het definiëren van de functiescheidingsregels (het zetten van de kruisjes in de matrix) moeten de uitgangspunten bepaald worden, zodat de matrix een consistent geheel wordt. Indien dit niet gebeurt, dan kan/zal tijdens het vullen van de matrix van inzicht veranderd kunnen worden. Een referentiepunt wordt gemist. Het vullen van de matrix in een Excel-sheet, met plusminus 150 rijen en 150 kolommen, is geen sinecure, en soms lastig werk. Zeker om het overzicht te bewaren. Enkele voorbeelden van uitgangspunten zijn:

  • Rollen met toegang tot stamgegevens mogen binnen hetzelfde proces (of dezelfde module) geen registrerende activiteiten uitvoeren.
  • Rollen mogen geen combinatie van taken uitvoeren die opvolgend zijn in de waardenkringloop.
  • Geen rol moet in staat zijn de eigen targets te beïnvloeden.
  • Voor de wijziging van kritieke gegevens moet altijd een vierogenprincipe gelden.

Het eigenaarschap van de functiescheidingsmatrix dient hoog in de organisatie te worden belegd. Zodra dat is gebeurd, dient de eigenaar te communiceren naar eenieder, dat de matrix geen richtlijn is, maar een wet.

Zorg ervoor dat gecommuniceerd wordt door de eigenaar van de matrix (vaak de concern controller of hoofd financiën) dat de matrix een wet is.

Het kan voorkomen dat in sommige gevallen voor sommige conflicten een uitzondering geldt, indien er compenserende maatregelen zijn geïmplementeerd. Voor die conflicten die in het systeem zijn toegestaan, moet worden gedocumenteerd welke mitigerende maatregelen dienen te worden geïmplementeerd om het risico te beperken. Hierbij dient duidelijk te worden gemaakt dat het lokale management van de onderneming verantwoordelijk is voor de implementatie en de uitvoer van de mitigerende maatregelen en dat periodiek dient te worden getoetst of de maatregel ook daadwerkelijk wordt uitgevoerd. In goede functiescheidingsmatrices staat met kleuren of indicatoren weergegeven, of er voor een functiescheidingsconflict compenserende maatregelen moeten worden geïmplementeerd en zo ja, voor welke functiescheidingsconflicten dat geldt. Het monitoren of compenserende maatregelen hebben gewerkt, dient te worden ingebed in de organisatie

Vaak komen functiescheidingsconflicten voor in relatief kleine business units. Uit die business units kan bijvoorbeeld de reactie komen dat de afdelingen te klein zijn om functiescheiding te waarborgen. Een mogelijke reactie van het corporate management zou dan kunnen zijn om de werkzaamheden te verplaatsen naar groep- of clusterniveau of gebruik te gaan maken van het shared service center. Let op! Deze reactie kan confronterend zijn en moet dus met enige omzichtigheid worden gebracht.

Tip D. Technische inrichting van de tool

Met de technische inrichting van de tool wordt bedoeld het inregelen van de beveiligingsregels. Dit zijn de auditregels waarmee de gebruikers worden geïdentificeerd die een functiescheidingsconflict in de aan hen toegekende bevoegdheden hebben zitten. U moet om tot deze regels te komen een aantal inrichtingskeuzen maken. Hier volgen enkele tips die u helpen de juiste keuzen te maken.

Keuze 1. Scope van transacties

Bij het inrichten van de regels kunnen twee verschillende keuzen worden gemaakt:

  1. inrichten alleen op transactiecodes op basis van de organisatiespecifieke transaction process master list (TPML);
  2. inrichten op alle transactiecodes waarmee het mogelijk is de activiteit uit te voeren, op basis van alle transacties die in SAP zitten.

De eerste methode lijkt de meest eenvoudige methode, de tweede methode is de meest complete. In het eerste geval is het immers mogelijk dat bepaalde conflicten niet gerapporteerd worden doordat één van de mogelijke transactiecodes niet is meegenomen in het auditfilter, maar mogelijk via wijzigingsbeheer toch in de rollen terecht is gekomen. Dit kan tot vervelende verrassingen leiden tijdens de jaarrekeningcontrole (minder in control dan gedacht). Daarnaast komt het voor dat er niet een unieke transactiecode is om een activiteit uit te voeren. Indien we naar het aanmaken/wijzigen van bijvoorbeeld een inkooporder kijken, dan zijn er in SAP de volgende transactiecodes te onderkennen: ME21, ME22, ME21N, ME22N, MEPO (afhankelijk van de SAP-versie). Daarbij kan het voorkomen dat de onderneming zelf ook nog een aantal transactiecodevarianten heeft ontwikkeld voor het invoeren van een inkooporder. Deze dienen ook in de auditfilters te worden opgenomen. Wij adviseren in de regel om de tweede optie te kiezen; dat betekent bij de initiële inrichting meer werk, maar maakt het onderhoud van de regels beperkt.

Keuze 2. De inrichting op autorisatieobjectniveau

Indien een onderneming op de output van zo’n tool wil kunnen steunen, dan is het heel belangrijk dat de in deze tools opgenomen audit queries adequaat zijn.

Het technisch instellen van de regels in de tool is echt expertwerk. Daarbij dient u een combinatie aan te wenden van experts van uw SAP-systeem, de toolexpert en de SAP-security expert. Wij kunnen op basis van onze laatste audits concluderen, dat veel regels in de tool vaak onjuistheden bevatten op objectniveau en onvoldoende rekening houden met de systeemspecifieke eigenschappen. Onjuiste regels resulteren in ‘false positives’ en/of ‘false negatives’. De geautomatiseerde tool zal namelijk rapporteren over gebruikers die én de combinatie van conflicterende transactiecodes hebben én de relevante autorisatieobjecten om de transactiecodes binnen het conflict volledig te kunnen uitvoeren. Het is hierbij dus belangrijk dat de beveiligingsregels de juiste autorisatieobjecten met de juiste waarden bevatten:

  • te veel objecten: de kans is aanwezig dat niet alle gebruikers die de activiteit daadwerkelijk kunnen uitvoeren ook worden gerapporteerd (false positives);
  • te weinig objecten: de kans is aanwezig dat gebruikers worden gerapporteerd die de activiteit niet kunnen uitvoeren (negatives).

Het bepalen van het gebruik van autorisatieobjecten is een activiteit die specialistische kennis van het SAP R/3-autorisatieconcept, de autorisatie-inrichting, de configuratie van het systeem en het gebruik van verplichte velden in masterdata vereist. Quick wins kunnen worden behaald in het beoordelen van de optionele autorisatieobjecten in SAP. De optionele autorisatieobjecten zijn objecten die gecontroleerd worden indien bepaalde customizing settings of bepaalde velden in stamgegevens zijn onderhouden. Een eenvoudig voorbeeld is transactiecode FB01 in SAP. In tabel 2 staan de autorisatieobjecten weergegeven die volgens tabel USOBT door deze transactiecode worden gecontroleerd. Tevens staan de belangrijkste kenmerken opgenomen van deze objecten.

C-2006-2-Vreeke2-t2

Tabel 2. In SAP voorgestelde autorisatieobjecten voor transactiecode FB01. [Klik hier voor grotere afbeelding]

De meeste ondernemingen onderhouden geen bevoegdheidsgroepen en hebben geen business areas ingericht. Dit heeft tot gevolg dat een audit query voor transactiecode FB01 alleen op autorisatieobject F_BKPF_BUK en F_BKPF_KOA zal controleren.

Een andere belangrijke vraag in de technische realisatie is de vraag hoe de tool omgaat met meerdere veldwaarden in een object. Indien de tool meerdere waarden in een object behandelt met een AND-Logic, dan houdt dat in dat een gebruiker alle waarden in het object moet hebben voordat hij gerapporteerd zal worden. Indien via een audit query specifiek gekeken wordt naar waarde 01 en 02 en 03, dan zal een gebruiker die alleen waarde 01 heeft dus al niet meer worden gerapporteerd. Een tool die de OR-Logic gebruikt voor veldwaarden zal deze gebruiker wel rapporteren.

Keuze 3: Gebruik van default of organisatiespecifieke regels

De meeste van de aangeboden tools bevatten al voorgedefinieerde regels. De standaard door de toolleverancier aangeboden regels bevatten over het algemeen een goed technisch startpunt, echter niet meer dan dat. Deze content is immers niet in overeenstemming met de door het management bepaalde gewenste functiescheiding en is niet in overeenstemming met de configuratie van het R/3-systeem en de behoefte van de onderneming.

Voorkom te allen tijde ‘false positives’ en ‘false negatives’. Zodra er één fout wordt ontdekt, zal er alles aan worden gedaan om de geloofwaardigheid van de tool ter discussie te stellen en de resultaten te ondermijnen. Als een lopend vuurtje door de organisatie zal dan het rumoer klinken dat de tool niet betrouwbaar is. Met de technische implementatie van de auditfilters valt of staat de gehele tool.

Samenvattend

Vergeleken met de resultaten van 2001 is de kwaliteit van de inrichting van het autorisatieconcept over de hele linie verbeterd. Echter, het blijft gelden dat een grijs gebied niet bestaat. Organisaties doen het of goed of slecht. Er zijn dus meer organisaties aangetroffen waar het beter gaat. Belangrijkste oorzaken hiervan zijn volgens ons de invoering van wetgevingen zoals SOX en Tabaksblat, het ontstaan van SAP-autorisatie competence centers en het gebruik van ‘nieuwe’ functionaliteit zoals afgeleide rollen (activity groups), object inheritance en samengestelde rollen. Als reactie op de wetgeving zijn veel ondernemingen intensief aan de slag gegaan met het SAP R/3-autorisatieconcept door middel van een herimplementatie van het SAP R/3-autorisatieconcept of de ingebruikname van Compliance Management Software, lees ondersteunende tooling. Veel ondernemingen zijn op dit moment zeer geïnteresseerd in ondersteunende tooling voor SAP R/3-autorisaties. Zij maken daarin helaas vaak niet een weloverwogen keuze en hebben moeite de tools goed in te regelen. Niet alleen vanuit de techniek. Het opstellen, implementeren en communiceren van de functiescheidingsmatrix die vaak de basis is van de regels in de tool blijkt een nachtmerrie te zijn binnen veel organisaties. Oorzaken hiervan zijn vaak het niet bij het project betrekken van de proceseigenaren, het vergeten van het benoemen van de uitgangspunten, het niet duidelijk maken in businesstermen waarom een conflict een risico is en het niet hoog genoeg beleggen van het eigenaarschap in de organisatie. De resultaten van de scans worden dan continu ter discussie gesteld.

Een andere observatie op basis van onze advieswerkzaamheden is dat de allocatie van rollen vaak niet eenduidig gebeurt en dat daardoor bepaalde verwachte standaardisatieresultaten niet gerealiseerd worden. Zie onze opmerkingen over ‘splitted roles’.

De toekomst in SAP op het gebied van beveiliging zal nog uitdagender worden. Het concept van de ‘Service Oriented Architecture’ of ‘Enterprise Service Architecture’ dat SAP zal kenmerken, zal infrastructuurbeveiliging en applicatiebeveiliging meer integreren. Ook zal de totale logische toegangsbeveiliging over meerdere applicaties (intern/extern) dienen te worden opgezet, geïmplementeerd en bewaakt. Dus zeker een kans dat wij rond 2010 het onderzoek weer herhalen.

Effectief gebruik van key risk indicators

Het Basel II Comité schrijft in zijn Sound practices for the management and supervision of operational risk voor dat banken indicatoren dienen te identificeren die een verhoogd risico op toekomstige verliezen signaleren. Dit artikel beschrijft hoe deze zogenaamde key risk indicators (KRI’s) kunnen worden toegepast binnen primaire en ondersteunende beheersingsprocessen en hoe zij het mogelijk maken om het optreden van risico’s tijdig te signaleren met als doel adequaat te reageren door het nemen van passende maatregelen.

Inleiding

Het Basel II Akkoord dat van toepassing is op de Europese bancaire wereld is naast onder andere de Sarbanes-Oxley wetgeving een (veelomvattende) regelgeving waar internationaal opererende banken mee geconfronteerd worden. Basel II geeft kwantitatieve en kwalitatieve eisen om risico’s af te dekken en te mitigeren. Eén van de risicocategorieën die binnen Basel II worden onderscheiden, is operationeel risico. Ten opzichte van het Basel I Akkoord is dit een nieuwe risicocategorie, waaronder ook de risico’s vallen die samenhangen met het gebruik van systemen. In de ‘sound practices for operational risk management’ van het Basel II Comité is aangegeven dat key risk indicators (KRI’s) kunnen worden gebruikt om inzicht te krijgen in de mate waarin operationeel risico zich voordoet binnen een bank. Het Basel II Akkoord beschrijft niet op welke wijze deze KRI’s dienen te worden geïdentificeerd en beschreven. Dit artikel laat zien dat KRI’s ook bruikbaar zijn voor het monitoren/verkrijgen van inzicht in risico’s op het vlak van IT general controls. Het start met een definitie van KRI’s en een korte toelichting op het gebruik van KRI’s binnen operationeel risicomanagement. Vervolgens beschrijft het welke eisen gesteld kunnen worden aan KRI’s en op welke wijze KRI’s het beste kunnen worden geïdentificeerd.

Op basis van praktijkervaring beschrijven wij in dit artikel hoe KRI’s het beste kunnen worden ingezet om het optreden van risico’s effectief te monitoren en op welke wijze KRI’s in de praktijk worden gebruikt. De wijze waarop KRI’s kunnen worden gebruikt voor het signaleren van risico’s binnen processen en de onderliggende IT general controls, wordt toegelicht aan de hand van een voorbeelduitwerking van een hypothekenproces.

Kader 1. Basel II Akkoord.

In november 2005 is het definitieve rapport uitgebracht door het Basel Committee on Banking Supervision (‘het Basel Comité’) betreffende de internationale convergentie van de richtlijnen voor toezicht op de solvabiliteit van internationaal opererende banken.

In de Basel II-richtlijnen wordt een driedeling geïntroduceerd, de zogenaamde ‘pijler’-benadering. De drie pijlers worden geacht elkaar in werking te versterken.

  • Pijler I behandelt de minimumkapitaaleisen (het zogenaamde regulatory capital). In deze pijler wordt met name ingegaan op de nieuwe methoden voor de berekening van de minimumkapitaaleisen voor kredietrisico, operationeel risico en handelsportefeuillekwesties (waaronder marktrisico) op basis van een classificatie van klanten die afwijkt van het Basel I Akkoord. De richtlijnen geven voor krediet- en operationeel risico een aantal berekeningsmethoden die verschillen in geavanceerdheid.
  • Pijler II richt zich op de rol van toezichthouders en de economische kapitaalseisen. In Nederland wordt van De Nederlandsche Bank verwacht dat zij nagaat hoe goed banken hun kapitaalbehoeften ten opzichte van de risico’s beoordelen en dat zij waar nodig ingrijpt. Hiertoe vertaalt DNB momenteel de Basel II-voorschriften naar Nederlandse regelgeving. Pijler II beschrijft ook de kwalitatieve aspecten van risicomanagement.
  • Pijler III richt zich op transparantie naar de markt en beschrijft de vereisten met betrekking tot de verstrekking van informatie aan stakeholders. Deze pijler beschrijft de toelichtingseisen met betrekking tot risk management. Het doel hiervan is dat stakeholders beter inzicht krijgen in het risicoprofiel en het risicomanagement van de instelling, waardoor de marktdiscipline wordt bevorderd.

Key risk indicators en operationeel risicomanagement

Het eerste deel van dit artikel geeft meer achtergrondinformatie over het begrip key risk indicator en operationeel risicomanagement in het algemeen, alvorens in het tweede gedeelte van dit artikel in wordt gegaan op KRI’s in de praktijk.

Het begrip key risk indicator

In de ‘sound practices for operational risk management’ ([BIS03]) definieert de BIS (Bank for International Settlements) Risk Indicators als volgt:

‘Risk indicators zijn statistieken en/of eenheden, vaak financieel van aard, die inzicht kunnen verschaffen in de risicopositie van een bank. Deze indicatoren worden in het algemeen periodiek gereviewd (maandelijks of per kwartaal) om banken attent te maken op veranderingen die op risico’s kunnen duiden. Zulke indicatoren kunnen het aantal mislukte transacties, personeelswisselingen en de frequentie en/of de impact van fouten of verzaken zijn.’

Key risk indicators zijn de voornaamste ‘early warning’-signalen die signaleren wanneer de kans bestaat dat een verlies zich zal voordoen als gevolg van een bestaand risico. Het doel van deze KRI’s is de binnen een organisatie relevante risico’s te signaleren om te voorkomen dat deze zich manifesteren en leiden tot verliezen. Op basis van deze signalen kan de organisatie besluiten additionele maatregelen te treffen om te voorkomen dat het risico zich daadwerkelijk voordoet. Daarnaast draagt monitoring van KRI’s bij aan een risicobewustzijn bij medewerkers, zeker wanneer deze monitoring wordt geïntegreerd in performance management.

KRI’s bestaan uit financiële, operationele en procesindicatoren die een continu voorspellend inzicht geven in de mate waarin een organisatie risico loopt binnen haar systemen, processen, producten, mensen en omgeving ([Dresd03]). Het verschil met loss data (gegevens over opgetreden operationele verliezen) is de toekomstgerichtheid van KRI’s. KRI’s zijn gericht op het signaleren van situaties waarin mogelijke toekomstige verliezen kunnen optreden.

KRI’s verschillen daarnaast van risk selfassessments, doordat zij zich baseren op waarneembare feitelijke data en niet op (eigen) schattingen van toekomstige situaties en activiteiten. Zij kunnen zowel preventief (ex ante) als detectief (ex post) van aard zijn. De meest krachtige risk indicators zijn preventief van aard. Zij bieden inzicht in de te verwachten risico’s zonder dat verliezen zijn opgetreden. Een voorbeeld van een preventieve KRI is het overzicht van de medewerkers die een bepaalde compliancetraining hebben gevolgd. Wanneer hieruit blijkt dat een laag percentage van de medewerkers deze training heeft bijgewoond, bestaat er een groter risico dat niet aan de compliance eisen wordt voldaan door de medewerkers. Een detectieve KRI is bijvoorbeeld het aantal klachten van klanten dat ontvangen is.

In de RMA journal (Risk Management Association journal) wordt gesproken over drie typen KRI’s ([Davi02]):

  • Loss indicatoren (ex post): historische gegevens van daadwerkelijk opgetreden verliezen die bruikbaar zijn om verwachte verliezen te bepalen.
  • Procesindicatoren (ex post / ex ante): indicatoren waarmee de kwaliteit van procesuitvoering voor alle risicotypen kan worden gemonitord. Het is een uitdaging om indicatoren te identificeren die een voorspellende waarde hebben, in plaats van indicatoren die informatie verschaffen over wat in het verleden is opgetreden.
  • Omgevingsindicatoren (ex ante): indicatoren die gericht zijn op het signaleren van veranderingen in de omgeving. Deze indicatoren hebben vaak een grote kwalitatieve component. Zij zijn erop gericht risico’s te identificeren voordat een verlies optreedt.

Deze KRI-typen zijn schematisch weergegeven in figuur 1.

C-2006-2-Spanjer-1

Figuur 1. KRI-typen [Davi02].

Een goed risicomanagementraamwerk combineert zowel ex post als ex ante KRI’s uit de verschillende categorieën om tijdige identificatie van optredende risico’s te realiseren.

KRI’s hebben betrekking op een specifieke risicocategorie van een bepaalde bedrijfsactiviteit. De frequentie waarmee monitoring van de KRI’s plaats dient te vinden, is afhankelijk van de betreffende risico’s en de mate waarin de omgeving verandert. De BIS geeft aan dat monitoring van de KRI’s een integraal onderdeel van de activiteiten van de bank zou moeten zijn ([BIS03]).

In de praktijk wordt reeds veelvuldig gebruikgemaakt van andere indicatoren, KPI’s (key performance indicators) om de prestatie van een afdeling, proces en/of persoon te meten. In veel gevallen overlappen KPI’s en KRI’s elkaar. Slechte performance kan immers leiden tot een groter risico. KPI’s zijn echter gericht op het maximaliseren van het resultaat, terwijl KRI’s gericht zijn op het minimaliseren van de kans dat een risico zich voordoet en leidt tot een verlies.

Voorbeelden van KRI’s zijn:

  • aantal ATM-berovingen per 1000 ATM’s ter identificatie van het risico van diefstal;
  • aantal hackpogingen per jaar ter identificatie van het risico van ongeautoriseerde toegang tot systemen en data door derden;
  • ratio van verliezen ten opzichte van inkomsten/omzet per product ter identificatie van het risico van te lage marges;
  • openstaande audit findings met hoog restrisico;
  • aantal klanten uit landen met een verhoogd risicoprofiel ter identificatie van het risico van slechte kredietwaardigheid van klanten;
  • time-to-market van nieuwe producten ter identificatie van het risico van een niet-succesvolle introductie van nieuwe producten.

KRI library

In 2005 heeft de Risk Management Association, een non-profitorganisatie die het gebruik van goede risico principes binnen financial services wil vergroten, de resultaten van een KRI-onderzoek voor banken gepubliceerd ([KRIex]). Dit onderzoek had tot doel een KRI-raamwerk voor de bancaire sector op te stellen ([Davi03]). Het doel van dit raamwerk is om standaardisatie, volledigheid en consistentie in KRI’s te bereiken waardoor vergelijkbaarheid tussen organisaties kan worden gerealiseerd en de effectiviteit van KRI’s kan worden vergroot. Het onderzoek heeft de RMA samen met RiskBusiness, een consultant op het gebied van operational risk management, uitgevoerd en verschillende banken hebben eraan deelgenomen. Het heeft geleid tot een KRI-bibliotheek waarin meer dan 1800 indicatoren zijn opgenomen.

Het onderzoek is in twee stappen uitgevoerd. In eerste instantie is een risicomatrix opgesteld met drie assen; risicocategorie, business line en processen. Voor risicocategorie en business line vormde het Basel II Akkoord de basis (zie tabel 1).

C-2006-2-Spanjer-t1

Tabel 1. Basel II-risicocategorieën en business lines.

Door toevoeging van processen ontstond een 3D-matrix met ongeveer 10.000 punten waarop een specifiek risico kon bestaan. Vervolgens zijn al deze punten van een risicoweging voorzien. Dit wil zeggen dat voor elk van de punten is bepaald hoe groot het verwachte risico was. Hieruit bleek dat externe risico’s (met uitzondering van diefstal en fraude) in het algemeen een lagere weging hadden dan interne risico’s. De categorie met hoog risico was ‘execution, delivery, process management’, waarbinnen voornamelijk transactie- en datamanagement als risicovol worden beschouwd. Haperende technologie, slechte procedures en incorrecte data bleken vaak een bron van aanhoudende verliezen die relatief klein zijn, maar in een korte periode kunnen oplopen tot grote bedragen.

De tweede stap in het onderzoek was om voor alle punten met een hoog risico KRI’s te definiëren. Dit heeft geleid tot 1800 key risk indicators en lijsten van de top-20 KRI’s per gehanteerde productgroep.

Banken kunnen zich abonneren op de KRI library. Eenzelfde onderzoek, gestart in 2004, voert de RMA momenteel uit voor verzekeraars.

Key risk indicators binnen operationeel risicomanagement

Het begrip KRI wordt door het Basel Comité geïntroduceerd als onderdeel van operationeel risicomanagement. Conform het Basel II Akkoord definieert DNB operationeel risico als ([DNB05a]): ‘risico van verliezen als gevolg van tekortschietende of falende interne procedures, mensen of systemen of als gevolg van externe gebeurtenissen, daaronder mede begrepen juridische risico’s’.

In haar ‘sound practices for operational risk management ([BIS03]) schrijft het Comité onder andere voor dat banken een proces moeten implementeren om hun operationeel risicoprofiel en de mate waarin materiële verliezen kunnen optreden, te monitoren. Tevens schrijft het voor dat het senior management en de directie van een bank van deze informatie dient te worden voorzien zodat zij een pro-actieve houding ten opzichte van operationeel risicomanagement kunnen innemen. Figuur 2 bevat een raamwerk voor operationeel risicomanagement (afgeleid van ([ISMA03])).

Dit raamwerk is bedoeld om de activiteiten die benodigd zijn voor operationeel risicomanagement (ORM) te structureren. De strategie vormt de basis voor de overige componenten van ORM. In deze strategie dienen (top-down) de doelstellingen van ORM op basis van de risicohouding en risicotolerantie van een organisatie te worden beschreven. Als onderdeel van de strategie worden de doelen voor ORM en het beleid voor ORM vormgegeven. Dit beleid wordt verder vormgegeven binnen het ORM-proces.

C-2006-2-Spanjer-2

Figuur 2. Raamwerk voor operationeel risicomanagement.

De eindverantwoordelijkheid voor ORM ligt bij het (lijn)management. De verantwoordelijkheden voor ORM dienen te worden verankerd in een organisatiestructuur ([KPMG05a]). Binnen deze organisatiestructuur zullen verschillende organisatieonderdelen met elk hun eigen verantwoordelijkheden en eisen binnen het proces voor operationeel risicomanagement bestaan. Operationele risico’s kunnen zowel binnen de lijn als in ondersteunende functies optreden. Naast management hebben ook risk management en internal audit een belangrijke rol in ORM om de kwaliteit van ORM binnen de organisatie te borgen.

Het ORM-proces dient continu te worden uitgevoerd op verschillende niveaus binnen een organisatie. Dit proces is gestructureerd om op een effectieve wijze operationeel risicomanagement uit te voeren binnen een organisatie met als doel de bestaande operationele risico’s te beperken tot een acceptabel niveau. Dit acceptabele niveau is bepaald in de ORM strategie (vastgelegd in een risicohouding en risicotolerantie). De activiteiten binnen dit proces zijn:

  • Assessment. Deze activiteit bestaat uit de risico- en controlidentificatie. Het doel ervan is te bepalen welke risico’s bestaan binnen de organisatie en welke maatregelen getroffen zijn en getroffen zouden moeten worden om deze risico’s te mitigeren zodat aan het (operationeel) risicomanagementbeleid wordt voldaan.
  • Controlimplementatie. De controls die benodigd zijn om de bestaande risico’s te mitigeren dienen te zijn en te worden geïmplementeerd in de processen van de organisatie.
  • Meten en monitoring. Deze activiteiten bieden inzicht in de mate waarin de organisatie blootgesteld is aan risico’s, hoe goed de geïmplementeerde maatregelen werken en in hoeverre nieuwe risico’s ontstaan. Het gebruik van key risk indicators wordt gezien als een erg effectieve manier om deze monitoring in te richten. Een definitie hiervan is opgenomen in de volgende paragraaf. Naast het meten van KRI’s wordt het meten en opslaan van verliezen die optreden, gebruikt om:
    • het risicobewustzijn binnen een organisatie te vergroten;
    • een analyse van opgetreden verliezen en de achterliggende oorzaak mogelijk te maken;
    • het operationeel risico te kwantificeren.
  • Capital modelling and allocation. Deze activiteit bestaat uit het berekenen van regulatory en economic capital. De advanced measurement-benadering van Basel II biedt banken de mogelijkheid om eigen modellen hiervoor te ontwikkelen op basis van eigen loss data.
  • Rapportage. Rapportage is een belangrijk onderdeel binnen ORM. Vanwege de diversiteit van operationele risico’s en de scope van operationeel risico binnen een organisatie is het van belang dat informatie over ORM op de juiste wijze gegroepeerd wordt gerapporteerd aan het management, zodat de juiste keuzen kunnen worden gemaakt omtrent het eventueel benodigde bijsturen door het nemen van (additionele) maatregelen.

Met behulp van informatietechnologie kan ORM worden ondersteund. IT kan ORM faciliteren door automatisering van dataverzameling, -analyse, rapportage en berekening van het benodigde kapitaalbeslag (al dan niet op basis van zelf ontwikkelde modellen).

Eisen aan Key Risk Indicators

KRI’s hebben betrekking op specifieke risico’s en de hieraan gerelateerde maatregelen. Een belangrijke eis aan een KRI is derhalve dat deze het optreden van het specifieke risico signaleert.

KRI’s zijn bedoeld voor monitoring van het risicoprofiel. Om deze monitoring effectief te kunnen uitvoeren, is het van belang dat KRI’s aan het onderstaande voldoen:

  • Specifiek. De KRI dient betrekking te hebben op de werking van een specifieke control of de kans of de impact van een risico. Te generieke KRI’s helpen de organisatie niet om risico’s effectief te managen. De KRI moet consistent zijn met (potentieel) optredende verliezen. Hij moet gericht zijn op het signaleren van mogelijke verliezen. Een goede KRI signaleert operationele problemen en legt een relatie met potentieel financieel verlies. Er dient een correlatie te bestaan tussen KRI’s en daadwerkelijke gebeurtenissen. Het nadeel van de bedrijfs- of processpecifieke eigenschappen van een KRI is dat KRI’s daardoor lastig te aggregeren zijn.
  • Key. Om een overvloed van data te voorkomen, die zijn doel voorbijschiet, dienen de KRI’s betrekking te hebben op de key risico’s. De mate waarin een risico key is, is afhankelijk van het risicobeleid van de organisatie.
  • Meetbaar. De KRI moet gebaseerd zijn op objectieve data die de werking van de maatregel meten en het mogelijk maken om deze over meerdere perioden te vergelijken. Deze maatstaf dient algemeen toepasbaar en eenduidig te zijn. De hieraan ten grondslag liggende brondata dient periodiek te worden gereviewd op integriteit. Per KRI dient het duidelijk te zijn welke data eraan ten grondslag liggen.
  • Beschikbare data. Er dient voldoende accurate data beschikbaar te zijn over de KRI om monitoring mogelijk te maken. Tevens dient de monitoring georganiseerd te kunnen worden.
  • Tolerantielevels. KRI’s moeten tolerantiegrenzen hebben. Wanneer de KRI buiten deze grenzen treedt, dient actie te worden ondernomen om het verhoogde risico te mitigeren. In figuur 3 zijn twee momenten opgetreden waarop de KRI (aantal klachten van klanten) zich buiten de tolerantiegrenzen bevond.
  • Actiegericht. Wanneer de KRI buiten de acceptabele toleranties valt, dienen het eraan gerelateerde risico en de controleomgeving te worden onderzocht. Tevens dient een actieplan/procedure te worden opgesteld om het risico te mitigeren tot binnen de acceptabele toleranties.
  • Toegewezen aan verantwoordelijke. De verantwoordelijkheid voor monitoring van de KRI en het mitigeren van de gerelateerde risico’s dient duidelijk te zijn.
  • Tijdgebonden. KRI-data dienen periodiek te worden gegenereerd op basis van actuele data om effectieve monitoring van het risicoprofiel mogelijk te maken. Deze databronnen dienen accurate en tijdige datavastlegging en -analyse te faciliteren.

C-2006-2-Spanjer-3

Figuur 3. Voorbeeld tolerantiegrenzen voor het aantal klachten van klanten.

Bovenstaande eisen aan KRI’s zijn bepaald op basis van de eisen die door banken in de praktijk aan KRI’s worden gesteld en door gebruik te maken van de op dit gebied beschikbare literatuur.

Naast de eisen waaraan goede KRI’s voldoen, bestaan er succesfactoren voor een effectief KRI-programma. Deze zijn in tabel 2 opgenomen ([Davi02]).

C-2006-2-Spanjer-t2

Tabel 2. Succesfactoren KRI-programma.

Key risk indicators in de praktijk

Het vervolg van dit artikel gaat in op de wijze waarop KRI’s in de praktijk kunnen worden ingezet en worden toegepast.

Identificatie van key risk indicators

Om KRI’s voor een proces op te kunnen stellen, is het van belang het proces en de hierin bestaande risico’s goed te kennen. Conform de Business Process Analysis (BPA)-methodiek van KPMG, start de identificatie van KRI’s met het identificeren van de processtappen binnen een proces en de operationele risico’s die hiermee samenhangen. Door de getroffen maatregelen in kaart te brengen kan per risico worden aangegeven hoe groot het restrisico is. In de praktijk worden vaak alleen voor hoge risico’s en voor restrisico’s KRI’s geïdentificeerd. Wanneer deze basis voor KRI-identificatie bepaald is, kunnen de daadwerkelijke KRI’s worden geïdentificeerd. Voor elk van de hoge risico’s dient vervolgens te worden bepaald of gegevens die reeds binnen het proces worden verzameld, hiervoor geschikt zijn. Indien dit niet het geval is, dienen nieuwe monitoringmechanismen te worden overwogen. Voor elk van deze potentiële KRI’s dient de effectiviteit te worden bepaald door te controleren in hoeverre elk van deze KRI’s voldoet aan de eisen die eerder in dit artikel zijn gesteld.

De informatie die binnen een organisatie beschikbaar is over de verliezen die zich hebben voorgedaan en de oorzaken hiervan, vormen belangrijke input ter identificatie van KRI’s. Wanneer bijvoorbeeld verliezen optreden door het foutief afhandelen van transacties en het aantal verliezen hoger was in de zomerperiode wanneer er gebruik wordt gemaakt van uitzendkrachten, kan het aantal uitzendkrachten dat werkt op de betreffende afdeling een KRI zijn voor het risico dat transacties onjuist worden afgehandeld.

Een methode om te bepalen welke KRI het meest effectief is om het optreden van een risico te voorspellen, is opgenomen in kader 2. Deze methode is tijdrovend. Wanneer er voldoende kennis bestaat over het proces en de hierin bestaande risico’s, is het invullen van een designmatrix wellicht niet nodig. Het invullen van een BPA-matrix die kan worden gehanteerd voor het in kaart brengen van risico’s binnen processen, is dan mogelijk zonder gebruik te maken van de designmatrix (zie tabel 3). Zoals reeds aangegeven, hoeven KRI’s alleen te worden ingevuld voor de risico’s die de organisatie als onacceptabel bestempelt (op basis van de kans en de schade).

Kader 2. Bepaling effectiviteit van KRI’s.

In het RMA journal van mei 2005 ([Imma04]) wordt de designmatrix template aangereikt ter bepaling van de geschiktheid en effectiviteit van potentiële KRI’s. Met behulp van deze matrix kan worden bepaald in hoeverre de potentiële KRI ‘specifiek’ genoeg is. Een voorbeeld van deze matrix is opgenomen in figuur 4. In de linkerkolom worden alle potentiële oorzaken van het risico opgenomen. Deze worden voorzien van een weging die weergeeft hoe groot de kans is dat als gevolg van deze oorzaak het risico optreedt. Vervolgens wordt voor elk van de potentiële KRI’s bepaald in hoeverre zij een relatie hebben met de oorzaken (in de linkerkolom).

C-2006-2-Spanjer-4

Figuur 4. Designmatrix ([Imma04]).

Vervolgens dient voor de potentiële KRI’s te worden bepaald in hoeverre deze voldoen aan de overige eisen. Wanneer KRI’s wel aan deze eisen voldoen maar geen 9 scoren in de designmatrix, dient te worden achterhaald of de KRI moet worden aangepast om beter bij het risico te passen. Door bijvoorbeeld de klanttevredenheidsindex te meten van klanten die contact hebben gezocht met het callcenter, in plaats van de totale klanttevredenheidsindex, wordt de KRI specifieker en beter bruikbaar ter identificatie van het risico dat het klantcontact niet op een adequate manier plaatsvindt.

Wanneer potentiële KRI’s hoog scoren op de designmatrix maar beperkt voldoen aan de overige KRI-criteria, dient te worden bepaald welke actie moet worden ondernomen om de KRI te verbeteren, bijvoorbeeld door meer frequent informatie over de KRI te verzamelen. Indien het niet mogelijk is de KRI te verbeteren, kan hij niet als KRI worden gebruikt.

C-2006-2-Spanjer-t3

Tabel 3. Business Process Analysis-matrix inclusief KRI’s.

Voor de KRI’s dient tevens te worden bepaald op welke wijze en door wie ze worden gemonitord en op welke wijze en aan wie ze worden gerapporteerd, en wie verantwoordelijk is voor het nemen van actie wanneer de KRI boven de tolerantielimiet is.

Ook wanneer de monitoring van KRI’s geautomatiseerd plaatsvindt, is een verantwoordelijke nodig voor de follow-up wanneer onacceptabele risico’s bestaan.

Gebruik van key risk indicators

Operationeel risico is een nieuwe risicocategorie ten opzichte van het Basel I Akkoord. De kwantificering van operationeel risico en het gebruik van KRI’s is als gevolg hiervan relatief nieuw in de regelgeving. Hierdoor is het niet verwonderlijk dat operationeel risicomanagement sterk in ontwikkeling is. Frameworks om operationeel risicomanagement te structureren zijn in de praktijk door banken geïmplementeerd. Uit een recent onderzoek op het gebied van risicomanagement ([Frer06]) dat is uitgevoerd onder leden van het Controllers Instituut, is gebleken dat 61 procent van de organisaties uit de financiële sector die hebben deelgenomen, een formeel risicomanagementbeleid kent. Een dergelijk beleid wordt vaak op groepsniveau geformuleerd; monitoring en identificatie van risico’s is in het algemeen als lijnverantwoordelijkheid belegd.

Binnen de bancaire wereld zijn met de komst van Basel II de ontwikkelingen op het gebied van ORM in een stroomversnelling geraakt. De sound practices ([BIS03]) waarin het gebruik van KRI’s wordt aanbevolen, zijn door De Nederlandsche Bank onderschreven en overgenomen en worden of zijn reeds door de banken in Nederland geïmplementeerd.

De uitdaging waar organisaties momenteel voor staan is de inbedding en effectuering van het beleid en framework in de organisatie. Het adequaat rapporteren en opvolging geven aan geïdentificeerde risico’s door middel van KRI’s is nog in volle ontwikkeling, waardoor de robuustheid van een effectief framework zich vaak nog moet bewijzen. De identificatie van KRI’s heeft bij verschillende organisaties reeds plaatsgevonden. De grote bancaire instellingen lopen hierbij voorop. Het inbedden van KRI’s in de processen, waarna monitoring op basis van KRI’s mogelijk wordt, is één van de volgende stappen in de verdere uitrol van ORM in de bancaire sector.

Uitwerking van key risk indicators

Ter afsluiting van dit artikel wordt de wijze waarop KRI’s kunnen worden gebruikt voor het signaleren van risico’s, toegelicht aan de hand van een voorbeelduitwerking van een hypothekenproces. Behalve op processpecifieke risico’s en maatregelen gaat dit artikel in op IT general controls betreffende continuïteit en security.

De auteurs hebben gekozen voor dit proces, omdat het binnen veel bancaire organisaties voorkomt. Het in dit artikel gehanteerde proces voor particuliere hypotheekverstrekking is weergegeven in figuur 5.

C-2006-2-Spanjer-5

Figuur 5. Voorbeeldproces: particuliere hypotheekverstrekking.

Het proces start met een aanvraag voor een hypotheekofferte door een klant. Deze aanvraag wordt door de bank geregistreerd. Wanneer de klant de relevante stukken (zoals paspoort, werkgeversverklaring en taxatierapport) reeds bij zich heeft, worden deze overgelegd. Deze kunnen echter ook in een later stadium worden ontvangen.

Op basis van de ontvangen gegevens van de klant wordt de aanvraag beoordeeld. In deze beoordeling bepaalt de bank in hoeverre de klant voldoet aan de voorwaarden voor verstrekking van een hypotheek van de door de klant gewenste omvang. Wanneer deze beoordeling positief uitpakt, stelt de bank een (voorwaardelijke) offerte op.

Indien de klant akkoord gaat met de offerte en deze accepteert, dient hij alle voor de hypotheekverstrekking benodigde stukken te overhandigen. De bank registreert en beoordeelt deze stukken op authenticiteit. Tevens beoordeelt de bank in hoeverre de stukken overeenkomen met de uitgangspunten waarvan bij het opstellen van de offerte is uitgegaan (bijvoorbeeld hoogte hypotheek en inkomen van de klant). Nadat beide partijen akkoord zijn gegaan met de offerte, vindt het notarisverkeer plaats, waarbij de klant daadwerkelijk het eigendom over het huis verkrijgt. Deze activiteiten spelen zich grotendeels buiten het blikveld van de bank af. Zij controleert in hoeverre deze activiteiten zijn uitgevoerd. Als laatste vindt de financiële afhandeling tussen onder andere de klant, de notaris en de hypotheekverstrekker (bank) plaats.

Voor het proces is vervolgens een BPA-matrix gedeeltelijk ingevuld (in tabel 4, conform tabel 3). Vanwege de focus van dit artikel op KRI’s is ervoor gekozen om hierin alleen de risico’s, maatregelen en KRI’s op te nemen. Voor elke processtap is bepaald welke (operationele) risico’s spelen en welke maatregelen binnen een bancaire organisatie worden getroffen om deze risico’s te mitigeren. In tabel 4 zijn de hoge (key) operationele risico’s en mogelijke maatregelen weergegeven. Risico’s die wel bestaan binnen het proces, maar die geen grote kans op optreden en/of grote schade bij optreden hebben, zijn voor dit voorbeeld niet verder uitgewerkt, omdat voor deze risico’s geen monitoring op basis van KRI’s zal plaatsvinden. Voor alle risico’s zijn KRI’s geïdentificeerd die voldoen aan de eisen die in het eerste deel van dit artikel zijn weergegeven.

In de tabel zijn niet alleen processpecifieke risico’s en maatregelen opgenomen, omdat voor het effectief functioneren van (applicatieve) maatregelen, een adequate organisatie en juist functionerende IT general controls van belang zijn. Vanwege het operationele risico dat gepaard gaat met informatiebeveiliging en continuïteit, zijn risico’s op deze gebieden uitgewerkt. De uitwerking van KRI’s voor deze risico’s dient ter illustratie van de mogelijkheid om KRI’s in te zetten voor het tijdig identificeren van IT-risico’s. Andere IT general controls, zoals een effectief change-managementproces, zijn immers tevens van toepassing op dit proces/voorbeeld.

C-2006-2-Spanjer-t4a

Tabel 4. Hoge operationele risico’s en maatregelen voor particuliere hypotheekverstrekking. [Klik hier voor grotere afbeelding]

C-2006-2-Spanjer-t4b

Tabel 4 (vervolg). [Klik hier voor grotere afbeelding]

Effectiviteit van IT key risk indicators

In tabel 4 zijn voor enkele IT-risico’s KRI’s opgesteld. Deze KRI’s dienen de risico’s op effectieve wijze te monitoren. De eisen die gelden voor KRI’s voor operationele risico’s zijn evenzo van toepassing op de KRI’s voor IT-risico’s.

In deze paragraaf worden – ter illustratie – de KRI’s van het inherente risico ‘Externen verschaffen zichzelf ongeautoriseerde toegang tot de systemen’ toegelicht aan de hand van de eisen die worden gesteld aan KRI’s voor operationele risico’s. De KRI’s die bij dit IT-risico zijn gedefinieerd, zijn als volgt:

  • aantal firewallwijzigingen (per periode);
  • aantal geïdentificeerde aanvallen (per periode);
  • aantal IT-beveiligingsonderzoeken (per periode).
KRI 1: aantal firewallwijzigingen

Om verschillende redenen kan het nodig zijn om aanpassingen door te voeren in de ruleset die het verkeer regelt van een firewall. Wijzigingen in de ruleset kunnen echter leiden tot het ontstaan van een beveiligingsrisico, doordat netwerkverkeer dat niet noodzakelijk is, wordt toegelaten tot achterliggende systemen. Veel wijzigingen in een bepaalde periode vergroten de kans op het ontstaan van dit risico.

Indien de firewall meerdere applicaties beschermt, dient de KRI alleen betrekking te hebben op wijzigingen van de rules die het verkeer reguleert van en naar de applicatie die het hypotheekverstrekkingsproces ondersteunt. Aanvullend zou kunnen worden bepaald dat alleen wijzigingen die resulteren in het toestaan van inkomend (‘inbound’) verkeer, door middel van de KRI worden gemonitord, omdat dit in het algemeen een groter beveiligingsrisico vormt dan het toestaan van uitgaand (‘outbound’) verkeer. Het op deze wijze toepassen van de KRI komt tegemoet aan de eis specifiek te zijn.

De meetbaarheid van de KRI is sterk afhankelijk van een goede registratie van wijzigingen in de firewall (rules). Indien iedere wijziging verloopt via een change-managementprocedure en hiervan een juiste registratie plaatsvindt, is het eenvoudig de wijzigingen per periode inzichtelijk te maken. Vanzelfsprekend dient deze change-managementinformatie beschikbaar te worden gesteld aan degene die verantwoordelijk is voor monitoring van deze KRI.

Het bepalen van een geschikt tolerantielevel voor deze KRI om daarmee een verhoogd risico aan te duiden, kan minder eenvoudig zijn. In beginsel dient als onderdeel van het change-managementproces bij iedere aanpassing van een firewall rule te worden beoordeeld in hoeverre een beveiligingsrisico ontstaat. Daarnaast dient te worden bepaald wat wordt verstaan onder een ongewoon aantal wijzigingen. Om dit te kunnen bepalen, kan gebruik worden gemaakt van ervaringscijfers (van het aantal wijzigingen in een bepaalde periode) en de ervaring van de beheerders van de systemen. Wanneer vinden zij een aantal changes ongewoon en gaat het aantal ten koste van de overzichtelijkheid en (wellicht) de juistheid van de wijzigingen? Bij een ongewoon aantal wijzigingen in een bepaalde periode kan de KRI aanleiding zijn om nader te onderzoeken wat de reden is van de vele wijzigingen.

KRI 2: aantal geïdentificeerde aanvallen

Om aanvallen te kunnen monitoren zal het firewallsysteem functionaliteit moeten hebben om verdacht verkeer te herkennen. Netwerkverkeer van en naar de hypotheekapplicatie dat afwijkt van het gebruikelijke verkeer (mogelijke aanvallen) dient geregistreerd te worden om meetbaarheid van de KRI mogelijk te maken. Zodra het aantal geregistreerde aanvallen boven een bepaalde tolerantiegrens komt dient actie te worden ondernomen om de herkomst van de aanvallen te bepalen en deze aanvallen nader te onderzoeken. Bij moedwillige aanvallen is snelle actie gewenst en voor het afslaan van deze aanvallen is een ‘intrusion prevention systeem’ vaak een goede oplossing die tevens monitoring van aanvallen mogelijk maakt. Overschrijding van een tolerantiegrens van de KRI dient dan aanleiding te zijn om te onderzoeken of aanvullende maatregelen nodig zijn.

KRI 3: aantal IT-beveiligingsonderzoeken

Het optreden van beveiligingsincidenten met een grote impact en het overschrijden van tolerantiegrenzen van de eerste twee KRI’s zijn redenen om een beveiligingsonderzoek in te stellen. De mate waarin KRI 1 en 2 specifiek zijn, is bepalend voor de mate waarin KRI 3 specifiek is. Een sterke toename van het aantal beveiligingsonderzoeken is reden om verder te onderzoeken of alle getroffen maatregelen om het risico van ongeautoriseerde toegang tot de hypotheekapplicatie te mitigeren voldoende effectief zijn. Het kan echter ook zijn dat verschillende ingestelde beveiligingsonderzoeken tot niets leiden en dat er vooral sprake is van loos alarm. In dat geval is mogelijk herdefiniëring of nadere specificatie nodig van de KRI’s die aanleiding hebben gegeven tot instelling van het onderzoek.

Conclusie

Dit artikel is ingegaan op de wijze waarop key risk indicators kunnen worden ingezet om in een vroeg stadium te signaleren wanneer operationele risico’s zich voordoen en zo de mogelijkheid te creëren deze te mitigeren voordat het risico zich heeft gemanifesteerd. In dit artikel hebben de auteurs willen aantonen dat KRI’s die voortkomen uit de hoek van het operationeel risicomanagement, ook goed toepasbaar zijn op IT controls. De auteurs hebben laten zien dat het gebruik van KRI’s voor IT controls een verdere professionalisering van risicomanagement op dit gebied kan bewerkstelligen. Vanwege de relatieve onbekendheid van KRI’s geeft dit artikel handvatten voor de identificatie en het gebruik van KRI’s.

Literatuur

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

[BIS05] Bank of International Settlements, Basel 2 Accord, November 2005.

[Chor04] Dimitris N. Chorafas, Operational risk control with Basel 2, basic principles and capital requirements, Elsevier Finance, 2004.

[Davi02] Jonathan Davies and Michael Haubenstock, Building effective indicators to monitor operational risk, RMA journal, May 2002.

[Davi03] Jonathan Davies and Charles Taylor, Getting traction with KRIs: laying the groundwork, RMA journal, November 2003.

[DNB05a] De Nederlandsche Bank, Concept-Toezichthouderregels Operationeel Risico, Basisindicatorbenadering en Standaardbenadering (Consultatiedocument (Implementatie Bazel II)), November 2005.

[DNB05b] De Nederlandsche Bank, Basel II: Governance of model development, validation and use, oktober 2005.

[Dresd03] Dresdner, Kleinwort and Wasserstein, Key risk indicators, December 2003.

[Fert06] Leon Fertman, Risk and compliance management framework for a financial services organisation: Key elements, Banking & Finance, 13 April 2006.

[Frer06] D.H.J. Freriksen, D.M. Swagerman en L. Paape, Risicomanagement: de praktijk in Nederland, MCA Tijdschrift voor organisaties in control, april 2006.

[Imma04] Aravind Immaneni, Chris Mastro and Michael Haubenstock, A structured approach to building predictive key risk indicators, Operational Risk, May 2004.

[ISMA03] ISMA Center, Operational risk, Regulation, Analysis and Management, Prentice Hall, 2003.

[Karoq] Chris Karoq, Operational Risk: Ignore It at Your Peril, Ernst & Young.

[KPMG] KPMG Financial Services, Basel briefings.

[KPMG05a] KPMG, Basel 2: A closer look, managing operational risk, 2005.

[KPMG05b] KPMG, Actualiteiten regelgeving Financiële Sector 2005: Het moment van de waarheid, Toezicht, verslaggeving en invloed overige regelgeving.

[KRI04a] KRI Newsletter Part II #4, May 2004.

[KRI04b] KRI Newsletter Part II #5, June 2004.

[KRIex] www.kriex.org

[Moul04] Bruce Moulton, Basel II: Operational risk and information security, http://enterprisesecurity.symantec.com/industry/finance, January 27, 2004.

[Rowe04] David Rowe, A difference in kind, Risk analysis, June 2004.

[Tayl04] Charles Taylor, Key risk indicators move up a gear, Global risk regulator, November 2004.

[Till03] Alice van Tillaart, Controlling operational risk, concepts and practices, 2003, NIBESVV, Amsterdam.

[Vlam06] Drs. M.J. Vlaminckx, Risicomanagement maakt prestatiemeting veelomvattend, MCA Tijdschrift voor organisaties in control, februari 2006.

[Zamp06] Helene Zampetakis, Security issues require holistic approach, Financial review, 20 March 2006.

Een inleiding tot integrated audit

In dit artikel worden de hoofdlijnen weergegeven voor de aanpak van een (IT-) audit in het kader van de controle van de jaarrekening en de interne beheersing.

Inleiding

In onze maatschappij is een trend gaande, waarbij organisaties naar een hoger niveau van beheersing streven. Waar voorheen meer in onderling vertrouwen werd samengewerkt, wordt thans op diverse terreinen gevraagd een aantoonbare beheersing te realiseren (figuur 1).

C-2006-2-Kornelisse-1

Figuur 1. Niveaus van volwassenheid beheersing.

De omslag naar aantoonbare beheersing vormt een wijziging in onze cultuur en uit zich in wet- en regelgeving, bijvoorbeeld inzake Sarbanes-Oxley (SOX) en Tabaksblat.

Als consequentie van aantoonbaarheid van beheersing is het van belang monitoring in te richten, opdat belanghebbenden adequaat kunnen worden geïnformeerd. Deze monitoring kan worden vormgegeven door verschillende partijen: bijvoorbeeld via interne controle binnen de operationele omgeving, via de interne auditor en via de externe auditor.

Met de zich ontwikkelende regelgeving is het van belang dat de organisatie zelf, dus het collectief van operationele en stafafdelingen, zorg draagt voor aantoonbaarheid van de interne beheersing. Indien bijvoorbeeld voor een organisatie de SOX-wetgeving van toepassing is, is het vereist dat de externe auditor de kwaliteit van de interne beheersing controleert, zowel wat betreft de evaluatie hiervan door het management van de organisatie zelf als de effectiviteit van de interne beheersingsmaatregelen. Hiermee krijgt de externe auditor dus twee taken, namelijk het beoordelen van zowel de financiële verslaglegging als de interne beheersing. Tezamen met het feit dat verschillende auditdisciplines meer met elkaar samenwerken om de financiële verslaglegging en de interne beheersing te beoordelen, wordt hiermee het begrip integrated audit invulling gegeven.

De integrated audit kan worden gefaseerd in het selecteren van objecten, het verrichten van waarnemingen en het evalueren van bevindingen.

Selecteren van objecten

Een organisatie zal op basis van de van toepassing zijnde wet- en regelgeving en het operationele risicomanagement moeten vaststellen welke monitoringinformatie nodig is, ofwel welke informatie het management nodig heeft om een redelijke mate van zekerheid te krijgen over de mate waarin het in control is. Dit betreft bijvoorbeeld monitoringinformatie over de organisatie in het algemeen, specifieke financiële informatie, maar ook informatie over specifieke IT-services.

Bij het beoordelen van de interne beheersing door de externe accountant dient te worden vastgesteld of door de organisatie een passende scoping van zogenaamde key risks en key controls heeft plaatsgevonden, voor de te beheersen bedrijfsprocessen, en of deze key controls effectief zijn geïmplementeerd en gemonitord door de organisatie zelf.

De scoping betreft zowel de maatregelen aangaande de interne beheersing van de organisatie in het algemeen als de operationele beheersingsmaatregelen per te beheersen bedrijfsproces. Bij de bedrijfsprocessen is het van belang vast te stellen welke de relevante applicaties zijn, op basis van de toegepaste IT-dependent manual controls en de automated controls ([PCAO04]).

Voor de scoping van de maatregelen aangaande de organisatie in het algemeen wordt veelal het COSO-model ([COSO06]) als basis genomen. Dit model richt zich op ‘Control Environment’, ‘Risk Assessment, ‘Control Activities’, ‘Information and Communication’, en ‘Monitoring’.

De scoping van de interne beheersing van bedrijfsprocessen in een IT-ondersteunde omgeving kan plaatsvinden aan de hand van het model uit figuur 2.

C-2006-2-Kornelisse-2

Figuur 2. Objecten van een IT-applicatie.

De objecten van een IT-applicatie betreffen bijvoorbeeld maatregelen in de applicatie, databasemanagementsystemen, servers, identitysystemen (zoals Active Directory), werkplek-pc’s, het netwerk en monitoring- en beheersystemen.

Hierbij verloopt in de praktijk het selecteren van de relevante IT-applicaties en ICT-componenten als volgt. Op basis van de jaarcijfers en de uitingen betreffende de jaarcijfers worden de voornaamste entiteiten van de organisatie geïnventariseerd. Voor elk van deze entiteiten worden vervolgens de voornaamste bedrijfsprocessen bepaald, waarbij per proces de zogenaamde key controls worden vastgesteld. Een ‘control’ is ‘key’, als voor de betrouwbare procesgang wordt gesteund op deze key control.

Key controls komen tot uiting in verschillende vormen: de zogenaamde ‘manual controls’ (handmatige maatregelen), ‘IT-dependent manual controls’ (IT-afhankelijke maatregelen, bijvoorbeeld rapportages uit applicaties), en ‘automated controls’ (geprogrammeerde maatregelen binnen applicaties). De accountant selecteert samen met de algemene IT-auditor de key controls.

In meer complexe en omvangrijke omgevingen selecteert de technical IT-auditor samen met de algemene IT-auditor de controls in de ICT-omgeving. Hiertoe wordt voor ‘IT-dependent manual controls’ en ‘automated controls’ vastgesteld op welke IT-applicatie(onderdelen) door de key controls wordt gesteund. Deze IT-applicatie(onderdelen) vallen vervolgens binnen de scope van de audit. Daarna worden voor de relevante IT-applicatie(onderdelen) de applicatiespecifieke IT (zoals applicatie- en databaseservers) en generieke ICT (zoals netwerk en werkplek) vastgesteld, evenals de IT-beheerorganisaties die hiervoor zorg dragen ([Korn05]).

C-2006-2-Kornelisse-3

Figuur 3. Focus van audit.

Verrichten van waarnemingen

De auditor dient vervolgens waarnemingen te verrichten betreffende de als relevant onderkende objecten, met de hiertoe vereiste diepgang en met de vereiste zekerheid. Betreffende de organisatiebrede maatregelen dienen de opzet en het bestaan van maatregelen te worden gecontroleerd, voor de operationele maatregelen dient deze controle te worden uitgebreid met de werking van maatregelen.

Het is bij het uitvoeren van waarnemingen van belang dat de audit zelf eveneens aantoonbaar adequaat wordt uitgevoerd. Hiertoe is het van belang een gedocumenteerd werkprogramma te hanteren, waarin zijn gedocumenteerd:

  • objecten;
  • gehanteerde normen;
  • wijze van waarnemen (bijvoorbeeld interview, documentatie, systeemconfiguratie);
  • frequentie van waarnemen;
  • evaluatie per norm.

Het onderzoeken van de opzet van maatregelen vindt veelal plaats door het bestuderen van documentatie en het interviewen van betrokken functionarissen. Bij het onderzoeken van het bestaan en de werking van maatregelen worden vooral registraties ingezien en worden systeeminstellingen van ICT-componenten opgevraagd.

Indien applicaties of delen van applicaties door een ICT-serviceorganisatie worden beheerd, kan het voorkomen dat niet de auditor van de cliënt, maar de auditor van de ICT-serviceorganisatie waarnemingen verricht. In dat geval kan door de auditor van de ICT-serviceorganisatie een zogenaamde SAS 70-rapportage worden opgesteld ([AICP05]).

Bij het doen van waarnemingen omtrent ICT-componenten kan de auditor ook steunen op monitoringvoorzieningen die de organisatie zelf heeft ingericht, maar de auditor dient veelal ook eigen waarnemingen te verrichten. Hiertoe kan bijvoorbeeld tijdelijk opvraagprogrammatuur (query tools) op computers van de organisatie worden geïnstalleerd, waarmee systeeminstellingen worden opgevraagd.

Evalueren van bevindingen

Tijdens de audit worden vele waarnemingen gedaan, die afzonderlijk en in samenhang dienen te worden geëvalueerd. Er zijn immers afwijkingen van normen die uiteindelijk geen wezenlijke impact hebben, en afwijkingen die dat wel hebben.

Het is in het bijzonder van belang de afwijkingen van normen in kaart te brengen, die kunnen leiden tot een materiële afwijking van de jaarrekening, waardoor deze geen getrouw beeld van de werkelijkheid meer geeft.

Vooral voor afwijkingen in de ICT-omgeving is het van belang bij elke afwijking de impact op een gedefinieerde key control te bepalen. Op basis van de afweging van deze impact dient de accountant zich een samenvattend oordeel aangaande de interne beheersing te vormen.

Samenvatting

Het streven naar hogere niveaus van beheersing resulteert in de noodzaak meer informatie ter beschikking te hebben betreffende de mate waarin financiële verslaglegging en interne beheersing voldoende ‘in control’ zijn.

Ter voorkoming van kosteninefficiënties is het hierbij noodzakelijk op basis van relevante wet- en regelgeving en operationeel risicomanagement een juiste scope op te stellen van de objecten waarvoor monitoringinformatie benodigd is.

De waarnemingen op basis waarvan met een bepaalde mate van zekerheid een uitspraak wordt gedaan over het werkelijke niveau van beheersing, worden vervolgens door verschillende auditdisciplines en teams uitgevoerd.

De geconstateerde afwijkingen dienen alle te worden geëvalueerd en te worden gerelateerd aan de relevante bedrijfsprocessen.

Literatuur

[AICP05] American Institute of Certified Public Accountants, AICPA Audit and Accounting Guide: Service Organizations: Applying SAS70, as Amended, 2005.

[COSO06] The Committee of Sponsoring Organizations of the Treadway Commission, Internal Control – Integrated Framework, www.coso.org.

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

[PCAOB04] Public Company Accounting Oversight Board, Auditing Standard 2 – An Audit of Internal Control Over Financial Reporting Performed in Conjunction with An Audit of Financial Statements, www.pcaob.org.

Tool-based monitoring en auditing van ERP-systemen, van hebbeding naar noodzaak

Het intern monitoren en auditen van interne controles met behulp van tools is niet echt iets nieuws. Echter, door de introductie van de Sarbanes-Oxley Act in de Verenigde Staten en de code-Tabaksblat in Nederland is een groei te verwachten inzake het gebruik van geautomatiseerde tools om efficiënter en effectiever te voldoen aan wet- en regelgevingen. Dit heeft vooral te maken met de vaak nog niet geïdentificeerde overlap aan controleframeworks van de diverse regelgevingen en met de omschakeling van handmatige controls naar IT application controls. Dit laatste heeft te maken met de efficiëntiewinsten die te behalen zijn door aantoonbaar ‘in control’ te zijn.

Deze twee ontwikkelingen vormen de basis voor de noodzaak om tooling te implementeren voor ondersteuning van zowel het monitoren als het auditproces. Aan de hand van een overzicht van typen tools met kenmerken en voorbeelden wordt een praktisch maturitymodel gepresenteerd om verder inzicht te geven in de implementatie van tooling in het kader van monitoring en auditing van ERP-systemen.

Inleiding

Recente wetgevingen, zoals Sarbanes-Oxley (SOX) en de code-Tabaksblat, hebben in de afgelopen jaren een negatieve ‘hype’ veroorzaakt, doordat na het bekend worden van de nieuwe wet- en regelgeving veel bedrijven niet precies wisten wat ze ermee aan moesten. Inmiddels hebben veel bedrijven die bijvoorbeeld SOX-plichtig zijn de wet en daarmee het controleframework geïmplementeerd ([Brou03]). Ze zijn ‘compliant’, maar tegen welke prijs?

In dit artikel wordt de (toekomstige) noodzaak beschreven van het gebruik van tools voor een efficiënte en effectieve ‘in control’ monitoring en auditing. Hierbij wordt niet alleen ingegaan op tools ten behoeve van het faciliteren van het proces om te komen tot een ‘in control’-statement ([Ooms04] en [Beuc05]), maar ook op tools die op ERP-procesniveau kunnen bijdragen aan dit ‘in control’-statement. Op de eerste plaats wordt ingegaan op een tweetal ontwikkelingen die de noodzaak tot het gebruik van tools onderschrijven. Deze ontwikkelingen worden toegelicht aan de hand van een internationaal uitgevoerd onderzoek door KPMG in 2005.

Daarna wordt het begrip tooling uitgelegd aan de hand van een overzichtelijke structuur van monitoring en auditing tools. Deze tools hebben als primair doel om de stelsels van controles (de controleframeworks) te beschrijven en te monitoren. In de praktijk zien wij dat organisaties een drietal volwassenheidsniveaus doorlopen bij de ‘implementatie’ van een controleraamwerk en de toepassing daarbij van geautomatiseerde tools. Het woord ‘implementatie’ is hier opzettelijk tussen aanhalingstekens geschreven omdat het succes van het efficiënt en effectief voldoen aan ‘in control’-wetgevingen niet alleen bereikt kan worden door de keuze van een goede tool, maar ook door een praktische implementatie binnen de organisatie met een adequaat organisation change proces.

Ontwikkeling 1. De ‘control transformation’ naar preventieve applicatiecontroles

De negatieve hype van SOX van 2002-2004 is onder andere te wijten aan de hoge interne, maar vooral ook externe kosten die het ‘compliance’ worden met zich meebracht. Een survey van KPMG LLP ([KPMG05]) onder SOX-compliant organisaties geeft één van de oorzaken van deze hoge kosten aan. Uit het onderzoek blijkt namelijk dat het merendeel van de organisaties steunt op manuele, detectieve controles in het kader van hun SOX compliance statement (zie figuur 1). Bij het testen van manuele controles, in het kader van de managementassessment of selfassessment voor SOX, moet er bijvoorbeeld een selectie van meerdere testgevallen (bij dagelijkse controles minimaal dertig) worden genomen. Naast de interne organisatie moet ook de externe auditor deze uitgebreide tests uitvoeren. Dat verklaart voor een groot deel de hoge interne en externe inspanning en dus ook kosten.

C-2006-2-Brouwers-01

Figuur 1. Veelvuldig gebruik van handmatige controles (KPMG LLP [KPMG05]).

Eén van de oplossingen is het gebruik van preventieve controles. Preventieve maatregelen hebben een sterkere invloed op de beheersing dan detectieve maatregelen omdat bij detectieve maatregelen altijd correctieve acties moeten worden genomen die bij een preventieve maatregel niet nodig zijn. Daarnaast hoeven preventieve applicatiecontroles nog slechts éénmaal getest te worden om het bestaan en de werking van de controles aan te tonen en daarmee te voldoen aan de richtlijn van de externe auditor, mits er sprake is van adequate algemene computercontroles. Als laatste heeft een applicatiecontrole een belangrijk voordeel: veel applicatiecontroles kunnen geautomatiseerd getest worden. Hierdoor kan een test van controlemaatregelen nog sneller en efficiënter worden gedaan en kan de frequentie van een dergelijke test zelfs worden opgevoerd. Het is belangrijk nog op te merken dat een automatische controle vaak nog een manuele component bevat, want automatische controles produceren uitzonderingen waaraan nog opvolging moet worden gegeven. Zowel de wens om de efficiency van de bedrijfsprocessen te verbeteren als de behoefte van organisaties aan het reduceren van kosten en energie om te voldoen aan alle wet- en regelgeving, leidt ertoe dat er een verplaatsing ontstaat van manueel detectieve controles naar automatische preventieve controles (zie figuur 2). Deze omzetting wordt ook wel de ‘control transformation’ genoemd en zal de komende jaren een grote vlucht nemen.

C-2006-2-Brouwers-02

Figuur 2. ‘Control transformation’ (KPMG LLP [KPMG05]).

Ontwikkeling 2. De consolidatie van ‘in control’-koninkrijkjes

De niet SOX-plichtige organisaties hebben aan de zijlijn toegekeken hoe de wél SOX-plichtigen hebben gestreden om aan de wet te voldoen. Beide categorieën organisaties zijn echter beïnvloed door de SOX-wetgeving want er is een algemene ‘in control’-bewustwording teweeggebracht. Deze heeft met name ermee te maken dat organisaties hebben gemerkt dat ze pas echt ‘in control’ zijn als ze het ook kunnen vaststellen en dat toch soms een handtekening onder een ‘letter of representation’ niet voldoende bleek.

In principe is er niet veel nieuws onder de zon, want naast de SOX-wet zijn er vele andere regels waar deze en andere organisaties wel aan moeten voldoen, zoals ‘FDA: Foods and Drugs Administration’-regels, Basel II, RAROC, ISO-richtlijnen, veiligheidsvoorschriften en de code-Tabaksblat. Al deze regelgeving heeft een niet te onderschatten element dat door de SOX-bewustwording alleen maar belangrijker is geworden. De organisatie moet namelijk zelf aantonen dat de interne beheersing op voldoende niveau is. Er is een verandering van de gedachtegang opgetreden bij de ‘in control’-stakeholders van organisaties, namelijk een verandering van ‘trust me’, ‘show me’ naar ‘prove me’ ([Brou03]). Een organisatie moet volgens al deze wetten en regelgevingen met voldoende bewijsmateriaal aantonen dat zij ‘in control’ is, en de organisatorische maatregelen heeft getroffen die ervoor zorgen dat risico’s voor zowel de operatie als de betrouwbaarheid van financiële cijfers beheerst worden.

Een onderdeel van het bewijzen van de interne beheersing is het testen van controlemaatregelen. Van alle procedures, controles, systeemcontroles en dergelijke die risico’s mitigeren, moet worden aangetoond (door te testen en bewijsmateriaal te vergaren) dat ze effectief zijn. Daar komt nog bij dat dit moet worden bewezen niet alleen voor de SOX-wetgeving, maar voor alle andere beheersingsraamwerken, zoals die hierboven reeds zijn benoemd. Het resultaat is in een aantal gevallen dat er aparte activiteiten worden uitgevoerd (interne reviews, externe audits) voor gedeeltelijk overlappende frameworks. Het hergebruiken van controls voor andere controleraamwerken kan een enorme efficiencyslag opleveren bij diverse en verschillende ‘in control’-statements. In figuur 3 is dit schematisch weergegeven. Dit heeft als voordeel dat een interne of externe auditor in eerste instantie verwezen kan worden naar de overall controlsbucket, die vanuit het eigen specifieke gezichtspunt bekeken kan worden.

C-2006-2-Brouwers-03

Figuur 3. Overlap van ‘in control’-statements.

De randvoorwaarden bij de implementatie van beide ontwikkelingen

Risk management en compliance kosten momenteel veel tijd, energie, geld en frustratie, waardoor een efficiënte aanpak noodzakelijk is. Voor organisaties die deze beide ontwikkelingen willen implementeren, zijn er twee elementaire randvoorwaarden. De eerste is de onvermijdelijke inzet van tools op verschillende onderdelen. Tools vereenvoudigen zowel het consolideren van wet- en regelgevingvereisten als het voldoen aan de verschillende documentatie-eisen voortvloeiend uit deze wet- en regelgeving. Vaak worden SOX-projecten bijvoorbeeld nog uitgevoerd met Excel. Voor het eerste jaar en voor een beperkte organisatieomvang werkt dit nog prima, maar deze manier blijkt vaak niet duurzaam voor de toekomst. Belangrijke voordelen van het gebruik van tools op het gebied van internal control monitoring zijn onder andere:

  • het efficiënt en overzichtelijk documenteren en rapporteren van testwerkzaamheden (de traditionele SOX-tools);
  • het overzichtelijk hergebruiken van de controls voor verschillende frameworks;
  • het efficiënt automatisch testen van IT-controles zowel detectief als preventief van aard;
  • het automatisch genereren van test evidence voor het testen van de effectieve werking van controls;
  • het in geval van organisaties met meerdere units automatisch vaststellen bij welke organisatieonderdelen internecontrolerisico’s worden gelopen en welke derhalve meer aandacht dienen te krijgen.

De tweede randvoorwaarde is het op een juiste wijze inbedden van de controle-uitvoering binnen de bedrijfsprocessen. Momenteel worden de wet- en regelgevingverklaringen namelijk nog vaak projectmatig uitgevoerd. Om de efficiëntieslag te kunnen maken is het noodzakelijk dat het testen van de controleframeworks wordt ingebed binnen de bedrijfsprocessen. Praktisch betekent dit dat de verantwoordelijkheid voor de uitvoering van de ‘in control’-tests niet uitsluitend bij internal audit, business controller of zelfs een externe organisatie wordt belegd, maar in eerste instantie bij de procesverantwoordelijke (process owner) en bedrijfsmanager. Om dit te realiseren dient een niet te onderschatten organisational change proces te worden opgetuigd.

Buiten het feit dat organisational change belangrijk is, zal dit artikel vooral ingaan op de typen tools en een praktisch maturitymodel bij de implementatie in organisaties.

Typen tools; een praktisch overzicht

In de vorige paragraaf is gesproken over het gebruik van tools voor de ondersteuning van testwerkzaamheden van controls, maar niet alleen op het laagste niveau van de organisatie waar de dagelijkse controles worden uitgevoerd, kunnen tools ondersteunen en daarmee de effectiviteit en efficiëntie verbeteren. Een risk of control framework moet gedragen worden door de gehele organisatie en heeft daarom een weerslag op verschillende niveaus van een organisatie. Vaak wordt dit hele stelsel van frameworks daarom Enterprise Risk Management genoemd. Tools sluiten zich daarbij aan en de tools die beschikbaar zijn hebben dan ook ieder een focus op één of meer van deze organisatieniveaus (zie figuur 4). In diverse publicaties van onderzoeksorganisaties zijn evaluaties van tools beschreven ([Gart04] en [Forr05]).

C-2006-2-Brouwers-04

Figuur 4. De typen tools binnen de organisatieniveaus.

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

Strategic risk management (niveau 1)

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

C-2006-2-Brouwers-05

Figuur 5. De strategische risico-overzichten.

Tactical risk management (niveau 2)

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

C-2006-2-Brouwers-06

Figuur 6. Voorbeeld procesflow.

Hiervoor kan gebruik worden gemaakt van het CARP-model. De afkorting CARP wordt gevormd door de eerste letters van de typen maatregelen:

Customising controls

Controls gerelateerd aan de configuratie en stamdata van een informatiesysteem. Voorbeelden hiervan zijn de three-way-match instellingen, verplichte velden, toleranties, automatische boekingen, etc. van een ERP-pakket. Deze controles bieden een goede preventieve werking mits zij op de juiste manier zijn ingericht. De instellingen zijn opgeslagen in het systeem en dus kan het bestaan (het aan of uit staan van een dergelijke instelling) worden vastgesteld.

Authorisation controls

Dit zijn maatregelen die gerelateerd zijn aan de logische toegangsbeveiliging van een informatiesysteem. Bijvoorbeeld het beperken van het aantal personen aan wie het is toegestaan om een kritische financiële transactie (bijvoorbeeld betalingsrun) uit te voeren, maar ook het beperken van het aantal personen dat een functiescheidingsconflict veroorzaakt (bijvoorbeeld het wijzigen van bankgegevens van crediteuren en het uitvoeren van de betalingsrun). Gegevens gerelateerd aan de inrichting van de logische toegangsbeveiliging van een applicatie zijn verankerd in de autorisatiestructuur (profielen) van een applicatie. Deze gegevens kunnen worden gebruikt voor het maken van analyses ter beoordeling van de inrichting van logische toegangsbeveiliging.

Reporting controls

Als onderdeel van de beheersing van een proces door middel van controlemaatregelen passen gebruikers controle- en uitzonderingsrapportages toe die door het systeem worden gegenereerd. Voorbeelden hiervan zijn het periodiek bekijken van veranderingen aan bankgegevens van leveranciers, het tijdig opvolgen van de openstaande facturen werkvoorraad of facturen verstuurd maar nog niet verwerkt in het grootboek. De gebruiker interpreteert het rapport en kan indien nodig de uitzonderingen rapporteren en opvolgen.

Procedural of manuele controls

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

Operational risk management (niveau 3 en 4)

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

C-2006-2-Brouwers-07

Figuur 7. Voorbeeld control-statusrapportage.

Om te kunnen beoordelen of een proces beheerst wordt, dient te worden gekeken naar de werking van de gedefinieerde controlemaatregelen, ervan uitgaande dat de opgezette controlemaatregelen (opzet en bestaan) in een organisatie afdoende zijn om de risico’s af te dekken. Het vaststellen en documenteren van de werking van controlemaatregelen kan met geautomatiseerde fact-finding worden gestaafd. Met inzet van tooling kan door middel van dataminingtechnieken[Met datamining wordt bedoeld het vergaren van informatie uit een informatiebron (meestal een database) en deze informatie gebruiken voor het creëren van meta-informatie (informatie over informatie).] deze fact-finding of bewijsvoering worden gegenereerd.

Het gebruik van tools kan dus ondersteuning bieden aan een breed scala van controleactiviteiten. Tools op het strategische en tactische niveau zijn niet altijd noodzakelijk. Echter, hoe lager het niveau des te dichter zit men op de operationele activiteiten waarbij het uitvoeren van controlemaatregelen werkelijk veel tijd in beslag kan nemen. In zo’n situatie kunnen de kosten flink oplopen en om dat te beperken kan tooling een uitkomst bieden.

Daarnaast kunnen gegevens over de effectieve werking van individuele controles (op het operationele niveau) geaggregeerd worden en daarmee een indicatie geven van de totale effectieve beheersing van een proces (het tactische niveau).

ERP-monitoring in de praktijk

Controlemaatregelen zijn geïntegreerd in de bedrijfsprocessen. In eerste instantie zullen dit procedurele controles zijn waarbij veel gebruik wordt gemaakt van rapportages die uit het systeem komen en wat minder configuratiecontroles. Een belangrijk deel van de controlemaatregelen maakt dan ook gebruik van systeemrapportages, zoals openstaande facturen, openstaande inkooporders of overzichten waarop alle geleverde goederen vermeld zijn waaraan geen inkooporder ten grondslag ligt.

Voor veel van dergelijke rapportages maakt diegene die de controle uitvoert gebruik van impliciete normen. Zo zal een inkoper bij het bekijken van een rapport met daarop alle openstaande inkooporders geneigd zijn alleen naar die inkooporders te kijken waarvan de verwachte leverdatum al meer dan één of twee weken is verstreken. Door deze impliciete normen te verwerken in een tool dat ondersteuning biedt aan fact-finding, is het mogelijk een filter te creëren en op het operationele niveau te ondersteunen bij het rapporteren en doen opvolgen van uitzonderingen. De gebruiker hoeft daarvoor dan ook niet meer in een systeem te duiken en heeft door middel van een ‘in control’-dashboard direct zicht op welke controlemaatregelen die onder zijn verantwoordelijkheden vallen, opvolging vereisen. Het aggregeren van deze aantallen naar subprocessen en hoofdprocessen tot afdelingen levert ook het management op de hogere niveaus in de organisatie direct informatie over de beheersing van een proces.

De mate van beheersing van een proces wordt meetbaar door deze fact-finding gegevens in historisch perspectief te plaatsen en het verloop daarvan in acht te nemen. Door gebruik te maken van tools op het operationele niveau met daarbij ondersteuning van fact-finding is het mogelijk het aantal uitzonderingen terug te dringen en stabiel te houden.

Kader 1. Voorbeeld van geautomatiseerd monitoren.

Een ERP-pakket maakt gebruik van een logische voorraad bij het uitvoeren van een Materials Requirements Planning. De logische voorraad bestaat uit de fysieke voorraad inclusief de eventueel nog te ontvangen goederen (op basis van openstaande inkooporders). Het mag duidelijk zijn dat wanneer de verwachte leverdatum van een inkooporder ruimschoots is overschreden, het minder verstandig is te verwachten dat deze nog tijdig geleverd gaat worden. De met de bewuste inkooporder bestelde goederen zouden dus niet bij de logische voorraad moeten worden opgeteld, anders zou de MRP-run voor die materialen geen nieuwe aanvraag-tot-bestellingen genereren, hetgeen resulteert in het niet tijdig voorradig zijn van materialen voor de productie, met alle gevolgen van dien. Een manier om dit op te lossen is het tijdig beoordelen van openstaande inkooporders en daarbij letten op de verwachte leverdatum. Als een organisatie gebruikmaakt van een geautomatiseerd tool dat de verantwoordelijke personen pusht (door e-mails o.i.d.) opvolging te geven aan die inkooporders waarvan de verwachte leverdatum een norm heeft overschreden, kan het leveringsproces op een strenge manier worden bewaakt en zullen de frequentie waarin het voorkomt dat een inkooporder lang openstaat en de duur van openstaan van een inkooporder verminderen.

Voor veel meer processen in een organisatie is het mogelijk voorbeelden te geven zoals bovenstaand, waarin een tool duidelijk toegevoegde waarde kan leveren op het gebied van procesbeheersing. Tevens geeft dit voorbeeld ook direct de overlap tussen de eerdergenoemde beheersingsraamwerken en het belang van een organisatie voor effectieve procesbeheersing weer. In het kader van SOX zal een organisatie op basis van openstaande inkooporders haar verplichtingen op een juiste manier moeten registreren en bewaken en waar nodig daarvoor voorzieningen moeten treffen. Vanuit het organisatieperspectief is het niet wenselijk dat de productie stilligt door een tekort aan een bepaald materiaal.

Maturityniveaus in de organisatie voor tools op operationeel niveau

Het geautomatiseerd testen, monitoren en opvolgen van uitzonderingen is een hele aanpassing voor een organisatie en is ook niet iets wat in een korte tijd geïmplementeerd kan worden. Een organisatie moet erop voorbereid zijn. Een basiscontroleraamwerk moet bestaan en de medewerkers moeten ‘aware’ zijn van wat controle is en waartoe zij dient. Een organisatie die de basis niet op orde heeft kan niet de overstap maken naar geautomatiseerde controles en dus geautomatiseerd testen. Er is een groeipad dat doorlopen zou kunnen worden (zie figuur 8). Het groeipad bestaat uit de volgende maturityniveaus:

Periodieke centrale reporting

De organisatie heeft een controleraamwerk en weet welke controleactiviteiten moeten worden uitgevoerd. Deze worden periodiek uitgevoerd door een centraal team, vaak nog met behulp van Excel. Periodiek onderzoek naar doorbrekingen van functiescheidingen en het draaien en opvolgen van rapportages zijn daar voorbeelden van.

Voorwaarde om deze fase te starten is de beschikbaarheid van een control framework met geïdentificeerde key processen, key risico’s en key controls.

Monitoringintegratie in processen

De volgende stap is het overschakelen van deze periodieke centrale controleactiviteiten naar de bedrijfsprocessen zelf. De controleactiviteiten en -momenten worden verankerd in de dagelijkse processen en maken deel uit van de werkinstructies. Medewerkers voeren de controles uit en volgen de uitzonderingen van de rapportages op. In principe is de organisatie ‘in control’.

Voorwaarde om deze fase te starten is de beschikbaarheid van beschreven process flows, inclusief de key controls en een centraal rapportagetool om de verantwoording van de controleactiviteiten vast te leggen en te rapporteren.

Continuous monitoring

De controleactiviteiten die in de processen verankerd zijn, worden naar een hoger niveau getild en de uitvoering hiervan wordt vastgelegd in een operational risk management tool waardoor het management in staat is direct inzage te krijgen in het reilen en zeilen van de organisatie. De tweede stap hierin is het automatisch voeden van deze applicatie door middel van fact-finding. De status van de controles wordt al direct in de applicatie geladen en de gebruiker geeft daar opvolging aan. In wezen is er een continue automatische controle.

Voorwaarde om deze fase te starten is de beschikbaarheid van een continuous monitoring tool en geïdentificeerde key application controls voor de monitoring.

C-2006-2-Brouwers-08

Figuur 8. Monitoring maturitymodel.

Op dit moment zitten sommige organisaties op niveau 1, waarbij een deel al vergevorderd is in de overstap naar niveau 2. Zoals al eerder aangehaald, moet een organisatie groeien in haar volwassenheid alvorens het volgende niveau bereikt kan worden.

Impact op de externe audit

In welke fase een organisatie ook zit, het zelf ‘in control’ zijn kunnen aantonen op basis van fact-finding uit de systemen is een erg krachtig intern controlemiddel, dat zeker invloed heeft op de externe audit.

In 2002 al is geschreven over de invloed van ‘in control dashboards’ op de audit ([Brou02]). Hierin werd ook al geconcludeerd dat de implementatie van een ‘in control dashboard’ de sterkste vorm van interne controle is, waarbij de organisatie de werking van haar interne controle daadwerkelijk kan aantonen aan het externe auditteam tijdens de interim-controle.

Na de komst van SOX en Tabaksblat is wel het awareness voor interne controle in een stroomversnelling gekomen, maar is er door de forse inspanning gericht op SOX vooral focus geweest op de handmatige controls zoals reeds beschreven. De twee beschreven ontwikkelingen en dus de implementatie van tools zullen echter de komende jaren een grote vlucht nemen binnen organisaties. De vraag wordt dan automatisch: zullen de auditfirma’s gebruikmaken van door de organisatie geïmplementeerde tools of eigen tools gaan inzetten voor hun controle ([Brou06])? Het is in ieder geval ondenkbaar dat de auditfirma’s om de systemen heen controleren indien de organisatie een dergelijk internecontrolesysteem heeft opgetuigd.

Conclusie

De beschreven ontwikkelingen en mogelijke besparingen hebben aangetoond dat tool-based monitoring en auditing van ERP-systemen echt geen hebbeding meer is. Indien organisaties de efficiëntieslag willen winnen en ‘in control’-statement duurzaam willen implementeren, kan niet meer om tools heen worden gegaan. De keuze welke niveaus de tools dienen af te dekken in de organisaties is wel nog van belang. De meeste toegevoegde waarde en kostenbesparingen kunnen worden behaald met tools op het operationele niveau, maar deze vergen naast een uitdagende technische en functionele implementatie ook nog een organisatorische.

Literatuur

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

[Brou02] Drs. P.P.M.G.G. Brouwers RE RA, Ontwikkelingen met betrekking tot ‘in control dashboards’ en de invloed op auditing, Compact 2002/4.

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

[Brou05] Drs. P.P.M.G.G. Brouwers RE RA, Tool-based monitoring van ERP-systemen, Excerpta NOREA/VERA-congres 23 en 24 november 2005.

[Brou06] Drs. P.P.M.G.G. Brouwers RE RA, De toekomst is nu, De Accountant, april 2005.

[Forr05] The Forrester Wave™: Sarbanes-Oxley Compliance Software, Q1 2005, 7 april 2005.

[Gart04] MarketScope: Compliance Management Software, 10 december 2004.

[KPMG05] Sarbanes-Oxley 404 Poll Study, KPMG LLP, maart 2005.

[Liss05] Drs. ing. A.T. J. Lissone, Sarbanes-Oxley Section 404, Reducing the cost of compliance with tools, 2005.

[Ooms04] Mw. drs. M. Ooms-Pieper RE en mw. ir. R.M.L. Degens, SOX404 business and tool alignment, Compact 2004/4.

Integrated audit: ‘SAS 70: het verlengstuk van internal control over financial reporting’

Het uitbesteden van een proces ontslaat het management niet van zijn eindverantwoordelijkheid. Maar hoe krijg je zekerheid over processen die je hebt uitbesteed en welke invloed heeft dit op het internal control statement en de integrated audit? Met het van kracht worden van de Sarbanes-Oxley Act hebben we opnieuw kennisgemaakt met een oude bekende. Maar wat staat ons te wachten?

Inleiding

Het van kracht worden van de Sarbanes-Oxley Act, met name sectie 404, vereist van het management van aan de Amerikaanse beurs genoteerde organisaties dat het een statement afgeeft over de interne beheersing rondom de financiële verslaglegging. De getrouwheid van deze verklaring moet worden getoetst door de externe accountant. In grote multinationale organisaties is het vaak zo dat één of meer processen zijn uitbesteed. De vraag is dan hoe zekerheid kan worden verkregen over de beheersing van processen die wel van invloed zijn op het financiële verslagleggingsproces maar die buiten het zichtveld van zowel het management als de externe accountant plaatsvinden.

Specifiek voor die gevallen waarin delen van interne beheersing zijn uitbesteed, is in de Verenigde Staten een uitvoeringsstandaard gedefinieerd, Statement on Auditing Standards Nr 70 of kortweg SAS 70. Hoewel deze standaard en het hieruit voortvloeiende rapport in principe bedoeld zijn als een auditor-to-auditor rapport, heeft het rapport sinds de publicatie van PCAOB II een breder bereik gekregen. Ook het management mag voor zijn ‘assessment on internal control over financial reporting’ gebruikmaken van een SAS 70-verklaring.

In dit artikel staan de gebruikers van het SAS 70-statement centraal, de gebruikersorganisatie en haar accountant. In het bijzonder zal dit artikel ingaan op de voorbereiding en uitvoering van een SAS 70-onderzoek, het gebruik van een SAS 70-statement zelf en de kosten die met een SAS 70-onderzoek gepaard gaan. Aangezien het gebruik van een SAS 70-statement in het kader van jaarrekeningcontrole niet nieuw is, wordt SAS 70 in dit artikel vooral belicht vanuit de ‘integrated audit’. De ‘integrated audit’ bestaat uit een gecombineerde controle op de jaarrekening en het internal control statement van de organisatie. Voor de invloed van Sarbanes-Oxley Act en SAS 70 op leveranciers van het SAS 70-statement verwijzen we naar [Bigg06].

Voorbereiding en uitvoering

Het uitbesteden van een proces ontslaat het management niet van de plicht en de verantwoordelijkheid om zijn interne huishouding op orde te hebben ([PCAO04]). Het is dan ook de verantwoordelijkheid van de gebruikersorganisatie om haar dienstverlener aan te sturen en te controleren. Een verzoek om een SAS 70-onderzoek wordt vaak geïnitieerd door de gebruikersorganisatie(s) en/of haar accountant. In de praktijk zien we vaak dat er wordt gebeld naar de serviceorganisatie met het verzoek: ‘Doe mij even een SAS 70’.

De externe accountant van de gebruikersorganisatie, ofwel de user auditor, is van oudsher de ontvangende partij. In principe heeft de user auditor slechts een beperkte rol in de voorbereiding en uitvoering van het SAS 70-onderzoek. Echter, in de praktijk zien en stimuleren de auteurs dat de user auditor juist wel wordt betrokken in de voorbereiding van het onderzoek, voornamelijk bij het bepalen van de scope en planning van het SAS 70-onderzoek.

De serviceorganisatie is leverancier van het SAS 70-statement en is opdrachtgever van de service auditor. De serviceorganisatie is verantwoordelijk voor het opstellen van een dienstbeschrijving, het definiëren van beheerdoelstellingen (control objectives) en het beschrijven van internecontrolemaatregelen (control descriptions) die zij heeft getroffen voor het realiseren van de beheerdoelstellingen. In de praktijk zien we dat de beheerdoelstellingen zoals deze terugkomen in het SAS 70-statement vaak in overleg tussen de serviceorganisatie en de userorganisatie worden bepaald en afhankelijk zijn van contractafspraken en dienstverlening.

Daarnaast heeft de serviceorganisatie in de uitvoering van het onderzoek nog een aantal verantwoordelijkheden, maar hiervoor verwijzen de auteurs graag naar een uitgave van het American Institute of Certified Professional Auditors ([AICP05]).

De service auditor geeft een verklaring over de mate waarin de beheerdoelstellingen worden gerealiseerd. De service auditor is ervoor verantwoordelijk auditwerkzaamheden uit te voeren rondom de getrouwheid van de dienstbeschrijving, de opzet van het raamwerk van interne controle en het bestaan en eventueel de werking van de beschreven controlemaatregelen.

Generieke versus specifieke SAS 70-rapporten

Het verzoek ‘Doe mij even een SAS 70’ heeft vaak meer voeten in de aarde dan op het eerste gezicht wellicht lijkt. In de praktijk zien de auteurs dat elke gebruikersorganisatie deze vraag op een andere manier beantwoord wil zien.

In het ene uiterste neemt men genoegen met een generiek SAS 70-rapport, waarin het grootste deel van de inhoud wordt bepaald door de serviceorganisatie. In een generiek SAS 70-rapport beschrijft de serviceorganisatie de standaarddienstverlening, beheerorganisatie en controlemaatregelen. Het generieke rapport is een afgeleide van de standaarddienstverlening zoals deze is vastgelegd in haar dienstenportefeuille.

In het andere uiterste is een specifiek rapport gewenst. Aangezien het management van de userorganisatie het SAS 70-rapport wil gebruiken als verlengde van zijn eigen internal control framework, ontvangt het graag een rapport dat direct aansluit op dat framework.

Een overzicht van de belangrijkste verschillen tussen een generiek SAS 70-rapport en een specifiek SAS 70-rapport is opgenomen in tabel 1.

C-2006-2-Biggelaar-t1

Tabel 1. Verschillen tussen een generiek en een specifiek SAS 70-rapport. [Klik hier voor grotere afbeelding]

Een generiek rapport biedt in veel situaties voldoende zekerheid voor zowel de gebruikersorganisatie als haar auditor en is ook goedkoper dan een specifiek rapport. In principe gaat het hierbij dan om een standaard en ondersteunend proces, bijvoorbeeld pensioenadministratie of salarisverwerking. Naarmate de mate van standaardisatie afneemt en de complexiteit toeneemt neemt ook de behoefte aan een specifiek statement toe.

Het SAS 70-rapport

Het resultaat van een onderzoek uitgevoerd volgens de SAS 70-standaard is een SAS 70-rapport. Het rapport kent in principe vier secties:

  • de accountantsverklaring (sectie I);
  • de beschrijving van controls door de serviceorganisatie (sectie II);
  • informatie van de service auditor (sectie III);
  • overige informatie van de serviceorganisatie (sectie IV).

Het is echter mogelijk dat u SAS 70-rapporten tegenkomt met minder secties.

Sectie III is alleen verplicht indien het SAS 70-rapport een uitspraak doet over een bepaalde werkingsperiode, ofwel een SAS 70 type II. PCAOB-standaard 2 vereist dat de internecontrolemaatregelen op werking wordt getoetst ([PCAO04]), vandaar dat u in het kader van de integrated audit in principe altijd een sectie III zult tegenkomen.

Een sectie IV wordt slechts dan gebruikt indien de serviceorganisatie informatie aan de gebruikersorganisatie wil verstrekken die buiten de scope van het onderzoek valt. Denk hierbij aan op stapel staande ontwikkelingen, of de wijze waarop de serviceorganisatie omgaat met bevindingen.

Hoewel u door de nummering van secties wellicht verwacht dat de secties ook in deze volgorde worden opgenomen in het SAS 70-statement, is er geen verplichte volgorde. In de praktijk zien we dan ook dat de verschillende secties nog wel eens in een andere volgorde worden gezet om de leesbaarheid van het rapport te vergroten.

Het moge duidelijk zijn dat het in ontvangst nemen en archiveren van een SAS 70-rapport niet voldoende is voor de integrated audit of voor het management assessment on internal control. Maar hoe ga je daar als user auditor of user management mee om? Het ligt voor de hand om vooraan te beginnen, de ervaring leert echter dat dit niet altijd de beste manier is.

Zoals eerder in dit artikel is vermeld, kan er sprake zijn van een generiek of een specifiek SAS 70-rapport. De wijze waarop een SAS 70-rapport moet worden gelezen door het management is hiervan afhankelijk en heeft ook veel te maken met het verwachtingsmanagement dat in de voorbereiding en uitvoering door de serviceorganisatie heeft plaatsgevonden.

Bij een generiek rapport dient het management zichzelf onder andere de volgende vragen te stellen:

  • Sluit de scope van het onderzoek aan op ons eigen internal control framework? Worden alle relevante processen en deelprocessen die wij hebben uitbesteed, door het SAS 70 geraakt? In de meeste gevallen is dat neergelegd in de beschrijving van controls door de serviceorganisatie (sectie II).
  • Welke control objectives hanteert de serviceorganisatie? Hoe passen deze control objectives op de binnen de organisatie gehanteerde control objectives? Control objectives zijn terug te vinden in sectie II en III. Om redundantie in het rapport te voorkomen, wordt er vaak voor gekozen om de control objectives alleen in sectie III te vermelden.
  • Heeft de service auditor een gekwalificeerde opinie op de voor de gebruikersorganisatie relevante control objectives (sectie I de accountantsverklaring)? En zo ja, wat betekent dit dan, wat is de omvang en heeft de geconstateerde tekortkoming betrekking op onze organisatie? Deze informatie is opgenomen in sectie III.

Bij een specifiek rapport is in principe alleen de laatste vraag nog relevant. De eerste twee zijn in principe al in de voorbereiding beantwoord. Vanzelfsprekend dient het management nog altijd wel kennis te nemen van het rapport en vast te stellen dat het rapport aansluit op wat was afgesproken in de scopingsletter.

SAS 70 voor de user auditor

Voor de user auditor dient het SAS 70-rapport twee doelen. In eerste instantie het traditionele doel: het verkrijgen van een redelijke mate van zekerheid over opzet bestaan en werking van controle maatregelen binnen de serviceorganisatie. Op deze controlemaatregelen wil de user auditor steunen bij het plannen van controlewerkzaamheden bij de gebruikersorganisatie en het bepalen van het controlerisico.

Voorts is het rapport een onderdeel van het toetsen van het management assertion op de interne beheersing rondom de financiële verslaglegging. Bijzonder hieraan is dat de uitvoering van testwerkzaamheden niet door het management zelf heeft plaatsgevonden maar door de service auditor.

In dit kader is het voor de user auditor niet alleen relevant om te verifiëren en evalueren of er in sectie I opmerkingen zijn opgenomen die potentieel tot een ‘material weakness’ leiden, maar ook hoe het management is omgegaan met het SAS 70-statement zelf. De vraag die hierbij bijvoorbeeld gesteld kan worden, is: ‘Heeft het management zelf het SAS 70-statement op een juiste manier beoordeeld en indien nodig corrigerende maatregelen getroffen?’

Voor het traditionele gebruik van een SAS 70-rapport door de user auditor zijn specifieke richtlijnen opgenomen in de SAS 70-standaard (zie [AICP05]). Bijvoorbeeld:

  • Een ongekwalificeerd oordeel in sectie I betekent niet dat de user auditor alleen op basis hiervan het controlerisico omlaag kan brengen. Ook ‘deficiencies’ op individuele controls kunnen invloed hebben op de planning en het controlerisico. Uiteindelijk zijn het werkende controls op basis waarvan de user auditor een lager controlerisico kan rechtvaardigen (zie onder meer ook [PCAO04]).
  • Melding van zogenaamde ‘user organisation control considerations’ moeten worden meegenomen in het plannen van de audit (zie hierna).
  • De werkingsperiode die wordt getest door de service auditor moet zoveel mogelijk aansluiten op de auditperiode van de user auditor. Een SAS 70 die slechts een deel van de auditperiode afdekt is minder waardevol.

Kort gezegd komt het erop neer dat de user auditor in het kader van de controle op de jaarrekening moet bepalen welke elementen van het SAS 70-rapport voor zijn controle van belang zijn en of het SAS 70-rapport op die elementen voldoende zekerheid biedt voor werking van controles.

De impact van een gekwalificeerde opinie

Indien de service auditor concludeert dat één of meer beheerdoelstellingen niet worden gehaald, leidt dit tot een gekwalificeerde opinie. De betreffende beheerdoelstelling wordt in dat geval expliciet uitgesloten in sectie I. Een gekwalificeerde opinie door de service auditor hoeft niet per definitie te leiden tot een ‘material weakness’ in het internal-controlraamwerk van de gebruikersorganisatie, noch hoeft dit te leiden tot een afkeurende verklaring bij de jaarrekening.

Een gekwalificeerde opinie is voor het raamwerk van interne controle in eerste instantie niets anders dan een geconstateerde tekortkoming, ook wel ‘deficiency’ genoemd. Aangezien het SAS 70-statement in principe een integraal onderdeel is van het internal-controlraamwerk, dient een ‘deficiency’ bij de serviceorganisatie in principe ook op eenzelfde manier te worden beoordeeld en geëvalueerd.

Het kan best zo zijn dat op grond van een kwalificatie de user auditor tot de conclusie komt dat er sprake is van een ‘material weakness’ in de interne beheersing over financiële verslaglegging. Dit betekent niet automatisch dat er ook een gekwalificeerde opinie bij de jaarrekening wordt gegeven. Door het bestaan van de ‘material weakness’ dient de user auditor bij het plannen van zijn controlewerkzaamheden meer gegevensgerichte werkzaamheden te plannen. Op basis van die werkzaamheden kan alsnog worden geconcludeerd dat de jaarrekening een getrouwe weergave is van de werkelijkheid.

De ‘user organisation control consideration’

Tijdens het doornemen van het SAS 70-rapport kan het zijn dat op enig moment een ‘user organisation control consideration’ wordt gegeven. Kort gezegd komt dit erop neer dat de serviceorganisatie er bij het inrichten van een dienst rekening mee heeft gehouden dat ook de gebruikersorganisatie bepaalde controls heeft ingericht. Een goed voorbeeld is het verwerken van personeelsmutaties door een salarisverwerker. De serviceorganisatie kan deze mutatie slechts tijdig verwerken indien de gebruikersorganisatie deze ook bijtijds doorgeeft. De serviceorganisatie zal om die reden aangeven dat zij van de gebruikersorganisatie verwacht controlemaatregelen te hebben ingericht die tijdig een signaal afgeven aan de serviceorganisatie.

Wat betekent een dergelijke ‘user organisation control consideration’ voor het management van de gebruikersorganisatie en de user auditor? Het management dient er zich van te vergewissen dat het dergelijke controlemaatregelen heeft geïmplementeerd, heeft gedocumenteerd en heeft getest in het kader van het ‘assessment on internal control over financial reporting’. De user auditor zal in zijn controle van het management assertion moeten verifiëren of het management de user control consideration zelf heeft gesignaleerd bij het doornemen van het rapport, een soortgelijke control heeft gedocumenteerd en getest, en vervolgens zal hij zelf nog een paar waarnemingen moeten doen om de werking van de control zelfstandig vast te stellen (zie ook [PCAO04]). Dit laatste is wederom van belang voor het management assertion in het kader van het SOX 404-statement en in de tweede plaats om op het moment dat deze test faalt de werkzaamheden in het kader van jaarrekeningcontrole hierop aan te passen.

Waarom kost een SAS 70-statement zoveel geld?

Deze vraag wordt ons in de praktijk vaak gesteld zowel door service providers die voor een generiek statement in de praktijk vaak de kosten dragen, als door de gebruikersorganisatie die voor specifieke SAS 70-rapporten de rekening moet betalen. De relatief hoge kosten zijn een gevolg van de benodigde inspanning om een SAS 70-rapport op te leveren. Hieronder wordt een aantal oorzaken toegelicht waardoor deze inspanning zo groot is:

Een SAS 70 type II-verklaring geeft een redelijke mate van zekerheid (reasonable assurance) over een minimale periode van zes maanden. Reasonable assurance betekent dat de auditor niet alleen kan afgaan op bijvoorbeeld interviews maar ook feitelijke waarnemingen moet doen in de vorm van inspections, observations, reperformance, etc. Bovendien betekent een type II met een werkingsperiode van minimaal zes maanden in de praktijk dat er minimaal tweemaal wordt getest gedurende de zes maanden.

In 2004 zijn de richtlijnen van de PCAOB op het gebied van dossiervorming verschenen (zogeheten PCAOB-richtlijn 3). Deze richtlijn is in beginsel van toepassing op integrated audit-activiteiten. Voorzover bekend hebben de meeste auditfirma’s die SAS 70-rapporten afgeven deze richtlijn ook van toepassing verklaard voor SAS 70-onderzoeken. De consequentie hiervan is een vergrote werklast om de dossiers in orde te maken. Zo moet bijvoorbeeld elk dossierstuk (werkpapieren, en ontvangen bewijsmateriaal) tweemaal worden beoordeeld: eenmaal door de auditor en eenmaal door een reviewer van gelijk of hoger ervaringsniveau. Voorts moet elk dossierstuk worden gedateerd en geparafeerd door auditor en reviewer.

Maar vergeet ook niet dat ook de service auditor, conform sectie 102 van de Sarbanes-Oxley Act, moet zijn ingeschreven bij de PCAOB (www.pcaobus.org/Registration/) wil de rapportage bruikbaar zijn voor SOX 404-werkzaamheden. Als gevolg hiervan moet de service auditor voldoen aan alle richtlijnen van de PCAOB. Een voorbeeld daarvan is dat de PCAOB vanuit Amerika het recht heeft om dossiers te reviewen bij de service auditors in Europa. Inmiddels zijn de eerste tickets door de PCAOB besteld om dossierreviews uit te voeren.

In de praktijk zien we veelal bij de eerste bespreking tussen de vier betrokken partijen dat de eisen van de user organisation en user auditor hoog zijn. Niet alleen worden er veel control objectives gedefinieerd, maar ook het aantal objecten in scope is groot. Daarnaast zien wij in de praktijk vaak specifieke eisen op het gebied van bijvoorbeeld de steekproeven, tussenrapportages, besprekingen, early warnings, mate van detail van sectie III, etc. Vanzelfsprekend heeft dit een grote invloed op de benodigde inspanning.

Er wordt steeds vaker gevraagd om zekerheid over een langere periode. Eind jaren negentig is het begonnen met de eerste TPM-verklaringen die met name gericht waren op opzet en bestaan. Dit werd gevolgd door SAS 70 type I-verklaringen. Met de SOX-wetgeving is het bijna vanzelfsprekend opgerekt naar type II-rapportages over een periode van zes maanden en inmiddels vragen de eerste user auditors SAS 70-statements over een periode van negen of twaalf maanden. We zien dit met name gebeuren bij userorganisaties die in hoge mate afhankelijk zijn van IT en/of bijvoorbeeld geen fysieke goederenstromen hebben (telco’s, banken). Hoewel een langere auditperiode niet automatisch betekent dat de selection size van de tests moet worden uitgebreid, dient deze wel beter gespreid te worden over de auditperiode. In de praktijk betekent dit al snel dat er drie of vier keer moet worden getest.

Wat nu als er geen SAS 70-statement is?

In de praktijk hebben we al een paar keer meegemaakt dat het ontbreken van een SAS 70-statement tot grappige maar ook frustrerende situaties kan leiden. Indien er geen SAS 70 beschikbaar is (bijvoorbeeld omdat serviceorganisatie en userorganisatie het niet eens worden over wie wat gaat betalen), betekent dit met een strikte interpretatie van de SOX 404-wetgeving dat het management van de userorganisatie zelf de key controls bij de service provider moet gaan testen. Vervolgens, maar natuurlijk niet gelijktijdig, moet de user auditor reperformancewerkzaamheden uitvoeren om vast te stellen of de testwerkzaamheden door het management goed zijn uitgevoerd. Hij staat dus ook weer op de stoep bij de service provider. Als service providers meerdere klanten hebben die SOX-plichtig zijn, leidt dit al snel tot ongewenste situaties die voor alle partijen maar beter kunnen worden voorkomen. Dit is overigens ook vaak de conclusie van serviceorganisaties en hun klanten na één jaar werken zonder SAS 70-statement.

Tot slot

Met het van kracht worden van de Sarbanes-Oxley Act is het begrip SAS 70 weer uit de kast gehaald en van zijn stofmantel ontdaan. Dit artikel is voornamelijk geschreven vanuit het perspectief van de gebruikers. Duidelijk moge zijn dat je er met het verzoek ‘Doe mij even een SAS 70’ niet bent.

Is het een hype? De toekomst zal het leren. Vandaag de dag zien we in ieder geval dat steeds meer organisaties assurance willen over een uitbesteed proces, ook niet (grote) beursgenoteerde organisaties. In enkele gevallen heeft het zelfs helemaal niets te maken met financiële verslaglegging of integrated audit. De vraag aangaande assurance komt dan vanuit een heel andere hoek, bijvoorbeeld FDA, OPTA of andere toezichthoudende instanties.

Is er nog meer over SAS 70 te schrijven? Ja, zeer zeker. Denk maar eens aan situaties waarin delen van één proces zijn uitbesteed aan meerdere service providers. Hoe sluit je al die rapporten op elkaar aan? Hoe ga je als serviceorganisatie om met grote veranderingen in aangeboden diensten? Bijvoorbeeld de implementatie van een nieuw systeem, transities, offshoring van activiteiten, of situaties waarin de standaardset van controls simpelweg nog niet is geïmplementeerd. Wellicht dat we in toekomstige artikelen nog op deze vragen terugkomen.

Literatuur

[AICP05] American Institute of Certified Public Accountants, AICPA Audit and Accounting Guide: Service Organizations: Applying SAS 70, as Amended, 2005.

[Bigg06] Drs. ing. S.R.M. van den Biggelaar RE, drs. S. Janssen RE en drs. G.J.L. Lamberiks, SAS 70 in een ICT-fabriek: Accessoire, fabrieksoptie of onderdeel van de standaard?, Compact 2006/1.

[PCAO04] Public Company Accounting Oversight Board, An Audit of Internal Control Over Financial Reporting Performed in Conjunction with An Audit of Financial Statements, 2004.

Integrated audit: een uitdaging voor de auditor?

Als gevolg van de inwerkingtreding van de Sarbanes-Oxley Act 404 (SOX 404) voor Nederlandse instellingen met een Amerikaanse beursnotering worden door de Public Company Accounting Oversight Board (PCAOB) eisen gesteld aan de werkzaamheden van de externe accountant. De externe accountant dient naast de controle van de jaarrekening tevens de verantwoording van het management te beoordelen en een eigen verklaring af te geven betreffende de effectiviteit van de ‘internal controls’ ten aanzien van de financiële verslaggeving. Grote vraag die wij ons als beroepsgroep moeten stellen is: ‘Hoe kan voorkomen worden dat de controlekosten de pan uitrijzen?’ en dus ‘Welke mogelijkheden zijn er om een efficiënte integrated controleaanpak neer te zetten bij onze klanten?’ Dit is ons inziens de uitdaging voor de komende periode. Een belangrijke voorwaarde hierbij is een intensieve samenwerking tussen de financiële accountant en de IT-auditor in een zo vroeg mogelijk stadium van de controle. Maar ook het uitwerken van een goede scoping op basis van een ‘risk based approach’ is hierbij van belang.

Inleiding

De uitdaging bij het uitvoeren van een integrated audit is het opzetten van een doordachte en efficiënte controleaanpak. Hierbij dienen aspecten zoals een deugdelijke grondslag en de hoogte van de controlekosten mede in ogenschouw te worden genomen. Het begrip integrated auditing wordt binnen de accountancy op verschillende wijzen geïnterpreteerd. In dit artikel zullen wij een nadere toelichting geven over onze definitie van integrated auditing. De eerste ervaringen van de implementatie van Auditing Standard No. 2 bij met name grote Amerikaanse ondernemingen waren niet positief, dat wil zeggen dat de controles uitgevoerd sinds de implementatie vaak niet zo effectief en efficiënt zijn uitgevoerd als bedoeld in de Auditing Standard. Dit heeft weer geleid tot hogere kosten. Het belang van het neerzetten van een effectieve en efficiënte controleaanpak integrated audit is derhalve evident en wordt in dit artikel verder uitgewerkt. Hierbij zal worden stilgestaan bij de verschillen en overeenkomsten met de reguliere jaarrekeningcontrole. Aanvullend wordt het belang van een meer geïntegreerde teamsamenstelling (financial en IT-auditor) voor het optimaliseren van de integrated audit nader toegelicht. Het artikel heeft als uitgangspunt ondernemingen waarbij een zekere mate van automatisering voor de bedrijfsvoering aanwezig is.

Inleiding integrated audit

Het begrip integrated audit

Integrated auditing is een begrip dat al enige tijd wordt gehanteerd in de praktijk wanneer verschillende auditdisciplines samenwerken of wanneer verschillende auditvormen worden gecombineerd. Denk bijvoorbeeld aan de samenwerking externe accountant met IT-auditor, of de samenwerking externe accountant met interne accountant, maar men kan ook denken aan de combinatie operational, financial en IT-audit. Door de Sarbanes-Oxley Act 404 heeft het begrip weer een betekenis extra gekregen. In deze paragraaf willen wij kort stilstaan bij het begrip integrated audit in het kader van die wet.

Artikel 404 van de Sarbanes-Oxley Act vraagt een onderzoek naar de ‘internal control over financial reporting’ door het management en de externe accountant. Sinds jaar en dag verricht de accountant onderzoek naar de financiële positie, de financiële resultaten en de kasstromen, resulterend in een periodieke verantwoording daarvan in de jaarrekening. De controle van interne beheersing kan niet los worden gezien van de controle van de jaarrekening. Op grond van de regelgeving naar aanleiding van de Sarbanes-Oxley Act dient dezelfde accountant daarom beide controles te verrichten. De combinatie van beide controles wordt de integrated audit genoemd.

Tabel 1 geeft uitgebreid het doel van de integrated audit weer.

C-2006-2-Beugelaar-t01

Tabel 1. Doel integrated audit.

Het doel van een integrated audit is te komen tot een conclusie geformuleerd door de accountant die is bedoeld om het vertrouwen van de beoogde gebruikers in bovenstaande uitkomsten te versterken ([NIVR05]).

De verantwoordelijkheden van de accountant zijn bij een integrated audit niet anders dan bij een reguliere jaarrekeningcontrole, met dien verstande dat bij de integrated audit drie conclusies geformuleerd dienen te worden in plaats van één. Figuur 1 geeft de drie conclusies (‘verklaringen’) schematisch weer ([Buur05]).

C-2006-2-Beugelaar-01

Figuur 1. Conclusies integrated audit.

Op grond van de Sarbanes-Oxley wet is in de Verenigde Staten een toezichthoudend orgaan opgericht, de Public Company Accounting Oversight Board (PCAOB). De PCAOB heeft in maart 2004 een controlestandaard uitgegeven genaamd ‘An audit of internal control over financial reporting in conjunction with an audit of financial statements’ (Auditing Standard No. 2). In deze standaard zet de PCAOB uiteen op welke wijze een integrated audit door de accountant dient te worden uitgevoerd. Volgens de PCAOB ([PCAO05a]) is een systeem van interne beheersingsmaatregelen sinds geruime tijd de fundering van het verslaggevingsproces van de onderneming alsmede van de jaarrekeningcontrole door de externe accountant. De externe accountant onderzocht in hoeverre gesteund kon worden op dit systeem om een efficiënte controle uit te voeren. Dit onderzoek was echter niet verplicht. Tevens had de externe accountant de mogelijkheid om meer arbeidsintensieve gegevensgerichte werkzaamheden te verrichten indien het systeem van onvoldoende opzet was, niet bestond of niet werkte. Echter, door de invoering van de Sarbanes-Oxley wet en Auditing Standard No. 2 is de keuzemogelijkheid voor de accountant vervallen: het onderzoeken van de opzet, het bestaan en de werking van het systeem van interne beheersingsmaatregelen is verplicht geworden, alsmede het formuleren van een conclusie daarover door zowel het verantwoordelijk management als de externe accountant. Om de werkzaamheden van de accountant onder deze verplichting zo efficiënt mogelijk in te richten heeft de PCAOB in haar Auditing Standard No. 2 de integrated audit geïntroduceerd.

Op 30 november 2005 publiceerde de PCAOB haar onderzoeksrapport naar de initiële implementatie van Auditing Standard No. 2 ([PCAO05b]). Conclusie van het onderzoek is dat de controles uitgevoerd sinds de implementatie vaak niet zo effectief en efficiënt zijn uitgevoerd als bedoeld in de Auditing Standard No. 2. De PCAOB geeft aan dat de uitdagingen zeer groot zijn geweest:

  • Tijdsdruk. De Sarbanes-Oxley wet is op 30 juli 2002 van kracht geworden. Grote Amerikaanse ondernemingen dienden vanaf 15 november 2004 aan artikel 404 te voldoen. Gezien de eisen die aan de onderneming worden gesteld, is deze doorlooptijd kort. Dat heeft tot gevolg gehad dat sommige ondernemingen nog niet gereed waren voor de integrated audit van de accountant met betrekking tot boekjaren eindigend op of na 15 november 2004.
  • Tekort aan personeel zowel bij de ondernemingen als bij de accountantskantoren.
  • Tekort aan geschoold personeel.
  • Achterstallig onderhoud aan het raamwerk van interne beheersingsmaatregelen.

De belangrijkste waarneming ter onderbouwing van de teleurstellende conclusie van de PCAOB betreft de beperkte integratie van de controle van de jaarrekening met de controle van de interne beheersing. De PCAOB verwacht dan ook dat op basis van de opgedane ervaringen een betere integratie mogelijk moet zijn en zal leiden tot effectievere en efficiëntere accountantscontroles en daarmee ook tot lagere kosten voor de ondernemingen.

Relevante wet- en regelgeving

De Public Company Accounting Oversight Board is een private, not-for-profitonderneming, die in het kader van de Sarbanes-Oxley wet is opgericht om toezicht te houden op accountants die beursgenoteerde ondernemingen controleren, met als doel de belangen van de beleggers en het publiek te behartigen bij het opstellen van informatieve, getrouwe en onafhankelijke accountantsverklaringen. De PCAOB heeft inmiddels vier Auditing Standards uitgegeven waarvan Standard No. 2 de belangrijkste is. Belangrijk om op te merken is echter dat de PCAOB toezicht houdt op en regels uitgeeft ten behoeve van accountants. Op grond van de Sarbanes-Oxley wet is de Securities Exchange Commission (SEC) belast met het toezicht op de ondernemingen en is de SEC de instantie die regelgeving verschaft met betrekking tot de ondernemingen. Wat betreft nadere concretisering van de Sarbanes-Oxley wet heeft de SEC tot op heden diverse ‘Frequently asked questions’ en een ‘Staff Statement on Management’s report on Internal Control over Financial Reporting’ uitgegeven. Omdat deze nadere concretisering op bepaalde punten nog steeds vrij beperkt is, wordt door ondernemingen vaak ook gerefereerd aan de PCAOB Standard No. 2.

De regelgevers in de Verenigde Staten hebben verschillende categorieën ondernemingen onderkend die onderhevig zijn aan de Sarbanes-Oxley wet. Op dit moment is het zo dat buitenlandse ondernemingen (d.w.z. niet Amerikaans) met een beursnotering aan de Amerikaanse beurzen moeten voldoen aan de wet op het einde van het eerste boekjaar eindigend na 15 juli 2006.

Kosten SOX 404 compliance

De fasen van een integrated audit zijn in hoofdlijnen gelijk aan de fasen van een reguliere jaarrekeningcontrole (zie hierna). Toch blijkt uit onderzoek dat de impact op de omvang van de werkzaamheden van de accountant in uren uitgedrukt aanzienlijk is. De vier grootste accountantskantoren hebben een onderzoeksbureau gevraagd onderzoek te doen naar de accountantskosten gerelateerd aan de controle van interne beheersing ([Char05]). Het onderzoeksbureau onderzocht negentig grote Amerikaanse ondernemingen. De gemiddelde omzet van deze ondernemingen over 2004 bedroeg 8,1 miljard dollar. De gemiddelde accountantskosten bedroegen 1,9 miljoen dollar extra uit hoofde van de controle van interne beheersing. Een ander onderzoek ([Fole05]) geeft een stijging (ten opzichte van 2003) van de totale accountantskosten aan van 55 procent voor zeer grote huishoudingen tot 84 procent voor kleinere huishoudingen.

Deze toename van de accountantskosten voor de huishoudingen is uiteraard het gevolg van een toename van gewerkte uren door de accountant. Mogelijke verklaringen voor deze toename zijn:

  • Tijdsdruk: dit aspect hebben wij in de vorige opsomming reeds beschreven.
  • Steile leercurve wat betreft de vereisten van de Sarbanes-Oxley wet en de Auditing Standard voor zowel de externe accountants als het management.
  • Onvermogen om de reguliere controle te integreren met de controle van de interne beheersing: wij verwijzen naar de mogelijke oorzaken daarvoor genoemd in het onderzoeksrapport naar de initiële implementatie van Auditing Standard No. 2.

Genoemde toenames hebben betrekking op het controlejaar 2004 ten opzichte van 2003 voor Amerikaanse ondernemingen. De verwachting is dat door een betere integratie van beide controles evenals de toegenomen kennis bij zowel ondernemingen als accountants de accountantskosten ten opzichte van 2004 zullen dalen voor de onderzochte groep ondernemingen.

Controleaanpak integrated audit

Fasering integrated audit

In deze paragraaf wordt aandacht gegeven aan de uitwerking van de fasering van de integrated audit aanpak. De fasering is op hoofdlijnen weergegeven in tabel 2.

C-2006-2-Beugelaar-t02

Tabel 2. Fasering integrated audit.

Deze fasen zijn op hoofdlijnen gelijk aan de fasen van een reguliere jaarrekeningcontrole. Toch blijkt uit onderzoek dat de impact op de omvang van de werkzaamheden van de accountant, alsmede de kosten, aanzienlijk zijn. De achtergrond hiervan hebben wij in voorgaande paragrafen reeds toegelicht. In de paragrafen hierna wordt een nadere toelichting gegeven per fase.

Fase 1. Plannen van de controle

Fase 1 betreft het plannen van de controle. Tijdens deze fase evalueert de accountant het effect van een groot aantal zaken voor de opzet van zijn controle. Deze evaluatie wijkt over het algemeen niet af van de evaluatie die de accountant maakt bij een reguliere accountantscontrole. In deze fase worden onder meer op basis van geïdentificeerde ‘significant accounts’ vanuit de jaarrekening de belangrijke processen bepaald die deze ‘accounts’ voeden. Belangrijk aspect bij het plannen van de controle voor SOX 404 is het bepalen van de scope; dat wil zeggen wordt voldoende ‘coverage’ behaald bij de selectie van de geïdentificeerde ‘significant accounts’ door het selecteren van bedrijfsonderdelen en processen.

Specifieke voorschriften indien de huishouding uit meerdere onderdelen bestaat

Veelal zal de huishouding uit meerdere onderdelen bestaan. Deze onderdelen kunnen geografisch verspreid zijn, waardoor meerdere accountants bij de controle betrokken zijn. De groepsaccountant[Onder ‘groepsaccountant’ wordt verstaan de accountant die verantwoordelijk is voor het afgeven van de accountantsverklaring bij de jaarrekening van een huishouding waarin financiële gegevens van één of meer (groeps)onderdelen zijn verwerkt die door een andere accountant zijn gecontroleerd (Richtlijnen voor de Accountantscontrole, editie 2002).] bepaalt gedurende de planningsfase welke onderdelen object van onderzoek zijn en wat de reikwijdte van het onderzoek is. De overwegingen die een rol spelen bij bovenstaande bepaling in het kader van een jaarrekeningcontrole zijn minder gereguleerd dan bij een integrated audit. De Richtlijnen voor de Accountantscontrole evenals de Amerikaanse Auditing Standards geven slechts zeer beperkt voorschriften voor de bepaling van de objecten van onderzoek. De reikwijdte van het onderzoek zal veelal afhankelijk zijn van het feit of het onderdeel een statutaire jaarrekening dient te laten controleren.

Auditing Standard No. 2 echter staat in een aparte bijlage[Appendix B van de Auditing Standard No. 2.] uitgebreid stil bij huishoudingen die uit meerdere onderdelen bestaan. De onderdelen worden in drie categorieën verdeeld:

  • onderdelen die individueel financieel significant zijn;
  • onderdelen die bijzondere risico’s met zich meebrengen;
  • onderdelen die financieel significant zijn indien samengevoegd met andere onderdelen.

Onderdelen die individueel financieel significant zijn en onderdelen die bijzondere risico’s met zich meebrengen zijn altijd object van onderzoek bij een integrated audit. Onderdelen die financieel significant zijn indien samengevoegd met andere onderdelen zijn object indien zij als groep een mogelijke materiële onjuistheid in de jaarrekening kunnen veroorzaken. Volgens de Auditing Standard No. 2 dient de accountant uiteindelijk de interne beheersingsmaatregelen over een ‘large portion’ van de activiteiten en de financiële positie van de huishouding te onderzoeken. De invulling van de begrippen ‘financieel significant’ en ‘large portion’ wordt vervolgens weer aan het ‘professional judgement’ van de groepsaccountant overgelaten.

In de praktijk wordt als leidraad vaak vijf procent van een relevant kengetal (bijvoorbeeld netto-omzet) aangehouden om de individueel financieel significante onderdelen te bepalen. Over het algemeen beschouwt men het hoofdkantoor van de huishouding als onderdeel dat individueel financieel significant is. Onderdelen die bijzondere risico’s met zich meebrengen kunnen bijvoorbeeld de financieringsmaatschappij of de interne verzekeringsmaatschappij zijn. ‘Large portion’ staat in de praktijk veelal voor zestig tot tachtig procent van de activiteiten en de financiële positie van de huishouding.

De reikwijdte van het onderzoek is afhankelijk van in welke categorie het onderdeel is ingedeeld. Bij onderdelen die individueel financieel significant zijn, dient de andere accountant bijvoorbeeld onder meer alle interne beheersingsmaatregelen met betrekking tot de relevante controledoelstellingen van alle ‘significant accounts’ te onderzoeken. De andere accountant zal bij onderdelen die bijzondere risico’s met zich meebrengen, vooral de interne beheersingsmaatregelen met betrekking tot de betreffende risico’s onderzoeken.

Overigens wijkt de definitie van ‘onderdeel’ zoals gebruikt bij de jaarrekeningcontrole niet af van de definitie zoals gebruikt in de integrated audit. Een onderdeel is over het algemeen een eenheid die afzonderlijk financiële informatie samenstelt, haar eigen administratie voert en unieke interne beheersingsmaatregelen kent ten opzichte van andere eenheden.

Onderdelen die uit meerdere fysieke locaties bestaan

Een onderdeel geselecteerd door de groepsaccountant kan uit meerdere fysieke locaties bestaan. Op deze locaties kunnen interne beheersingsmaatregelen worden uitgevoerd. In het kader van de reguliere jaarrekeningcontrole zal de accountant proberen de controle dusdanig te plannen dat hij met behulp van gegevensgerichte werkzaamheden en mogelijk het testen van enkele centrale toezichthoudende interne beheersingsmaatregelen voldoende bewijs zal vergaren.

Echter, indien interne beheersingsmaatregelen worden uitgevoerd op de diverse fysieke locaties met betrekking tot de relevante controledoelstellingen van significante jaarrekeningposten, zal de accountant in het kader van de integrated audit de werking van deze maatregelen dienen vast te stellen. Uiteraard zal ook bij een integrated audit de accountant proberen te voorkomen dat hij een groot aantal locaties dient te bezoeken, maar dat zal lastiger zijn dan bij de reguliere jaarrekeningcontrole. Uiteindelijk dient de accountant de interne beheersingsmaatregelen over een ‘large portion’ van de activiteiten en de financiële positie van de huishouding te onderzoeken.

Fase 2. Uitvoeren en evalueren van de effectiviteit van het systeem van interne beheersingsmaatregelen

Fase 2 betreft het evalueren van de werkzaamheden die de leiding van de huishouding heeft verricht ten behoeve van haar bewering betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen. Tevens bevat deze fase voor de externe accountant het verkrijgen van inzicht in het systeem van interne beheersingsmaatregelen ten behoeve van de eigen uit te voeren testwerkzaamheden en evaluatie. Deze fase is specifiek voor een integrated audit. In deze fase zullen door de externe accountant derhalve ook eigen werkzaamheden worden uitgevoerd, naast het beoordelen van de door het management uitgevoerde werkzaamheden.

De werkzaamheden voor fase 2 bestaan enerzijds uit het kennisnemen van de resultaten van door het management uitgevoerde testwerkzaamheden, het verkrijgen van kennis van het systeem van de interne beheersingsmaatregelen en het uitvoeren van eigen werkzaamheden. Hiertoe wordt een aantal activiteiten uitgevoerd mede naar aanleiding van de scopebepaling vanuit fase 1. Deze activiteiten betreffen onder meer:

  • Het identificeren van de ‘Company Level Controls’ alsmede het testen van de opzet, het bestaan en de werking van deze controls.
  • Het identificeren van de ‘significant accounts’ (en toelichtingen), van de relevante controledoelstellingen en van de significante transactiestromen.
  • Het verkrijgen van kennis over de informatiesystemen, met inbegrip van de hiermee verband houdende bedrijfsprocessen, voorzover van belang voor de financiële verslaggeving.
  • Het identificeren van de onderdelen van het systeem van interne beheersingsmaatregelen waarvan de effectiviteit van zowel de opzet (inclusief bestaan) als de werking geëvalueerd dient te worden. Hieronder valt ook een onderzoek naar het stelsel van IT General Controls (algemene IT-beheersingsmaatregelen).
  • Het testen van de geïdentificeerde interne beheersingsmaatregelen in opzet, bestaan en werking, alsmede het doen van de evaluatie. Het testen van de opzet en het bestaan kan onder meer plaatsvinden door het uitvoeren van een lijncontrole.

Bij de uitvoering van bovenstaande werkzaamheden dient zoveel mogelijk gebruik te worden gemaakt van door anderen (management of bijvoorbeeld een interne accountantsdienst) reeds uitgevoerde werkzaamheden. De mate van het gebruikmaken van de werkzaamheden van anderen wordt bepaald door een aantal factoren waaronder de onafhankelijkheid en deskundigheid van deze personen.

In onderstaande subparagrafen wordt kort ingegaan op een aantal specifieke activiteiten in de integrated audit.

Company Level Controls

‘Company Level Controls’ zijn te omschrijven als interne beheersingsmaatregelen die betrekking hebben op de onderneming als geheel in plaats van op specifieke processen, transacties en/of systemen. De Auditing Standard No. 2 geeft aan dat het COSO-raamwerk ([Coso]) geschikt is, maar ook ‘Guidance on Assessing Control’ van het Canadese instituut (CICA) en het ‘Turnbull-rapport’ opgesteld door het Engelse instituut (ICAEW) zijn geschikt bevonden. Een dergelijke verplichting voor de leiding om een raamwerk te kiezen en toe te passen is specifiek voor ondernemingen die onderhevig zijn aan integrated audits. De accountant dient de keuze en toepassing te betrekken in zijn onderzoek.

Het COSO-raamwerk neemt ook in de reguliere jaarrekeningcontrole een belangrijke plaats in als raamwerk voor de accountant om de effectiviteit van de interne beheersing te toetsen. Deze beoordeling is een standaardonderdeel van de reguliere jaarrekeningcontrole. Ook veel internationaal opererende ondernemingen zullen een algemeen aanvaard raamwerk als het COSO-raamwerk hanteren. Toch is de expliciete eis in Auditing Standard No. 2 nieuw en een punt waarop de integrated audit afwijkt van de reguliere jaarrekeningcontrole.

Indien het COSO-raamwerk is gekozen voor het beoordelen van de effectiviteit van de interne beheersing, betreft het vooral de vier componenten: beheersingsomgeving, risico-inschattingsproces, informatiesysteem en de communicatie, alsmede het toezicht op de werking van de beheersingsmaatregelen. Het identificeren, begrijpen en evalueren van de opzet en het bestaan van deze beheersingsmaatregelen is bij een integrated audit het startpunt van het onderzoek. Het dwingt de accountant tot een top-down benadering. De reden hiervoor is dat de effectiviteit van deze beheersingsmaatregelen doorgaans veel impact heeft voor het stelsel van beheersingsmaatregelen op proces-, transactie- of applicatieniveau. De uitkomst van de eerdergenoemde evaluatie heeft daardoor invloed op de verdere bepaling van de aard, de tijdsfasering en de omvang van de controlewerkzaamheden. In het kader van een integrated audit is het identificeren, begrijpen en evalueren van de opzet en het bestaan van deze beheersingsmaatregelen in geen enkel geval voldoende. Ook de effectieve werking van de interne beheersingsmaatregelen dient te worden vastgesteld, inclusief de ‘Company Level Controls’.

Identificatie van te testen interne beheersingsmaatregelen

In deze subparagraaf wordt stilgestaan bij de invulling van de activiteiten voor de tweede tot en met vierde bullet. In de praktijk hebben wij gezien dat ondernemingen veel tijd en energie hebben moeten steken in het identificeren van de processtappen, risico’s en significante beheersingsmaatregelen (‘key controls’). Veelal kwam dit voort uit het feit dat duidelijke procesbeschrijvingen niet aanwezig waren of verouderd waren, dan wel onvoldoende kennis aanwezig was hoe processen daadwerkelijk worden uitgevoerd binnen de organisatie en welke ‘key controls’ aanwezig zijn om de risico’s te beheersen. Ook hebben wij geconstateerd dat in hooggeautomatiseerde omgevingen, door gebrek aan kennis en ervaring binnen de organisatie, significante beheersingsmaatregelen ten onrechte als handmatige beheersingsmaatregelen zijn geïdentificeerd. Dit heeft als gevolg dat de ‘sample size’ voor het testen van de werking van een handmatige beheersmaatregel kan oplopen tot dertig à zestig keer testen.

C-2006-2-Beugelaar-02

Figuur 2. Typen beheersingsmaatregelen.

In figuur 2 trachten wij te benadrukken dat verschillende typen beheersingsmaatregelen geïdentificeerd kunnen worden, te weten ‘application controls’, ‘manual controls’ en ‘IT general controls’. De verantwoordelijkheid voor de uitvoering van deze beheersingsmaatregelen is in de praktijk op verschillende plaatsen binnen de organisatie belegd. Het beheer van de technische IT-infrastructuurcomponenten (besturingssysteem, netwerk en databasemanagementsysteem) is veelal belegd binnen een IT-rekencentrum. Het beheer van de bedrijfsprocessen en de applicaties wordt veelal uitgevoerd binnen de operationele bedrijfsafdelingen. Het uitvoeren en testen van de verschillende typen beheersingsmaatregelen vindt derhalve door verschillende disciplines plaats binnen de klantorganisatie, hetgeen ook gevolgen heeft voor de uitvoering van het werk bij de externe accountantskantoren. Een dergelijke aanpak vraagt om een teamsamenstelling waarbij IT-auditors en financial auditors betrokken zijn.

Bij de uitvoering van de integrated audit is het verplicht om een systeemgerichte controleaanpak te hanteren. De algemene IT-beheersingsmaatregelen zijn derhalve onderwerp van onderzoek zodra de accountant steunt op beheersingsmaatregelen uitgevoerd door een applicatie en/of zodra de accountant gebruikmaakt van rapporten uit een IT-applicatie. Het onderzoek dat de accountant vervolgens verricht naar de opzet, het bestaan en de werking van de algemene IT-beheersingsmaatregelen wijkt bij een integrated audit niet af van de reguliere jaarrekeningcontrole. Belangrijker nog is om te onderkennen dat ook de ‘application controls’ getest moeten worden. In de praktijk zien wij dat hier nog een verbetering in aangebracht dient te worden voor wat betreft de invulling ervan.

Ten behoeve van een effectieve en efficiënte integrated-auditaanpak zijn wij van mening dat bij de bepaling van de relevante ‘key controls’ aan de bedrijfsprocessenzijde een samenwerking tussen financial en IT-auditor onontbeerlijk is. Dit mede ter bepaling en herkenning van de juiste mix aan ‘application controls’ en ‘manual controls’. Een organisatie die in belangrijke mate gebruikmaakt van geautomatiseerde systemen en de daarin opgenomen geprogrammeerde controles ter ondersteuning van de voor haar financiële rapportage belangrijke processen, kan efficiencyvoordelen realiseren in de mate van uit te voeren testwerkzaamheden.

Bij onze klanten kunnen zich situaties voordoen waarbij een ‘application control’ geïmplementeerd is die geldt voor elke gedane transactie. Een voorbeeld hiervan is een controle op een verkooptransactie waarbij de betalingstermijn van dertig dagen wordt overschreden. Het systeem zorgt ervoor dat dit gesignaleerd wordt zodat het aanmaningsproces gestart kan worden en dat een eventuele voorziening voor oninbare debiteuren wordt getroffen. Ten behoeve van het testen van deze geprogrammeerde applicatiecontrole kan het draaien van een systeemquery en het beoordelen van de systeemparameter een testtechniek zijn. Hiermee kan worden vastgesteld of de ‘application control’ functioneert. Wanneer tevens is vastgesteld dat de IT general controls ten aanzien van met name ‘program changes’ en ‘access to programs and data’ effectief zijn zodat de geprogrammeerde controle niet ongeautoriseerd aangepast kan worden, dan volstaat een test (deelwaarneming) van één. Ook behoeft deze niet jaarlijks getest te worden, maar kan worden volstaan met ‘benchmarking’ en het jaarlijks vaststellen dat de IT general controls voor met name ‘program changes’ en ‘access to programs and data’ voor deze geautomatiseerde applicatiecontrole effectief zijn en getest worden. Tevens dient de auditor vast te stellen dat de geprogrammeerde controle inhoudelijk niet gewijzigd is ten opzichte van de laatste keer dat deze getest is. Dit zien wij als onderdeel van het change-managementproces.

Geautomatiseerde applicatiecontroles kunnen onder meer bestaan uit calculaties, boekingsschema’s naar jaarrekeningposten, het genereren van (verschillen)rapportages, en het signaleren van geprogrammeerde systeemsettingoverschrijdingen (stuurparameters). Het testen van deze controles kan bijvoorbeeld plaatsvinden door het herberekenen of opnieuw aanleveren van een transactie en nagaan of de resultaten kloppen.

Een belangrijk verschil tussen de integrated audit en de reguliere jaarrekeningcontrole betreft de situatie dat in een reguliere controle de accountant kan besluiten om bijvoorbeeld om een applicatie heen te controleren. In geval van de integrated audit dient de accountant zich ook een opinie te vormen over de effectiviteit van belangrijke applicatiecontroles en deze derhalve ook te testen.

Testen van de geïdentificeerde beheersingsmaatregelen

De accountant heeft ten behoeve van de uitvoering van het testen van de opzet, het bestaan en de werking verschillende testtechnieken ter beschikking, zoals het doen van interviews, het doen van waarnemingen ter plaatse, het uitvoeren van cijferbeoordeling en verbandscontroles, het uitvoeren van een lijncontrole, het beoordelen van ontvangen documentatie en het draaien van systeemqueries met behulp van auditsoftware. Deze testtechnieken zijn in een integrated audit hetzelfde als bij een reguliere jaarrekeningcontrole. Derhalve ook hier ‘niets nieuws onder de zon’.

Ook voor wat betreft het testen van de opzet, het bestaan en de werking en de te nemen aantallen steekproeven geldt dat voor de integrated audit wordt aangehaakt bij de reeds bestaande richtlijnen voor de reguliere jaarrekeningcontrole.

Waar wij wel een voordeel zien ten opzichte van de reguliere jaarrekeningcontrole is het feit dat het management onder SOX 404 zelf ook testwerkzaamheden uitvoert, waar de externe accountant onder bepaalde voorwaarden gebruik van mag maken. Dit betekent een besparing aan testinspanning voor de externe accountant.

Ten aanzien van de evaluatie van de testwerkzaamheden wordt in het kader van de integrated audit de bewering door de leiding van de huishouding betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen beoordeeld en wordt door de externe accountant ‘The auditors’ opinion on effectiveness of ICoFR’ verstrekt.

Fase 3. Planning en uitvoering van gegevensgerichte werkzaamheden

Waarom deze fase in een integrated audit? Het onderzoeken van de opzet, het bestaan en de werking van het systeem van interne beheersingsmaatregelen is toch verplicht geworden? Klopt, maar het doel van een integrated audit is te komen tot meer dan alleen een conclusie met betrekking tot het systeem van interne beheersingsmaatregelen. Ook de financiële positie, de financiële resultaten en de kasstromen zijn object van onderzoek. Indien het systeem niet effectief is in opzet of werking kunnen aanvullende gegevensgerichte werkzaamheden nodig zijn om toereikend controlebewijs in het kader van de reguliere jaarrekeningcontrole te verzamelen.

Van belang in dit kader is het feit dat de jaarrekening betrekking heeft op een boekjaar. De bewering betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen door management en accountant heeft echter betrekking op de situatie per einde boekjaar. Dat betekent dat het systeem gedurende een periode van het jaar niet effectief kan zijn geweest, maar het management deze ineffectiviteit gerepareerd kan hebben per einde boekjaar, waardoor zowel haar bewering als de bewering van de externe accountant goedkeurend kan zijn.

Ondanks het feit dat het onderzoek naar het systeem van interne beheersingsmaatregelen verplicht is, zal de externe accountant altijd beperkte gegevensgerichte werkzaamheden verrichten in het kader van de controle van de jaarrekening. Voorbeelden van dergelijke werkzaamheden zijn het verrichten van afsluitende cijferbeoordeling en het aansluiten van de jaarrekening op de saldibalans.

Conclusie is dat de gegevensgerichte werkzaamheden worden uitgevoerd ten behoeve van de reguliere jaarrekeningcontrole, en niet in het kader van het systeem van interne beheersingsmaatregelen.

Fase 4. Komen tot een conclusie

Een effectief systeem van interne beheersingsmaatregelen verkleint in belangrijke mate de kans op menselijke fouten, verkeerde beslissingen, het doelbewust omzeilen van beheersingsmaatregelen door werknemers en managers en het zich voordoen van onvoorziene omstandigheden. Het kan echter in geen geval absolute zekerheid bieden tegen het niet realiseren van ondernemingsdoelstellingen, noch kan het alle onjuistheden van materieel belang, verlies, fraude en overtredingen van wetten of regels voorkomen. Het systeem kan volgens COSO als effectief worden beschouwd als het management en de leiding een redelijke zekerheid hebben dat:

  • zij op de hoogte zijn van de mate waarin de operationele doelstellingen van de onderneming zijn bereikt;
  • de gepubliceerde financiële rapportages betrouwbaar zijn opgesteld;
  • de organisatie zich houdt aan de van toepassing zijnde wetgeving en regels.

Interne beheersing is een proces, zoals blijkt uit de definitie van COSO. In dit proces moet de onderneming vaststellen dat de interne beheersingsmaatregelen qua opzet, bestaan en werking adequaat en effectief zijn. De mate van adequaatheid is echter een staat waarin het proces verkeert op een bepaald moment in de tijd. Om te bepalen of het systeem effectief gewerkt heeft gedurende het gehele boekjaar zal er op meerdere momenten een evaluatie moeten plaatsvinden. Dit houdt in dat een adequaat en effectief systeem van interne beheersingsmaatregelen procedures omvat die ervoor zorgen dat onder andere de belangrijke tekortkomingen of zwakke punten in het systeem worden gemeld.

Een belangrijk verschil tussen de reguliere jaarrekeningcontrole en de integrated audit is de periode van effectieve werking. De accountant verricht bij een jaarrekeningcontrole systeemgerichte werkzaamheden indien zijn risico-inschatting mede omvat een verwachting ten aanzien van de effectieve werking van de interne beheersingsmaatregelen of indien het uitvoeren van uitsluitend gegevensgerichte werkzaamheden geen toereikende controle-informatie oplevert ([NIVR05b]). Deze werkzaamheden worden zodanig uitgevoerd dat de accountant zekerheid verkrijgt omtrent de doorlopende werking van de maatregelen gedurende de verslaggevingsperiode. Echter, in het kader van een controle van interne beheersing zoals opgenomen in de Sarbanes-Oxley wet is het vaststellen van de werking op een bepaald moment van belang. Dat moment is het einde van de verslaggevingsperiode (voor Nederlandse huishoudingen meestal 31 december). Het gaat dus om een momentopname.

Dat betekent dat tekortkomingen geconstateerd door de leiding en/of accountant gedurende de verslaggevingsperiode mogelijk nog gerepareerd kunnen worden en dus geen invloed kunnen hebben op de uiteindelijke accountantsverklaring (inzake de interne beheersing). Bij een reguliere jaarrekeningcontrole zal de accountant bij belangrijke tekortkomingen overgaan op gegevensgerichte werkzaamheden of de strekking van zijn accountantsverklaring aanpassen.

Ondanks het feit dat de controle van interne beheersing zich beperkt tot een momentopname dienen de interne beheersingsmaatregelen wel een bepaalde periode te bestaan en te werken. De lengte van deze periode is afhankelijk van de aard en de frequentie van de maatregel. Als stelregel voor de lengte wordt veelal genomen een dusdanige periode dat de accountant in staat is zijn minimale steekproefomvang te waarborgen.

Tekortkomingen in de interne beheersing

Een tekortkoming bestaat indien de opzet, het bestaan of de werking van een interne beheersingsmaatregel onder normale omstandigheden het management of personeel niet in staat stelt onjuistheden tijdig te voorkomen of te ontdekken. Tijdens diverse fasen van de controle kan de accountant tekortkomingen in de interne beheersing constateren. Gedurende het evalueren van de effectiviteit van de werking van het systeem van interne beheersingsmaatregelen kan de accountant ook uitzonderingen tegenkomen. Een uitzondering doet zich voor indien tijdens de evaluatie van de deelwaarneming blijkt dat een interne beheersingsmaatregel niet werkt zoals bedoeld is. Onder bepaalde voorwaarden is de deelwaarneming uit te breiden om toch te kunnen concluderen dat de maatregel effectief werkt, maar over het algemeen dient de accountant te concluderen dat er sprake is van een tekortkoming.

De Auditing Standard No. 2 kent drie varianten van tekortkomingen:

  • tekortkomingen;
  • significante tekortkomingen;
  • ‘materiële tekortkomingen’ (‘material weaknesses’).

De ernst van de geconstateerde tekortkoming is afhankelijk van de mogelijkheid dat de tekortkoming leidt tot een onjuistheid in de jaarrekening. Bij een controle van interne beheersing is de mogelijkheid van onjuistheden van belang en niet of zich daadwerkelijk onjuistheden hebben voorgedaan. Om de accountant te ondersteunen bij zijn inschatting van de ernst van de geconstateerde tekortkoming hebben de negen grootste Amerikaanse accountantskantoren een raamwerk ontwikkeld ([Fram04]). Dit raamwerk geeft beslissingsbomen voor de volgende bevindingen:

  • Geconstateerde uitzonderingen: wanneer is er sprake van een tekortkoming?
  • Geconstateerde tekortkomingen op proces- en transactieniveau: wanneer is er sprake van een significante tekortkoming of zelfs van een ‘material weakness’?
  • Geconstateerde tekortkomingen betreffende de algemene IT-beheersingsmaatregelen: wanneer is er sprake van een significante tekortkoming of zelfs van een ‘material weakness’?
  • Geconstateerde tekortkomingen betreffende interne beheersingsmaatregelen die betrekking hebben op de huishouding als geheel: wanneer is er sprake van een significante tekortkoming of zelfs van een ‘material weakness’?

Behalve genoemd raamwerk bevat de Auditing Standard No. 2 zelf enkele omstandigheden waarin sprake is van minstens een significante tekortkoming, mogelijk zelfs een ‘material weakness’. Voorbeelden van dergelijke omstandigheden zijn het herstel van fouten in de jaarrekening (na vaststelling van de jaarrekening), het ontdekken van een materiële onjuistheid in de concept-jaarrekening door de accountant, en ineffectief toezicht op de externe verslaggeving door het Audit Committee.

Alle geconstateerde tekortkomingen dienen door de leiding van de huishouding en door de accountant beoordeeld te worden op hun ernst. Deze beoordeling vindt plaats per tekortkoming, maar ook gecombineerd. Ter illustratie: de accountant kan meerdere significante tekortkomingen hebben geconstateerd die individueel bezien niet zullen leiden tot de reële mogelijkheid dat een materiële onjuistheid in de jaarrekening niet wordt voorkomen of geconstateerd. Indien deze significante tekortkomingen bijvoorbeeld allemaal samenhangen met interne beheersingsmaatregelen die de volledigheid van de omzet waarborgen, is er mogelijk wel sprake van een ‘material weakness’. Opgemerkt dient te worden dat deze beoordeling pas behoeft te worden gemaakt naar de situatie aan het einde van de verslaggevingsperiode. Tekortkomingen geconstateerd gedurende het jaar hoeven daarom niet beoordeeld te worden op hun ernst.

De accountant dient alle geconstateerde tekortkomingen te rapporteren aan de leiding van de huishouding met uitzondering van tekortkomingen die reeds door anderen (bijvoorbeeld de interne accountantsdienst) zijn gerapporteerd aan de leiding. Alle significante tekortkomingen en ‘material weaknesses’ moeten door de accountant gerapporteerd worden aan de leiding alsook aan het Audit Committee.

Concept-jaarrekeningen

In voorgaande subparagraaf hebben wij opgemerkt dat het ontdekken van een materiële onjuistheid in een concept-jaarrekening door de accountant gezien wordt als minstens een significante tekortkoming, mogelijk zelfs een ‘material weakness’. Bij de reguliere jaarrekeningcontrole werken de accountant en de leiding tijdens de jaarafsluiting vaak nauw samen. De accountant voert zijn werkzaamheden vaak uit op de concept-jaarrekening en koppelt zijn bevindingen zo snel mogelijk terug aan de leiding. Ook vinden vaak discussies tussen de accountant en de leiding plaats over de implementatie van nieuwe verslaggevingsregels. Ontstaat nu een probleem bij de integrated audit? De PCAOB heeft bovenstaande ook herkend en heeft door middel van een ‘Q&A’ aangegeven, dat enige vorm van informatie-uitwisseling tussen de leiding en de accountant mogelijk moet zijn. De leiding dient bij elk concept aan te geven in hoeverre het concept afronding nadert, welke beheersingsmaatregelen nog niet hebben gefunctioneerd en welk doel het concept voor de accountant heeft. Door dergelijke communicatie vanuit de leiding geeft zij aan het proces van de totstandkoming van de jaarrekening te beheersen. Het is en blijft de leiding die verantwoordelijk is voor de totstandkoming van de jaarrekening.

Ook discussies betreffende de implementatie van nieuwe verslaggevingsregels zijn bij een integrated audit niet verboden. Maar wederom is het van groot belang duidelijk te communiceren waarom het belangrijk is dat de accountant er door de leiding bij wordt betrokken.

Meerdere verklaringen

Zoals aangegeven in het begin van dit artikel is het doel van de integrated audit drieledig. De accountant verstrekt naar aanleiding van zijn werkzaamheden ook drie verklaringen. In de eerste plaats de reguliere accountantsverklaring betreffende de uitkomsten van zijn werkzaamheden in het kader van de controle van de jaarrekening. Deze verklaring verandert niet door de integratie met de controle van interne beheersing.

Daarnaast geeft de accountant zijn oordeel met betrekking tot zijn werkzaamheden betreffende de bewering door de leiding van de huishouding in de jaarrekening. Deze bewering door de leiding betreft de effectiviteit van het systeem van interne beheersingsmaatregelen. Tot slot beoordeelt de accountant ook zelf de effectiviteit van het systeem van interne beheersingsmaatregelen en geeft zijn oordeel hieromtrent. De verklaringen met betrekking tot de controle van interne beheersing worden gecombineerd tot één verklaring. Het is ook mogelijk de verklaring naar aanleiding van de controle van de jaarrekening te combineren en één accountantsverklaring op te nemen in de overige gegevens.

Bewering door de leiding van de huishouding

De bewering door de leiding bevat een aantal verplichte elementen. De leiding dient expliciet aan te geven dat zij verantwoordelijk is voor het opzetten en onderhouden van een effectief stelsel van interne beheersingsmaatregelen. Ten behoeve van het beoordelen van de effectiviteit dient de leiding een raamwerk te kiezen. Het gekozen raamwerk wordt door de leiding opgenomen in haar bewering. Uiteraard dient de leiding de uitkomsten van haar beoordeling betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen op te nemen. De leiding dient bij het verwoorden van de uitkomsten expliciet aan te geven of het systeem effectief was. De leiding mag niet concluderen dat het systeem effectief was indien zij één of meer ‘material weaknesses’ heeft geconstateerd. Tot slot dient de bewering van de leiding aan te geven dat de accountant die de jaarrekening heeft gecontroleerd, ook een verklaring heeft verstrekt met betrekking tot de bewering door de leiding.

Verklaring accountant betreffende de bewering door de leiding van de huishouding

De accountant dient het beoordelingsproces van de leiding van de huishouding betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen te begrijpen en te evalueren. De accountant stelt vast dat:

  • de leiding een selectie heeft gemaakt van de interne beheersingsmaatregelen die zij dient te testen ter onderbouwing van haar bewering;
  • de leiding een selectie heeft gemaakt van de onderdelen relevant voor haar evaluatie;
  • de leiding een geschikt raamwerk heeft gekozen voor het beoordelen van de effectiviteit van de interne beheersing;
  • de leiding de opzet en het bestaan van de door haar geselecteerde interne beheersingsmaatregelen heeft vastgesteld;
  • de leiding de werking van de door haar geselecteerde interne beheersingsmaatregelen heeft vastgesteld door middel van toereikende werkzaamheden;
  • de leiding de door haar geconstateerde tekortkomingen heeft geëvalueerd en heeft gerapporteerd aan de accountant;
  • de geconstateerde tekortkomingen in overeenstemming zijn met de bewering betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen.

Zoals gebruikelijk bestaat de verklaring van de accountant uit een aantal verplichte onderdelen.

Verklaring accountant naar aanleiding van zijn bevindingen betreffende de effectiviteit van het systeem van interne beheersingsmaatregelen

De werkzaamheden die de accountant verricht in het kader van de controle van interne beheersing zijn hiervoor geschetst. Op grond van deze werkzaamheden kan de accountant tekortkomingen hebben gesignaleerd. De leiding van de huishouding mag niet oordelen dat het systeem effectief was indien zij één of meer ‘material weaknesses’ heeft geconstateerd. Dit geldt ook voor de accountant.

Onderdelen accountantsverklaring controle van interne beheersing

Op grond van de Auditing Standard No. 2 bestaat de accountantsverklaring naar aanleiding van de controle van de interne beheersing uit een aantal verplichte onderdelen. Sommige van deze onderdelen zijn gelijk aan de verplichte (of standaard-) onderdelen van de accountantsverklaring naar aanleiding van de jaarrekeningcontrole. Daardoor is het mogelijk om één gecombineerde accountantsverklaring op te stellen. De volgende verplichte onderdelen zijn als afwijkend te beschouwen:

  • Reikwijdteparagraaf: deze paragraaf bevat een verwijzing naar de algemeen aanvaarde richtlijnen met betrekking tot de controle van interne beheersing: de regelgeving van de PCAOB.
  • Definitieparagraaf: deze paragraaf geeft aan wat de accountant verstaat onder ‘internal control over financial reporting’.
  • Beperkingenparagraaf: de accountant dient een paragraaf op te nemen waarin hij aangeeft dat – door haar aard – ‘internal control over financial reporting’ mogelijk niet onjuistheden voorkomt of signaleert. Ook bevat deze paragraaf de opmerking dat de conclusies niet naar de toekomst geprojecteerd kunnen worden.
  • Oordeelparagraaf: deze paragraaf bevat twee oordelen met betrekking tot de situatie op einde van het boekjaar.
  • Toelichtende paragraaf: indien de verklaring naar aanleiding van de jaarrekeningcontrole elders is opgenomen, is de accountant verplicht een verwijzing op te nemen naar die verklaring. Vervolgens dient de accountant eenzelfde toelichtende paragraaf op te nemen aan het einde van zijn verklaring naar aanleiding van de jaarrekeningcontrole verwijzend naar de verklaring betreffende de controle van interne beheersing.

Alle verklaringen dienen op dezelfde datum ondertekend te worden.

Samenvatting

De eerste ervaringen met de controleaanpak integrated audit bij met name grote Amerikaanse ondernemingen laten een toename van de controlekosten zien. Een belangrijke oorzaak die hieraan ten grondslag ligt is het feit dat een beperkte integratie van de controle van de jaarrekening met de controle van de interne beheersing heeft plaatsgevonden.

Het doel van een integrated audit is te komen tot een conclusie geformuleerd door de accountant die is bedoeld om het vertrouwen van de beoogde gebruikers van de jaarrekening te versterken. De verantwoordelijkheden van de accountant zijn bij een integrated audit niet anders dan bij een reguliere jaarrekeningcontrole, met dien verstande dat bij de integrated audit drie conclusies geformuleerd dienen te worden in plaats van één.

Bij de uitvoering van de controleaanpak integrated audit staat het stelsel van interne beheersingsmaatregelen centraal. Een onderzoek naar de opzet, het bestaan en de werking van dit stelsel vormt een verplicht onderdeel van de integrated audit, alsmede het formuleren van een conclusie hierover. Dit is een belangrijk verschil ten opzichte van de reguliere jaarrekeningcontrole. Voorheen had de accountant nog de keuzemogelijkheid, in de planningsfase, om in geval van een in opzet onvoldoende stelsel van beheersingsmaatregelen de keuze te maken om meer arbeidsintensieve gegevensgerichte controlewerkzaamheden uit te voeren. In het kader van een integrated audit is deze keuze niet toegestaan.

De fasen van een controleaanpak integrated audit zijn in hoofdlijnen gelijk aan de fasen van een reguliere jaarrekeningcontrole. Voor wat betreft de fase van planning van de integrated audit geldt dat voor SOX 404 de scope bepaald dient te worden; dat wil zeggen wordt voldoende ‘coverage’ behaald bij de selectie van ‘significant accounts’ door het selecteren van de bedrijfsonderdelen en de processen. Binnen de Auditing Standard No. 2 zijn specifieke voorschriften opgenomen ter bepaling van de scope en reikwijdte van de werkzaamheden; bijvoorbeeld als de onderneming uit meerdere onderdelen en/of fysieke locaties bestaat. De richtlijnen bij een reguliere jaarrekeningcontrole ter bepaling van de scope en reikwijdte zijn minder gereguleerd dan bij een integrated audit. Ten behoeve van een doordachte efficiënte controleaanpak integrated audit zien wij voordelen in het hebben van nadere voorschriften ter bepaling van de scope van de werkzaamheden. Het op een doordachte en onderbouwde wijze bepalen van de scope en reikwijdte draagt bij aan een deugdelijke grondslag en een effectieve en efficiënte controleaanpak.

De fase uitvoeren en evalueren van de effectiviteit van het systeem van interne beheersingsmaatregelen is een specifieke fase voor de integrated audit, in die zin dat in deze fase bij uitstek gestreefd moet worden naar het behalen van efficiencyvoordelen tussen de reguliere jaarrekeningcontrolewerkzaamheden en de SOX 404-werkzaamheden. Een belangrijk voordeel als gevolg van SOX 404 is dat het management ook testwerkzaamheden uitvoert ten aanzien van het stelsel van interne beheersingsmaatregelen. Bij de uitvoering van de werkzaamheden door de externe accountant dient waar mogelijk gebruik te worden gemaakt van de door anderen (management of bijvoorbeeld interne accountantsdienst) reeds uitgevoerde werkzaamheden. De mate van gebruikmaken van de werkzaamheden van anderen wordt bepaald door een aantal factoren, waaronder de onafhankelijkheid en de deskundigheid van deze personen.

Een ander belangrijk aspect in deze fase wordt gevormd door het identificeren van de juiste ‘key controls’. In de praktijk hebben wij geconstateerd dat in hooggeautomatiseerde omgevingen, door gebrek aan kennis en ervaring binnen de organisatie, significante beheersingsmaatregelen ten onrechte als handmatige beheersingsmaatregelen zijn geïdentificeerd. Dit heeft tot gevolg dat bij een meerdagelijkse handmatige beheersingsmaatregel de ‘sample size’ kan oplopen tot wel zestig keer testen. Als de beheersingsmaatregel steunt op een ‘application control’, is een test met een ‘sample size’ van één voldoende. Uiteraard dienen in aanvulling hierop wel de IT general controls, en met name de onderdelen ‘Access to programs and data’ en ‘Program changes’, getest te worden. Wij verwachten dat met name op dit onderdeel nog efficiency in de controleaanpak bereikt kan worden door het op een kritische wijze beoordelen van de geïdentificeerde ‘key controls’. Diversiteit in disciplines binnen het controleteam is hierbij van belang.

Een fase die specifiek wordt uitgevoerd ten behoeve van de jaarrekeningcontrole betreft het plannen en uitvoeren van gegevensgerichte werkzaamheden. Als het systeem van interne beheersingsmaatregelen niet effectief is in opzet of werking kunnen aanvullende gegevensgerichte werkzaamheden nodig zijn om toereikend controlebewijs in het kader van de jaarrekeningcontrole te verzamelen. Deze fase zal derhalve altijd door de accountant worden uitgevoerd. Ook als het systeem van interne beheersingsmaatregelen wel effectief bevonden is, zullen altijd beperkte gegevensgerichte werkzaamheden worden uitgevoerd.

Ter afronding van de werkzaamheden zal de externe accountant een conclusie formuleren. De aard van de te verstrekken conclusie wordt bepaald door het al dan niet gesignaleerd hebben van tekortkomingen (waaronder significante en materiële tekortkomingen). De weging van de tekortkomingen behoeft pas gemaakt te worden aan het einde van de verslaggevingsperiode. Uiteindelijk zal de accountant naar aanleiding van de uitgevoerde werkzaamheden een drietal verklaringen verstrekken in tegenstelling tot één verklaring in geval van een reguliere jaarrekeningcontrole.

Literatuur

[Buur05] Drs. P.A. Buur RE RA, drs. J.J. van Beek RE RA en drs. H.G.Th. van Gils RE RA, Invloed SOX op de rol van de IT-auditor, Compact 2005/2.

[Char05] Charles River Associates, Sarbanes-Oxley 404 Costs and Remediation of Deficiencies: Estimates from a sample of Fortune 1000 companies, April 2005.

[Coso] Internal Control – Integrated Framework, by the Committee of Sponsoring Organizations (COSO) of the Treadway Commission.

[Fole05] Foley & Kardner LLP, The Cost of being Public in the era of Sarbanes-Oxley, June 2005.

[Fram04] A Framework for Evaluating Control Exceptions and Deficiencies, Version 3, December 20, 2004.

[NIVR05a] NIVRA, Paragraaf 7 en 8, Stramien voor assurance-opdrachten, Richtlijnen voor de Accountantscontrole editie 2005.

[NIVR05b] Paragraaf 22, Richtlijn voor de Accountantscontrole 315, Editie 2005.

[PCAO05a] PCAOB, Policy Statement regarding implementation of Auditing Standard No. 2, PCAOB Release No. 2005-009, May 16, 2005.

[PCAO05b] PCAOB, Report on the initial implementation of Auditing Standard No. 2, PCAOB Release No. 2005-023, November 30, 2005.

Revenue assurance voor online-informatie

Bij de verkoop van online-informatie zijn tal van partijen betrokken: eigenaren, aanbieders, distributeurs en afnemers. Deze partijen vertrouwen in veel gevallen op self-reporting als primair mechanisme voor het registreren van verkopen. Mede als gevolg hiervan zijn gegevens over de verkoop van online-informatie niet altijd betrouwbaar. Dit artikel gaat in op de achtergrond en het belang van revenue assurance voor online-informatie en geeft aan op welke wijze de betrokken partijen kunnen samenwerken om de volledigheid van de opbrengsten te waarborgen.[Dit artikel is een bewerking van het onderzoeksrapport ‘Revenue assurance for online digital content’ van KPMG. Aan het rapport is verder meegewerkt door: drs. N. Wielaart, drs. R. van der Brugge RA, prof. dr. Th. Huibers en drs. K. Bakker RA.]

Inleiding

De sector Informatie, Communicatie en Entertainment (ICE) wordt geconfronteerd met een radicale verandering als gevolg van ontwikkelingen zoals internet, online-uitgeven, digitale televisie, online-gaming en het downloaden van muziek. De wereld van online-mogelijkheden is zowel veelbelovend als uitdagend. Veel mediabedrijven, zoals platenmaatschappijen, proberen naarstig te anticiperen op de snelle veranderingen die door het gebruik van internet teweeg zijn gebracht. Door de ontwikkeling van royaltymodellen als gevolg van vorderingen in digitale downloads zullen opbrengstenstromen direct getroffen worden. Order-to-cashprocessen, auteursrechten, de rol van de incassoagenten en thematiek omtrent piraterij bij content providers maken dat alle partijen in het proces kwetsbaar zijn voor het ‘lekken’ van opbrengsten en dat waardevol intellectueel eigendom onbeschermd blijft. Bestaande en toekomstige mediatechnologieën creëren veel nieuwe mogelijkheden. Een van de thema’s die zich voordoen is de wijze waarop in deze online-omgeving winstverhogingen gerealiseerd kunnen worden. Revenue assurance is daarom voor veel bedrijven een belangrijk thema.

Online-informatie – de toekomst is nu

Wat is online-informatie?

Online-informatie is informatie in digitale vorm die op elk gewenst moment beschikbaar is via internet, mobiele telefoon of een andersoortig netwerk – of het nu gaat om studieboeken, artikelen, handleidingen, gedichten, romans, thrillers, presentaties, strips, afbeeldingen, muziek, films of soapseries. Online-informatie kan vaak tegen een kleine vergoeding worden gedownload. De technische mogelijkheden van internet en mobiele netwerken zijn enorm uitgebreid en vrijwel onbeperkt. Samen met de diepgewortelde menselijke behoefte aan kennis, nieuws, achtergrondinformatie, muziek en allerlei vormen van entertainment zorgt deze technologische innovatie ervoor dat digitale content een enorm marktpotentieel heeft. Krachtige media maken digitale content bovendien toegankelijker en leiden waarschijnlijk tot een forse groei van de digitale content. De voorbeelden van deze nieuwe markten zijn talrijk. Zo is de verkoop van ringtones voor mobiele telefoons binnen enkele jaren uitgegroeid tot een miljardenbusiness. Internetgames en mobiele games zijn sterk in opmars. Het succes van iTunes leidt tot een revolutie in de muziekwereld. En op vele andere terreinen worden de mogelijkheden onderzocht. Zo worden voetbalwedstrijden uit de Champions League op internet aangeboden en is de eerste soap per sms al uitgezonden.

Uitbreiden van mogelijkheden

Met de opkomst van intelligente mobiele telefoons en hoogwaardige derdegeneratie mobiele netwerken (UMTS) zullen de mogelijkheden in de toekomst zich nog verder uitbreiden. Een groot aantal partijen is bezig met het maken van video- en muziekdiensten voor de mobiele telefoon. Zo is Real Networks van plan haar muziekdienst Rhapsody geschikt te maken voor de mobiele telefoon. De lancering zal plaatsvinden als er voldoende UMTS-toestellen in omloop zijn en de verwachting is dat er in 2008 meer dan een half miljard UMTS-toestellen zullen zijn. De mogelijkheden op het gebied van video op de mobiele telefoon worden ook onderzocht. In de Verenigde Staten zendt Verizon Wireless de populaire tv-serie ’24’ bijvoorbeeld al uit als miniserie op de mobiele telefoon. Een nieuw buzzword is daarmee geboren: de ‘mobisode’. Bovendien biedt de mobiele telefoon ook mogelijkheden voor het uitvoeren van kansspelen. Diverse partijen ontwikkelen daartoe initiatieven. Lange tijd was de online-verkoop van digitale content in veel sectoren vooral een grote belofte. Marktonderzoekers en -analisten voorzagen een grote groei en schetsten lucratieve vergezichten. De realisatie van die groeicijfers leek steeds opnieuw een jaar op te schuiven. Het lijkt erop dat we momenteel op een keerpunt zitten. De verkoop van digitale content – via internet en mobiele netwerken – neemt sterk toe en vormt in steeds meer sectoren reeds een substantieel deel van de opbrengsten.

Ontwikkelingen in de ICE-sector

Deze ontwikkeling tekent zich vooral af in de sector Information, Communication en Entertainment (ICE). Uitgevers ontwikkelen bedrijfsmodellen om opbrengsten te genereren uit digitale versies van papieren producten. Recent onderzoek van KPMG naar de uitgeverijbranche laat zien dat 62% van de uitgevers binnen twee jaar informatie waarvoor betaald moet worden via het internet wil gaan aanbieden. Op dit moment is dat nog 28%. Het EITO-rapport ([EITO05]) meldt: ‘veel van de opbrengsten van onlinecontent met betrekking tot consumenten komen van ‘uitgeverijen’. Voor het doel van het onderzoek is dit gedefinieerd als alle content die niet expliciet geclassificeerd is als muziek, video, games, d.w.z. content van een groot aantal genres dat vooral op beelden en tekst gebaseerd is’. Ook in de softwaresector genereren online-distributiekanalen steeds hogere opbrengsten. De online-distributie van bijvoorbeeld updates, plug-ins en add-ons is voor veel softwareleveranciers een onmisbaar element in de distributiemix geworden. In de telecomsector zorgen innovaties rond mobiele telefoons en mobiele netwerken voor compleet nieuwe bedrijfsactiviteiten, zoals de verkoop van ringtones, mobiele games en andere mobiele toepassingen, waaronder tv, loterijen en mobiele muziekdiensten. De opkomst van Triple Play, het gecombineerd aanbieden van televisie, telefonie en internet, zal zeker tot een bundeling van diensten en tot andere, complexere opbrengstmodellen leiden. In de strijd tegen de illegale verspreiding van digitale content heeft de muziekindustrie misschien wel het grootste belang bij revenue assurance. De legale online-muziekdistributie groeit razendsnel uit tot een volwaardige pijler naast de klassieke manier van distributie. Het succes van iPod en iTunes laat zien hoe groot het marktpotentieel is en dat terrein kan worden gewonnen op illegaliteit. De markt van betaalde muziekdownloads is het afgelopen jaar verdrievoudigd. Volgens onderzoek van de internationale organisatie van platenmaatschappijen, de IFPI, zijn de inkomsten uit downloaden wereldwijd gestegen van 380 miljoen naar 1,1 miljard dollar ([IFPI06]).

Het thema revenue assurance

Onder online digitale content wordt verstaan: het aanbieden van digitale informatie via het internet, mobiele netwerken of andersoortige netwerken, zonder dat hierbij een link is te leggen met een fysieke goederenstroom. Een online-internetwinkel waar de fysieke producten worden geleverd, valt dan ook buiten de reikwijdte van dit artikel. Onder revenue assurance wordt het ontwerpen, implementeren en onderhouden van een systeem van beheersingsmaatregelen verstaan om de organisatie voldoende vertrouwen in de betrouwbaarheid van de order-to-cashprocessen te geven teneinde meer winst te genereren. In het geval van online revenue assurance leiden downloads van digitale content tijdens het order-to-cashproces tot daadwerkelijke betalingen. De volledigheid van de opbrengsten is hierbij vanzelfsprekend van groot belang. Onder het order-to-cashproces vallen alle processtappen vanaf de initiële bestelling, het downloaden tot en met betaling en verantwoording hiervan in de financiële administratie van een organisatie. Het order-to-cashproces bestaat vaak uit een complex stelsel van vastleggingen, berekeningen en informatie-uitwisseling, waarbij veelal een groot aantal verschillende partijen en informatiesystemen betrokken zijn. Een bijzonder element in het geval van digitale content is het ontbreken van een fysieke productenstroom en fysiek contact met de klant. Traditionele methoden om de volledigheid van de opbrengsten te controleren, zijn daardoor ontoereikend. Elke organisatie die zich bezighoudt met de verkoop van digitale content via online-kanalen wordt met dit thema geconfronteerd. Een aanvullend probleem is dat digitale content nooit uitgeput raakt, maar keer op keer opnieuw kan worden verspreid zonder meerkosten, maar ook zonder meeropbrengsten. Door het gebruik van speciale technologie voor Digital Rights Management (DRM) kan een organisatie deze risico’s en opbrengsten beheersen door illegaal downloaden of kopiëren te voorkomen.

Een revenue-assurancemodel

Bij de verkoop van online digitale content zijn ten minste vier rollen voor de marktpartijen te onderscheiden: de klant, de distributeur, de uitgever en de contenteigenaar (zie figuur 1). Een uitgever kan bijvoorbeeld ook een ‘aggregator’ zijn, omdat een ‘aggregator’ het mogelijk maakt digitale muziekbestanden in het juiste format te zetten. In sommige gevallen kunnen meerdere rollen door één marktpartij worden vervuld. Andersom kan ook: meerdere marktpartijen oefenen één rol uit. Revenue assurance is derhalve van belang voor elke marktpartij.

C-2006-1-Wotte-1

Figuur 1. Vier rollen voor de marktpartijen bij de verkoop van online digitale content.

De volgende revenuemodellen zijn nu in de markt gangbaar:

  • een abonnement voor elke aansluiting met beperkt of onbeperkt gebruik;
  • een abonnement voor elke service met beperkt of onbeperkt gebruik;
  • een vast bedrag en pay-per-view/tik/click/download, etc.;
  • gratis content, soms ten behoeve van andere revenuestromen, zoals reclame-inkomsten;
  • een bundeling van abonnementen voor telefoon, kabeltelevisie en internet;
  • een variabel bedrag afhankelijk van de aard of het totaalbedrag van de transactie.

Het online aanbieden van digitale content impliceert in vrijwel alle gevallen een transformatie van het bedrijfsmodel en daarmee ook van de bedrijfsvoering en interne organisatie. Dit heeft gevolgen voor het proces waarmee digitale downloads worden omgezet in daadwerkelijke opbrengsten, het order-to-cashproces. Het doel van revenue assurance is het verkrijgen van zekerheid over de betrouwbaarheid van dit proces en daarmee het inzicht in of de organisatie alle opbrengsten krijgt waar zij recht op heeft. Revenue-assurancemodellen moeten op maat gemaakt worden om alle problemen van de verschillende opbrengstmodellen te kunnen oplossen.

Order-to-cashproces

De verkoop van online digitale content leidt tot betalingen in omgekeerde richting en tot samenwerking tussen diverse marktpartijen. Hierbij vormt het volume van de verkopen een belangrijke basis voor de verschillende stappen in het order-to-cashproces. In figuur 2 is de waardeketen van het order-to-cashproces weergegeven. Hoewel het lijkt alsof de betaling aan het einde van de waardeketen plaatsvindt, gebeurt dit eigenlijk direct na de bestelling en voor de levering.

C-2006-1-Wotte-2

Figuur 2. De waardeketen van het order-to-cashproces.

De beheersing ten behoeve van de revenue assurance dient in elke stap te zijn gewaarborgd. Maar wie weet precies hoeveel artikelen er de afgelopen week gedownload zijn? In de uitgeverswereld is de oplageverklaring een algemeen geaccepteerd begrip. Een onafhankelijke accountant verklaart hierbij dat de oplagecijfers – die onder meer worden gebruikt bij het calculeren van advertentietarieven – betrouwbaar zijn. In de wereld van digitale content wordt weinig gebruikgemaakt van onafhankelijke controle en verklaringen. Partijen zijn nog steeds grotendeels afhankelijk van de informatie die door de distributeur van de content wordt verstrekt. Dit fenomeen wordt ‘self-reporting’ genoemd ([KPMG04]). Bij de verkoop van digitale content bestaat geen fysieke goederenbeweging. Om de opbrengsten uit digitale content te beheersen zijn dan ook meer geavanceerde concepten en systemen nodig, waarbij informatietechnologie een belangrijke rol speelt. Zo is revenue assurance bijvoorbeeld in grote mate afhankelijk van goede beheersingsmaatregelen met betrekking tot het proces omtrent het verlenen van toegang tot digitale content aan gebruikers en van adequate facturerings- en incassoprocedures. Dit stelt hogere eisen aan de organisatie en vergt extra aandacht om de volledigheid van opbrengsten te waarborgen en ongeautoriseerd gebruik te voorkomen.

Gehouden Revenue Assurance Onderzoek

Het thema revenue assurance van online digitale content krijgt bij veel organisaties nog maar beperkte aandacht. Naarmate de online-activiteiten zich verder zullen ontwikkelen, zal ook revenue assurance in de toekomst hoger op de agenda komen te staan. Teneinde de huidige situatie in kaart te brengen, heeft KPMG een kort onderzoek uitgevoerd. Hierbij zijn diepte-interviews gehouden met tien organisaties die actief zijn op het gebied van online digitale content. Bij het onderzoek stonden de volgende vragen centraal:

  • Hoe hebben organisaties die online digitale content verkopen het order-to-cashproces ingericht?
  • Hoe beheersen die organisaties de volledigheid van hun opbrengsten en hoe verkrijgen zij voldoende zekerheid over de volledigheid van de opbrengsten?
  • Hoe implementeren en beheersen organisaties het order-to-cashproces en hoe verkrijgen zij zekerheid over de opbrengsten?
  • Hoe beïnvloedt de verkoop van online digitale content de bedrijfsmodellen van organisaties?

De bevindingen van de interviews met medewerkers van tien verschillende organisaties in vijf verschillende sectoren (software, muziek, mobiele telefonie, uitgeverij en digitale tv) die verantwoordelijk zijn voor de revenue-assuranceactiviteiten, werden samengevoegd met de kennis en praktische ervaring van specialisten van verschillende KPMG-business units. Daarnaast is bij het onderzoek gebruikgemaakt van openbare bronnen. Dit artikel geeft een samenvatting van de resultaten van het onderzoek.

Bevindingen

De markt voor online digitale content kent een breed scala aan producten en diensten. Juist omdat er zo veel verschillen zijn in bijvoorbeeld de aard van het digitale product, de volwassenheid van de business, de historie en de omvang van de betrokken organisaties, zijn er ook grote verschillen in de manier waarop met revenu assurance wordt omgegaan. Door de markt te segmenteren naar contenttype wordt inzicht verkregen in de belangrijkste kenmerken en risico’s. De belangrijkste bevindingen worden hieronder per contenttype beschreven.

Software

In de softwaresector is online digitale content al jaren gemeengoed. Grote softwareleveranciers als Microsoft, Oracle en Symantec zijn in hoge mate afhankelijk van internet voor het verlenen van toegang tot patches, nieuwe releases en updates. De klant betaalt hiervoor doorgaans via zijn licentie. Het downloaden van software is alleen mogelijk na het invoeren van sleutels die pas geactiveerd zijn nadat de licentie is verstrekt. Digital Rights Management (DRM)-technologie om illegale verspreiding te voorkomen, wordt hierbij niet altijd toegepast. DRM-technologie maakt het mogelijk om met behulp van speciaal vervaardigde technieken de toegang tot de content – of het nu gaat om tekst, muziek of games – te controleren. Individuele sleutels voor het gebruik van de content worden geleverd aan een eindgebruiker die rechten heeft gekocht. Dit houdt over het algemeen in dat er beperkingen zijn met betrekking tot kopiëren en herdistributie. Een nieuwe ontwikkeling is het spelen van games via internet. Populaire sites zoals Runescape maken het mogelijk de basisvariant van een game gratis te spelen. Voor een meer geavanceerde versie moet een bescheiden bedrag worden betaald.

Pragmatische aanpak bij jonge bedrijven

De mate van zekerheid over de volledigheid van de opbrengsten van deze vorm van online digitale content varieert sterk van organisatie tot organisatie. Het order-to-cashproces van jonge, startende bedrijven is pragmatisch en nog niet goed ingericht. Deze pragmatische aanpak is vaak een bewuste keuze. Vanwege het relatief lage volume van transacties en de noodzaak snel marktaandeel te verwerven en/of de kosten laag te houden worden de risico’s die deze aanpak met zich meebrengt aanvaardbaar geacht. De meer volwassen bedrijven willen wel investeren in zekerheid die door een onafhankelijke accountant kan worden verkregen, omdat de extra opbrengsten van een dergelijke dienst (bijvoorbeeld de SAS 70-verklaring of een externe audit) direct zichtbaar zijn en hun marktaandeel gewaarborgd zal worden doordat het illegaal verspreiden van software actief wordt bestreden.

Muziek

Ten behoeve van de online-verkoop van muziekbestanden stellen platenmaatschappijen hun muziekcatalogi aan bedrijfspartners beschikbaar. De muziekbestanden worden daarbij daadwerkelijk ‘fysiek’ op een ander platform geplaatst en de eindgebruiker kan ze daar tegen betaling downloaden. Elk muziekbestand heeft verschillende rechthebbenden aan wie royalty’s moeten worden afgedragen. Zo heeft bijna elk nummer een componist, tekstschrijver, uitgever, producent en uitvoerend artiest. Deze licenties worden door verschillende partijen in de muziekindustrie beheerd. Het eerdergenoemde EITO-rapport zegt het volgende over online-muziek: ‘In West-Europa zijn legale online-muziekdiensten pas recentelijk opgezet en ze hebben geschatte opbrengsten van minder dan EUR 4 miljoen in 2003. Naar schatting is slechts 5% van alle downloads in 2004 legaal (een stijging van 1% in vergelijking met 2003). Het jaar 2004 wordt echter gezien als het jaar van de doorbraak van online-muziek in West-Europa en voor 2005 wordt een grote groei verwacht.’ Verder meldt het rapport: ‘In 2004 is het aantal diensten meer dan verdrievoudigd en verwacht wordt dat in 2005 een aanzienlijk aantal diensten zal worden gelanceerd.’ Deze aanpak zorgt ervoor dat zij voor hun opbrengsten afhankelijk zijn van een aantal zaken. De rechthebbenden zijn afhankelijk van de goede trouw van hun zakenpartners en de betrouwbare werking van hun systemen. De contracten voorzien vaak wel in de mogelijkheid om systemen door te lichten, maar in de praktijk gebeurt dat nauwelijks. Insiders verwachten dat hier een behoorlijke ‘lekkage’ van opbrengsten plaatsvindt. In de digitale wereld vervagen landsgrenzen en ontbreekt een enkel punt of een enkele instantie die alle rechthebbenden, onder wie de oorspronkelijke producent en de uitvoerend artiest, vertegenwoordigt.

Self-reportingverhoudingen in de traditionele economie

Ook in de traditionele economie zijn tal van dergelijke self-reportingverhoudingen terug te vinden. Een internationaal onderzoek van KPMG liet zien dat deze self-reportingeconomie lekkages van tussen de zes en zeven procent kent. In de traditionele economie – dat wil zeggen verkopen onder licentie – is het gebruikelijk om door middel van (externe) audits zekerheid over opbrengsten te krijgen. De kosten van die audits worden meestal ruimschoots terugverdiend in de vorm van extra opbrengsten. Als begunstigden zoeken platenmaatschappijen dan ook naar manieren om deze afhankelijkheid te verminderen en om de revenue assurance te verbeteren. Eén van de alternatieven is om de originele muziekbestanden niet langer ‘fysiek’ over te dragen, maar op de eigen server van het bedrijf te plaatsen. De downloads vinden dan plaats door middel van een interface met het platform van de zakenpartner. De gebruiker merkt geen verschil, maar de platenmaatschappij heeft zelf directe controle over de downloads. Tegelijkertijd zullen de uiteindelijke begunstigden druk uitoefenen op platenmaatschappijen ten aanzien van hun afhankelijkheden. Een ander alternatief is om actiever en gerichter externe audits uit te voeren. Op dit moment gebeurt dat nog nauwelijks. Omdat het een kleine wereld is, weten partijen onderling overigens goed welke partijen wel en niet betrouwbaar zijn. Meer in het algemeen lijkt de technologie zich sneller te ontwikkelen dan de governancestructuren die daaraan ten grondslag liggen. De bedrijfsmodellen, contractuele afspraken en IT-infrastructuren zijn vaak in korte tijd ontwikkeld. In de toekomst kunnen culturen botsen als de contenteigenaars meer behoefte hebben aan zekerheid over de verkoop van hun content op andere platformen. Ze kunnen dan in het begin op weerstand van hun zakenpartners stuiten.

Veel aandacht voor DRM

Digital Rights Management is een onderwerp dat binnen de muziek- en filmindustrie op veel aandacht mag rekenen. De betrokken partijen doen er alles aan om hun content te beschermen tegen kopiëren en/of misbruik. Daarom hebben ze onder meer DRM-technologie ontwikkeld waarmee het mogelijk wordt om de speelduur te beperken, kopiëren te voorkomen, etc.

Mobiel entertainment

Het bewustzijn van de noodzaak van revenue assurance voor mobiele gaming of ringtones is laag. Bij mobiele gaming of ringtones gaat het vaak om jonge, kleine bedrijven die flexibel kunnen inspelen op marktveranderingen en technologische innovaties. Enkele jaren geleden werd de markt overspoeld door kleine partijen die snel geld wilden verdienen en vaak ook even snel weer verdwenen. Deze categorie is voor een groot deel vertrokken of ter ziele gegaan en de sector heeft daarmee stabiele trekjes gekregen. Het controlebewustzijn is bij dit contenttype echter vaak nog laag. De oorzaak hiervan is dat kleine bedrijven ‘dicht op de business’ zitten en denken dat ze daarmee een beeld hebben van de volledigheid van de opbrengsten. In veel gevallen zijn systemen waarin downloads en billing worden geregistreerd nog nooit kritisch beoordeeld op hun betrouwbare werking. Bij grotere bedrijven, die naast digitale mobiele producten en diensten ook de traditionele producten en diensten leveren, heeft het lagere controlebewustzijn een andere oorzaak. De opbrengstenstromen die zij uit digitale content genereren, zijn vaak marginaal op het totaal van hun activiteiten. Deze ‘incidentele opbrengsten’ worden gezien als een welkome aanvulling op de traditionele activiteiten, waarvoor aandacht voor controle minder noodzakelijk wordt geacht.

Redelijk onaantastbare status van telco’s

Binnen de samenwerkingsverbanden voor het verkopen van mobiele content bestaan onderlinge afhankelijkheden ten aanzien van de opbrengstenbeheersing. In een aantal gevallen zit er tussen de telco (het telefoniebedrijf) en de contenteigenaar een zogeheten aggregator ofwel tussenpersoon. Deze organisatie maakt het technisch mogelijk dat de mobiele content wordt verzonden. Dergelijke aggregators geven hun zakenpartners vaak wel inzicht in de systemen door middel van een directe interface en bieden in contracten ook de mogelijkheid om de systemen door te lichten om te beoordelen of de opgaven kloppen. Van dergelijke mogelijkheden wordt – zowel bij de telco’s als bij de aggregators – nauwelijks gebruikgemaakt. Dat heeft te maken met de relatief kleine omvang van de stromen, maar is voor een groot deel ook cultureel bepaald. Telco’s zouden dergelijke audits immers als een vertrouwensbreuk kunnen ervaren. Daarnaast is het controlebewustzijn in de entertainmentsector over het algemeen niet zo sterk. Het gaat vooral om goed vertrouwen en systeemaudits worden nauwelijks uitgevoerd. Binnen de samenwerkingsverbanden zijn de telco’s verantwoordelijk voor de primaire registratie. Zij registreren immers de premium-SMS die dient als betaling voor de mobiele content. Zij lijken daarbij echter een redelijk onaantastbare status te hebben, die ze hoofdzakelijk ontlenen aan hun omvang. De vaak kleinere samenwerkingspartners vertrouwen erop dat de opgaven van de telco kloppen en voeren vaak alleen maar globale cijferanalyses uit. Het paradoxale van het geval is dat telco’s van hun toeleveranciers zelf wel eisen dat ze de systemen mogen onderzoeken. Steeds meer telco’s besteden bepaalde activiteiten uit en vragen daarbij van de serviceorganisatie een verklaring – SAS 70 of anderszins – over de betrouwbare uitvoering van deze activiteiten.

Voorsprong op gebied van revenue assurance

Telco’s hebben de afgelopen jaren geïnvesteerd in het opzetten van revenue assurance. Dat zorgt ervoor dat ze ook ten aanzien van nieuwe vormen van dienstverlening een voorsprong hebben. Hun bedrijfsvoering is van oorsprong al gericht op het meten en factureren van niet-fysieke diensten: telefoonunits (of tikken). Nu daar digitale content aan wordt toegevoegd, hoeft de bedrijfsvoering niet op zijn kop. Voorts zijn er geen interne discussies nodig over kannibalisatie van hun traditionele bedrijfsactiviteiten door online-content. In principe is bij telco’s de opbrengstenbeheersing van online-content immers nauwelijks anders dan die van reguliere telefoontikken tegen verschillende tarieven. Het gaat om afstemmingen tussen brongegevens (downloads, belminuten) en de factureringssystemen. De telco’s zijn gewend aan deze meer complexe opbrengstenmodellen en hebben in het verleden al grote investeringen gedaan om revenue assurance te waarborgen. Desalniettemin blijven zij veel aandacht besteden aan dit cruciale beheersingssysteem. Voor andere partijen die online digitale content verspreiden, kan de kennis en ervaring van telco’s van grote waarde zijn voor het opzetten van revenue-assurancesystemen.

Diffuus beeld van geldstromen

Om mobiel entertainment van de grond te krijgen, zijn er tal van strategische allianties en gelegenheidscoalities gesmeed. Contenteigenaren, integrators, aggregators, dienstverleners en operators moeten elkaar vinden in samenwerkingsconstructies. Op dit moment is het beeld van de rechten en plichten in samenwerkingsconstructies vaak nog diffuus en het is daarmee ook onduidelijk hoe de geldstromen precies moeten worden verdeeld. Juist in de veelheid van verschillende afspraken is het lastig om goed het overzicht te houden. Voor een telco is één van de belangrijkste checks en balances om met grote regelmaat alle bedrijfsrichtlijnen – de parameters in het systeem die bepalen hoe de verschillende producten en diensten worden afgerekend – te controleren. Een duidelijk probleem ontstaat bij de afdracht van royalty’s over mobiele content, zoals bijvoorbeeld ringtones. De licentiegevers van de verschillende rechthebbenden hanteren elk hun eigen tarieven. De uiteindelijke distributeur probeert deze afdrachten op verschillende manieren te beperken. Soms worden bijvoorbeeld in plaats van het originele muziekstuk zogenaamde covertones opgenomen in een studio, in een poging om geen rechten af te dragen aan de oorspronkelijke producent en de uitvoerend artiest. De muziekindustrie loopt hierdoor naar schatting jaarlijks vele miljoenen euro’s aan rechten mis. Dit is één van de redenen dat platenmaatschappijen steeds vaker rechtstreekse deals over mobiele content willen sluiten met telco’s.

Bedrijfs- en consumenteninformatie

Business intelligence-informatie wordt door een aantal partijen al jarenlang digitaal afgezet. Sommige partijen hebben hun revenue assurance reeds lang op orde; bij andere staat dit nog in de kinderschoenen. In deze markt bestaat dan ook een gemengd beeld. De bedrijfsmodellen zijn bij de voorlopers in deze markt goed uitgekristalliseerd en de tijden van explosieve groei liggen achter hen. Deze partijen zijn dan ook vooral bezig met consolidatie en het vinden van nieuwe groeimarkten. Een volwassen houding ten opzichte van revenue assurance is hier van toepassing, waarbij veel aandacht naar betrouwbare systemen en bedrijfsbeheersmaatregelen uitgaat. Voor deze organisaties leidt deze houding ook tot een professionele noodzaak voor het verkrijgen van zekerheid bij de zakenpartners (d.w.z. een SAS 70-verklaring of een externe audit), vooral in gevallen waarin de contenteigenaar en distributeur aparte organisaties zijn. Sommige partijen worstelen nog met de bepaling van de juiste opbrengstenmodellen wanneer digitale content in combinatie met bijvoorbeeld een traditioneel abonnement wordt aangeboden en/of een vaste prijs of een variabele prijs voor beperkt of onbeperkt gebruik moet worden gehanteerd. In de wetenschappelijke informatie zijn vorig jaar initiatieven ontwikkeld waarbij de auteur voor distributie zou betalen en waarbij de gebruiker de content gratis zou kunnen raadplegen. Dit voegt weer een nieuwe dimensie aan het thema toe.

Weinig interesse in DRM

DRM-technologie krijgt weinig interesse onder de verspreiders van bedrijfsinformatie, terwijl deze technologie wel degelijk toegevoegde waarde kan hebben. Waarschijnlijk laten partijen hier kansen liggen om hun opbrengsten te vergroten of om uitholling van bestaande opbrengsten te voorkomen.

Moeizame omvorming naar digitale dienstverlening

Een uitgever die vroeger alleen boeken en tijdschriften verkocht en nu manieren ontwikkelt om digitale content te gelde te maken, moet daartoe fundamentele keuzen maken ten aanzien van zijn organisatie en bedrijfsvoering. In sommige gevallen wordt het online-kanaal ‘ingevlochten’ in de traditionele systemen en processen. Dat levert nogal eens problemen op, omdat deze systemen en processen oorspronkelijk zijn bedoeld voor de traditionele activiteiten. In het order-to-cashproces zijn er dan ook veel risico’s die ertoe kunnen leiden dat de volledigheid van opbrengsten niet is gewaarborgd. Naast bovengenoemd thema worstelen de uitgevers ook met hun prijsstelling. Slechts een beperkt aantal uitgevers (minder dan drie procent van de uitgevers van dagbladen in de Verenigde Staten, waaronder de Wall Street Journal) vraagt een aparte betaling voor een online-editie van de krant. De meeste uitgevers bieden een gratis digitale versie van de krant aan. Andere uitgevers laten de consument voor bepaalde delen van de digitale krant, bijvoorbeeld kruiswoordpuzzels, nieuwsrubrieken of achtergrondinformatie, betalen. Het gaat de uitgevers niet alleen om de opbrengsten die met de digitale verspreiding binnenkomen, maar ook om de klantenbinding, waardoor de digitale krant een wapen in de strijd is om de neergang van de gedrukte exemplaren af te remmen.

Digitale tv en andere streaming media

De markt voor digitale tv en andere streaming media is relatief jong en verschillende nieuwe initiatieven doen zich voor. In de Verenigde Staten kunnen televisiekijkers door middel van TiVo zelf bepalen wanneer zij hun favoriete tv-programma’s of tv-fragmenten willen zien. Broadbanddienstverleners zoals telco’s, kabelmaatschappijen en ISP’s controleren de toegang tot een snelgroeiende basis van hogesnelheidinternet-homes. Broadband is een belangrijk element in multiservicebundelingplannen, maar kan ook de huidige bedrijfsactiviteiten zoals telefonie of video ontwrichten. De afhankelijkheid van zakenpartners bij het innen van opbrengsten is tegenwoordig laag en er is geen noodzaak voor zekerheid (bijvoorbeeld een SAS 70-verklaring of een externe audit). Maar de rol van tv verandert en andere methoden om opbrengsten te genereren met tv-formats waarin SMS en mobiele content geïntegreerd worden, dienen zich aan. Dit zal leiden tot complexere opbrengstenstromen waarbij meer partijen betrokken zijn en daardoor zullen geavanceerde revenue-assurancemodellen een belangrijke rol gaan spelen. Het eerdergenoemde EITO-rapport merkt hierover op: ‘Over het algemeen zijn traditionele contentbedrijven, zoals omroepbedrijven en platenmaatschappijen, behoudend ten aanzien van nieuwe modellen en innovatieve technologieën en zien zij belangrijke wijzigingen in de huidige modellen alleen op lange termijn als mogelijk.’ Verder noemt het rapport: ‘Hoewel de huidige gevestigde partijen liever een langzame verandering zien, is er in West-Europa al duidelijk een verschuiving gaande van traditionele offline-contentdistributie naar online als een dominant kanaal. Maar de groei zal zich ook na dit decennium voortzetten en de bedrijfstak kan binnen tien jaar een totaal andere vorm hebben aangenomen.’

Transparantie en betrouwbaarheid zijn belangrijke thema’s voor het bedrijfsleven. Steeds meer organisaties moeten ervoor zorgen dat ze voldoen aan de eisen van wet- en regelgeving, zoals Sarbanes-Oxley en Tabaksblat, onder meer door het inrichten en onderhouden van een goed stelsel van interne beheersing. Dit geldt uiteraard ook voor revenue assurance, omdat volledigheid van de opbrengsten als één van de belangrijkste bedrijfsuitdagingen in de digitale wereld wordt gezien. Daarbij moeten organisaties echter niet uitgaan van de filosofie dat beheersing slechts een wettelijke plicht is. Een betere aanpak is om te handelen in het belang van de organisatie: als gevolg van een goede interne beheersing verdient een organisatie meer geld en interne beheersing is essentieel voor het versterken van de concurrentiepositie.

Revenue assurance onmisbaar onderdeel

Revenue assurance van het order-to-cashproces dat gericht is op online digitale content vormt een onmisbaar onderdeel van deze beheersing. Het is duidelijk dat de markt voorlopig nog een grote dynamiek zal laten zien als gevolg van de nieuwe opbrengstenstromen die voortvloeien uit digitale content. Het is voor bedrijven verstandig om vooral in te spelen op de actuele trends en contracten met samenwerkingspartners af te sluiten. Bestaande marktpartijen zullen delen van de waardeketen die zij niet tot hun kerntaak rekenen afstoten, terwijl nieuwe internationale partijen delen van de waardeketen zullen zien te verkrijgen. Een consolidatie rondom specifieke functies, bijvoorbeeld rondom subprocessen voor bestelling, distributie, incasso en/of omzetting van digitale content, zal leiden tot nieuwe schaalvergrotingen. Dergelijke functionele partijen kunnen, indien zij een hoge kwaliteit leveren, een groot marktaandeel verwerven waardoor andere partijen bestedingen per definitie moeten (her)overwegen. Veranderingen van die aard leiden tot complexe sourcing- en beheersingsvraagstukken rondom het proces en de organisatie van beheerste revenue assurance van digitale content. Revenue assurance van digitale content kan en moet de komende jaren verbeteren. Als opbrengstenstromen gaan toenemen en meer partijen betrokken zijn, zal de behoefte aan zekerheid bij de verschillende marktpartijen toenemen. Allereerst natuurlijk bij de uiteindelijke exploitant van de digitale content. Deze exploitant heeft een direct belang bij revenue assurance. Hij zal derhalve een revenue-assurancemodel moeten implementeren en onderhouden waarbij de volledigheid van de opbrengsten voortdurend gewaarborgd is.

Conclusie

De verkoop van online-informatie is sterk stijgende, maar de betrokken partijen besteden in hun stormloop op deze snelgroeiende markt nog maar weinig aandacht aan de volledigheid van de hieruit voortvloeiende opbrengsten. Zij vertrouwen sterk op self-reporting als basis voor het vaststellen van de opbrengsten. Het is vrijwel zeker dat hierdoor opbrengsten verloren gaan. Door reeds in een vroeg stadium aandacht te besteden aan het inrichten van controls om de volledigheid van de opbrengsten te waarborgen (revenue assurance) kunnen partijen ervoor zorgen dat scheefgroei wordt voorkomen en onnodige verliezen niet in hetzelfde tempo groeien als de markt zelf. Ook voor revenue assurance voor online-informatie geldt: get it right the first time.

Visie van de auteurs

De verschillende rechthebbenden hebben belang bij revenue assurance. De exploitant zal willen aantonen dat hij over betrouwbare systemen beschikt op basis waarvan de self-reportingafdrachten zijn bepaald. In een aantal gevallen zal de exploitant dit willen onderstrepen met een zogenaamde SAS 70-verklaring waarbij een externe accountant de goede werking van de systemen en beheersingsmaatregelen daarbinnen bevestigt. In steeds meer gevallen zullen de rechthebbenden gebruikmaken van hun recht om de volledige ontvangst van opbrengsten te onderzoeken. Een gangbare manier om zekerheid te krijgen, is het laten uitvoeren van externe audits. Waar goed vertrouwen nu in de onderlinge self-reportingrelaties de boventoon voert, zullen audits daarvoor straks in de plaats komen. Bedrijven en sectoren kunnen op dit punt van elkaar leren door best practices te delen. Zoals eerder aangegeven, kunnen de ervaringen van telco’s hierbij als voorbeeld worden genomen. Dat veranderingen in een branche tot desastreuze problemen in de revenue assurance en daarmee in de afrekeningen met klanten kunnen leiden, bewijst de publiciteit rondom afrekeningen en klachten bij kabelmaatschappijen en gas- en elektriciteitsbedrijven. Het is daarom naar ons oordeel van het grootste belang om tijdig en met voldoende aandacht te werken aan goede revenue-assurancesystemen. Hiermee is niet alleen de opbrengstkant gediend, maar kunnen ook negatieve publiciteit en talrijke klachtenprocedures worden voorkomen. Met relatief kleine inspanningen zijn naar onze mening grote verbeteringen te realiseren.

Literatuur

[EITO05] European Information Technology Observatory (EITO)-rapport, 2005.

[IFPI06] IFPI, Digital Music Report, 2006.

[KPMG04] KPMG Intellectual Property Services, The Self-Reporting Economy: ‘a Matter of Transparency and Trust’, 2004.

Trends in IT en IT-auditing

Technologische ontwikkelingen en trends kunnen substantiële impact op de maatschappij of een branche hebben. Op hun beurt leiden (technologische) ontwikkelingen tot ontwikkelingen op andere gebieden. IT-trends beïnvloeden en geven verdere richting en invulling aan de wijze waarop het vakgebied IT-auditing zich in de komende jaren zal ontwikkelen.

Inleiding

Wat is eigenlijk een trend? In de Van Dale wordt een trend omschreven als ‘een richting waarin zich iets ontwikkelt’. In het dagelijkse spraakgebruik staat de term trend ongeveer gelijk aan elke nieuwe ontwikkeling. Een trend is een belofte. Wordt de belofte niet ingelost, dan spreken we van een hype. Een trend die, na verloop van tijd, zijn belofte inlost, wordt een algemeen gebruikte toepassing.

In een wereld waarin de technologische ontwikkelingen elkaar steeds sneller opvolgen en het steeds moeilijker wordt om te voorspellen welke technologieën gaan doorbreken, is het allereerst van belang om inzicht te hebben in de belangrijkste technologische ontwikkelingen en doorbraken. Deze ontwikkelingen en doorbraken kunnen substantiële impact op de maatschappij of een branche hebben. Op hun beurt leiden (technologische) ontwikkelingen tot ontwikkelingen op andere gebieden. IT-trends beïnvloeden en geven verdere richting en invulling aan de wijze waarop het vakgebied IT-auditing zich in de komende jaren zal ontwikkelen.

In dit artikel wordt een kort overzicht gegeven van de trends in IT en IT-auditing. Het artikel is voor een belangrijk deel gebaseerd op de publicatie Trends in IT 2005|2006 van het Business & IT Trends Institute.

Kader 1. 4R’en-model (bron: Trends in IT 2004|2005, Business & IT Trends Institute).

Trends herkennen

Om te bepalen of een ontwikkeling een trend of een hype wordt, kan een aantal criteria worden gehanteerd waarmee zo vroeg mogelijk zekerheid kan worden verkregen of een ontwikkeling een investering waard is. Het 4R’en-model is een cyclisch model dat zich beweegt van Research en Rumours richting leveranciers/producten (Resources) en van daaruit naar concrete toepassing in de praktijk: Ready for business.

C-2006-1-Rutkens-01

Figuur 1. 4R’en-model.

De vier R-factoren beïnvloeden elkaar continu. De ene trend is bijvoorbeeld een enabler voor een volgende. De betekenis van de 4R’en is als volgt:

Research: wordt er door de overheid, grote organisaties, universiteiten of onderzoeksinstituten geld gestoken in de verdere ontwikkeling van een trend?

Rumours: wordt de trend door gerenommeerde onderzoeksinstituten en marktonderzoekbureaus gevolgd en/of zijn er veel publicaties in gerenommeerde vakbladen?

Resources: wordt de trend via producten/diensten door een betrouwbare en bekende leverancier op de markt gezet en/of worden er opleidingen, cursussen en workshops over de trend aangeboden via gerenommeerde opleidingscentra?

Ready for business: bestaan er concrete toepassingen van de trend in de praktijk, is de trend echt nieuw of slechts ‘oude wijn in nieuwe zakken’, is de trend ‘op tijd’ (timing) en/of is er een concrete behoefte aan de trend?

Trends in IT

De laatste jaren is er een duidelijke kentering zichtbaar in de IT. Na het aanvankelijke primaat van de techniek gaat nu steeds meer de inhoud de boventoon voeren. Het gaat erom met behulp van techniek innovatieve concepten te ontwikkelen met toegevoegde waarde voor de organisatie. We zien dit terug in de ontwikkelingen waarlangs IT-trends zich grofweg bewegen. Uit empirisch onderzoek blijkt een drietal ontwikkelingen:

Ten eerste stelt de technologie ons in staat steeds meer tijd- en plaatsonafhankelijk te werken. We zijn niet meer gebonden aan een pc maar kunnen via allerlei apparaten informatie benaderen en diensten afnemen. Dit wordt ook wel pervasive computing genoemd. Overigens schetsten diverse leveranciers, waaronder IBM, eind jaren negentig al een beeld van een dergelijke toekomst. In het Thomas J. Watson researchcentrum van IBM werd toen al onderzoek gedaan met allerlei huishoudelijke apparaten die voorzien van een chip met de buitenwereld konden communiceren. Op een nieuwjaarsbijeenkomst van IBM in 1998 werd verteld dat door een koelkast en de producten in deze koelkast te voorzien van chips, het mogelijk is om de koelkast via bijvoorbeeld het elektriciteitsnetwerk een boodschappenlijst te laten doorgeven aan de supermarkt. Ook nu nog geven diverse gerenommeerde leveranciers hun beeld van ‘de huiskamer van de toekomst’ of de toekomst van een bepaalde branche. Kijk bijvoorbeeld maar eens op de website van Microsoft.

Diverse (combinaties van) technologieën zoals Global Positioning System (GPS), Wireless Fidelity (Wi-Fi), GPRS/UMTS, intelligent agents, spraakherkenning en interactieve beeldschermen maken pervasive computing mogelijk. Het meest sprekende voorbeeld van pervasive computing op dit moment is waarschijnlijk de BlackBerry, een gecombineerde mobiele telefoon/organizer. De BlackBerry zal op korte termijn worden vervangen door zogenaamde Windows Smartphones. Deze telefoon kan in de auto dienen als navigatiesysteem en multimediaspeler en stelt ons met behulp van spraakherkenning in staat te reageren op ontvangen voice- en e-mailberichten. Daarnaast kan de ‘smartphone’ op een intelligente manier uw agenda bewaken en op basis van bepaalde voorkeursinstellingen nieuwsberichten voorlezen. Verder is de verwachting dat het gebruik van spraak- en videotoepassingen, bijvoorbeeld in het onderwijs, via datanetwerken de komende jaren verder zal toenemen. Een belangrijke randvoorwaarde voor de verdere ontwikkeling van pervasive computing is een goedkoop, breedbandig (internationaal) en ‘roaming’ draadloos netwerk.

Een tweede ontwikkeling waarlangs IT-trends zich bewegen is dat IT-toepassingen steeds meer gericht zijn op proces- en ketenintegratie. De technologie stelt ons steeds beter in staat informatie en diensten geautomatiseerd uit te wisselen tussen de processen binnen en tussen organisaties. Service Oriented Architectures (SOA), op XML gebaseerde technologietoepassingen (webservices) en zogeheten middlewarebussen maken het mogelijk (keten)integratie (met bestaande systemen) te realiseren. Daarnaast wordt steeds meer ketengeoriënteerde software ingezet, zoals ERP-software en portals om processen door organisaties heen beter op elkaar af te stemmen. In de zorg bijvoorbeeld wordt de volledige beschikbaarheid en efficiënte uitwisseling van informatie door middel van een basis ICT-infrastructuur en een landelijk Elektronisch Patiënten Dossier nagestreefd. Hiertoe wordt een gemeenschappelijke basisinfrastructuur gerealiseerd. Deze basisinfrastructuur omvat de gedeelde ICT-voorzieningen die nodig zijn om de individuele ICT-voorzieningen van verschillende zorgpartijen (zorgverleners, zorgverzekeraars, etc.) onderling te kunnen koppelen voor transmuraal gegevensverkeer. De inzet van SOA, XML en middleware speelt hierbij een belangrijke rol. Op zich is de gedachte van proces- en ketenintegratie natuurlijk niet nieuw. Enkele jaren geleden werd met objectoriëntatie en objectgeoriënteerd programmeren hetzelfde nagestreefd. Doordat processturing, procesoptimalisatie en ketenintegratie eindelijk volwassen beginnen te worden is de verwachting dat deze ontwikkelingen zich de komende jaren verder doorzetten.

De derde ontwikkeling ten slotte waarlangs IT-trends zich bewegen is de steeds verder toenemende (maatschappelijke) gerichtheid op informatie en het belang van betere en transparante informatie. De boekhoudschandalen (Enron, Ahold, Parmalat) waarmee de wereld is geconfronteerd, hebben hier zeker hun steentje aan bijgedragen. De roep om betrouwbare informatie kan worden gezien als één van de belangrijkste triggers voor IT-investeringen in de komende jaren. De technologieën zijn al beschikbaar, al blijven het aantal gigabytes en de bandbreedte een uitdaging. Een ander lastig vraagstuk in dit verband is het feit dat dezelfde gegevens vaak op verschillende plekken op niet-uniforme wijze worden geregistreerd. Binnen de (lokale) overheid worden hierom zogeheten authentieke bronregistraties opgezet zoals de gemeentelijke bevolkings- en vastgoedadministraties.

De gevolgen van de hierboven genoemde ontwikkelingen en trends zijn verschillend. Behalve dat het voor organisaties economisch steeds noodzakelijker wordt om gelijksoortige werkzaamheden vanuit efficiencyvoordelen te concentreren, wordt deze ontwikkeling door de technologie versterkt. Doordat informatie en diensten op elk moment via allerlei slimme randapparaten te benaderen zijn maakt het niet meer uit waar het werk wordt uitgevoerd. In dit verband staat het shared service center (SSC) al enige jaren in de belangstelling.

In het verlengde hiervan zien we dat organisaties vanuit proces- en ketenintegratie gedwongen worden om zich verder te positioneren in de keten en op zoek gaan naar hun kracht maar ook naar hun zwakte in deze keten. Deze ontwikkeling dwingt een organisatie na te denken over haar ‘kerncompetentie’. In dit kader zijn organisaties steeds meer bezig om delen van het eigen primaire proces onder te brengen bij andere partijen. Dit is een speciale vorm van outsourcing, business process outsourcing (BPO).

Kader 2. IT-trends.

De bekendheid van IT-trends

Door het Business & IT Trends Institute is onderzocht in welke mate IT-trends en ontwikkelingen binnen Nederlandse organisaties bekend zijn. Het resultaat is weergegeven in figuur 2. Wat opvalt is de groei van de mate van bekendheid van business intelligence (en datawarehouse). Dit is wellicht te danken aan de relevantie van deze trend in het kader van de toenemende aandacht voor (financiële) transparantie en rapportage. Opvallend is de gemiddelde stijging van de bekendheid van de huidige trends zoals .Net, Bluetooth, XML en portals. Deze zijn bekend bij meer dan 70% van de respondenten. Dit geldt niet voor de trends Enterprise Allocation Integration (EAI), J2EE, Professional Service Automation (PSA) en Voice over Internet Protocol (VoIP). Een oorzaak voor de lage bekendheid van PSA is wellicht dat PSA veelal als een module van ERP-pakketten wordt aangeboden. Wel zijn er diverse best-of-breed-pakketten op dit gebied terug te vinden. VoIP lijkt in tegenstelling tot voorgaande jaren nu snel aan bekendheid te winnen. Hoewel deze technologie al geruime tijd bestaat en door diverse kabelaars wordt aangeboden, lijkt hier niet gretig gebruik van te worden gemaakt. ERP en e-business lijken de top qua mate van bekendheid te zijn gepasseerd. De afname van bekendheid bij ERP en e-business kan deels worden verklaard door te kijken naar de branches van de onderzochte organisaties. Er is een verschuiving te zien in de branches ten opzichte van voorgaande jaren. Echter, de aanname dat beide trends over het hoogtepunt heen zijn, ligt voor de hand. Voor beide trends geldt dat daarin nu nog gedane investeringen gaan behoren tot die van de late followers.

C-2006-1-Rutkens-02

Figuur 2. Percentage respondenten dat aangeeft in hoge mate bekend te zijn met de mogelijkheden van de IT-trends (bron: Business & IT Trends Institute, 2006).

Kader 3. Toepassing van IT-trends

Mate van toepassing van IT-trends

Uitgaande van de in kader 2 weergegeven uitkomsten is per IT-trend onderzocht wat de mate van toepassing is van de ‘upper middle class’ der Nederlandse organisaties. Hier volgt een overzicht van de mate van toepassing van IT-trends.

C-2006-1-Rutkens-03

Figuur 3. De mate van toepassing van de IT-trends binnen organisaties in percentages van het totale aantal respondenten (deel 1) (bron: Business & IT Trends Institute, 2006).

Van een hoge mate van operationaliteit is sprake bij de trends Content Management Systemen met 32% en ERP met 38,4% (30% in 2004). Het verschil met voorgaande jaren bij ERP is opvallend te noemen. In 2002 werd door ruim 23% van de respondenten aangegeven grootschalig te investeren of te experimenteren met ERP. Tevens is de volwassenheid van deze pakketten (SAP, BAAN, JDEdwards, Oracle e.d.) zienderogen toegenomen. De ‘daling’ in 2004 ten opzichte van 2003 is terug te vinden in de branche-indeling. De toegenomen aanwezigheid van de branches lokale en centrale overheid en afgenomen aanwezigheid bij handelsorganisatie, transport en vervoer hebben dit verschil grotendeels verklaard. De stijging die nu weer zichtbaar is, wordt enerzijds hierdoor veroorzaakt maar anderzijds door de implementaties in onder meer het onderwijs.

In lijn met vorig jaar is een sterke groei zichtbaar voor Business Intelligence (inclusief datawarehousing). Het percentage Nederlandse organisaties dat deze trend operationeel heeft, is gestegen van 15,3% in 2002 naar 28,4% in 2005. Deze enorme explosie kan misschien in het licht worden gezien van de toenemende wens voor goede (financiële) informatie gezien de huidige economie en de discussies rondom de accountantskantoren en corporate governance. De krantenberichten van de afgelopen twee jaar ondersteunen in elk geval deze mogelijke verklaring.

In figuur 4 is duidelijk te zien dat de geënquêteerde organisaties vooralsnog niet investeren in XBRL en PSA. Dit is in lijn met 2004. Dit telt niet meer voor Open Source, echter hierbij valt het percentage ondernemingen dat de trend overweegt (17%) of experimenteert met Open Source (34%) op. Ook RFID kan momenteel nog niet rekenen op behoorlijke investeringen vanuit het Nederlandse bedrijfsleven. De mate waarin het Nederlandse bedrijfsleven de trend operationeel heeft is slechts licht gestegen. Wel experimenteert circa 12,7% van deze organisaties met de mogelijkheden van RFID, terwijl circa 14% hier nog over nadenkt.

Bij alle trends blijkt het percentage organisaties dat grootschalig investeert lager te zijn dan het percentage organisaties dat de trends operationeel heeft. Dit is een tegengesteld beeld met onze onderzoeken vóór 2002, maar ligt in de lijn van onze verwachtingen gezien de economische ontwikkelingen. Wel zien wij een belangrijke ontwikkeling ten opzichte van 2003, namelijk dat in 2005 en 2006 weer meer wordt geïnvesteerd in ICT. Dit betreft vooral de trends e-business, Content Management Systemen, Business Intelligence, portals, Service Oriented Architectures en W-LAN.

C-2006-1-Rutkens-04

Figuur 4. De mate van toepassing van de IT-trends binnen organisaties in percentages van het totale aantal respondenten (deel 2) (bron: Business & IT Trends Institute, 2006).

De trends J2EE en Linux kunnen de komende jaren nog wel eens wat beroering teweegbrengen. Deze tegenhangers van Microsoft (.Net) scoren inmiddels respectievelijk 18,7% en 18,3% als het gaat om het aantal Nederlandse organisaties dat deze trends operationeel heeft. Ruim 20,5% en 25,7% experimenteert met de mogelijkheden. Hoewel J2EE al enige tijd als een geduchte tegenstander kon worden gezien, is dit jaar Microsofts .Net als tegenhanger van J2EE van de eerste plaats verstoten, waarbij Microsoft .Net met 16,04% van de Nederlandse organisaties die deze trend operationeel heeft, een verschil kent van 2,7% met de nieuwe winnaar J2EE.

Kijkend naar de trends e-business, CMS en vele andere kan met behoorlijke zekerheid worden gesteld dat het Internet Protocol (dan wel diens opvolger) wel een belangrijk structureel element vormt voor toekomstige technologieën en ICT-infrastructuren.

Wat verder opvalt is dat technologieën die een vrij zware organisatorische impact hebben, zoals ERP, Enterprise Application Integration en WFM, een vrij hoge investering (red.: implementatieperiode) met zich meebrengen. Op zich logisch, omdat in die situaties veel meer moet gebeuren dan alleen maar een stuk technologie ‘naar binnen schuiven’. Juist bij deze trends gaat het veel meer om veranderingen in processen, structuren en cultuur (change management).

Trends in IT-auditing

Zoals in de inleiding al is aangegeven, beïnvloeden en geven de hiervoor geschetste IT-trends verdere richting en invulling aan de wijze waarop het vakgebied IT-auditing zich in de komende jaren zal ontwikkelen. Er is tot op heden echter (te) weinig gepubliceerd over trends in IT-auditing. Misschien heeft dit te maken met de aard van het beroep. Rainer Steger verwoordde dit recent in een column in de EDP-auditor als volgt: ‘…wij als IT-auditors verrichten vooral onderzoeken waarbij we de huidige situatie (ist-positie) toetsen aan een set met normen (soll-positie). Aan het doen van voorspellingen wagen wij ons als IT-auditors dan vaak ook niet.’ Hij voorspelt vervolgens: ‘Beveiliging, control en assurance rondom projecten zijn de onderwerpen waarmee wij ons dit jaar met name gaan bezighouden’.

In deze paragraaf geven we op basis van Trends in IT-beveiliging 2006 van Platform Informatiebeveiliging en Het profiel van de audit van NOREA een eerste aanzet voor de belangrijkste trends in IT-auditing. Hieruit komt naar voren dat er een vijftal trends en ontwikkelingen in IT-auditing is te onderscheiden die een grote samenhang vertonen met de ontwikkelingen waarlangs de IT-trends zich bewegen.

Als eerste trend zien we dat verschillende typen audits – operationeel, financieel en IT – steeds dichter naar elkaar toe groeien. Dit is gezien de verschuiving in de toepassing van IT van techniek naar inhoud logisch. In veel branches is IT een steeds belangrijker onderdeel van de bedrijfsprocessen en is zij in veel gevallen het hart van de organisatie. Deze trend wordt versterkt door de eisen van behoorlijk bestuur[Op 9 december 2003 publiceerde de commissie-Tabaksblat haar corporate-governancecode. De code bevat een aantal principes en ‘best practice’-bepalingen op basis waarvan Nederlandse vennootschappen die aandelen of certificaten van aandelen aan een beurs hebben genoteerd, invulling kunnen geven aan behoorlijk bestuur. In de code zijn verstrekkende bepalingen opgenomen omtrent de rapportage over het risicobeheersings- en controlesysteem van de onderneming. Inmiddels zijn door verschillende brancheorganisaties (bijvoorbeeld de HBO-raad en de BVE-raad) specifieke governancecodes ontwikkeld. De code-Tabaksblat heeft hierbij veelal als uitgangspunt gediend.] die in steeds meer branches aan organisaties worden gesteld. Risicomanagement en interne beheersing laten zich vanuit het oogpunt van de bedrijfsvoering niet verdelen in operationeel, financieel en IT. Een verdere integratie van de verschillende typen audits is in de (nabije) toekomst dan ook een bittere noodzaak. Inherent aan deze trend is de ontwikkeling dat het toetsen van de kwaliteit van het proces van totstandkoming en een aantal inhoudelijke randvoorwaarden waaraan strategievorming moet voldoen een belangrijk onderdeel is van de geïntegreerde audit. Interne beheersing vindt immers haar startpunt in de organisatiestrategie. Hierbij is het tevens van belang dat er in de geïntegreerde audit aandacht is voor de wijze waarop een organisatie omgaat met veranderingen. Snel en flexibel reageren op veranderingen is voor een organisatie van groot belang.

Een tweede belangrijke trend vloeit voort uit de steeds verdergaande proces- en ketenintegratie. Om de efficiency in het auditen van dergelijke informatieketens te bevorderen zien we auditors steeds vaker verklaringen afgeven waarop een andere auditor kan steunen. Het bekendste voorbeeld hiervan is een zogeheten SAS 70-verklaring. Een ontwikkeling die zich daarnaast aftekent is dat door de ketenpartners en auditors meer en meer gebruik gemaakt zal worden van een gemeenschappelijk dan wel geïntegreerd en procesgericht stelsel van internecontrolemaatregelen. Nu zien we vaak dat internecontrole- en beheersingssystemen van de verschillende ketenpartners onvoldoende op elkaar aansluiten en hanteren de betrokken (externe) auditors veelal hun eigen normenkader. Niet alleen vertoont het werk van de auditors hierdoor overlap maar bestaat tevens de kans dat er onvoldoende inzicht is in de kwaliteit van het gehele proces.

SAS 70

Hiermee wordt de sjabloon aangeduid van het rapport waarmee de ene auditor zich richt tot de andere auditor. De externe auditor van de aanbieder (service auditor) beoordeelt de interne beheersings- en controlemaatregelen die relevant zijn voor een klant en geeft hierover een oordeel af. De externe auditor van de klant (user auditor) kan vervolgens steunen op dit oordeel.

C-2006-1-Rutkens-05

Figuur 5. SAS 70.

Security is de derde belangrijke trend in IT-auditing. Zoals de toenmalige directeur van de ANWB, Jaap Groen, in het voorwoord van Trends in IT 2004|2005 al aangaf: ‘Security is op dit moment dan ook een belangrijk issue, niet alleen in de ICT, maar vooral ook in onze normale samenleving’. In z’n algemeenheid kan worden gesteld dat het belang van security toeneemt naarmate het aantal mensen met toegang tot de diverse informatiebronnen groter wordt. Daarnaast zorgt het toenemend gebruik van internet ervoor dat de aard van de bedreigingen verandert en dat het aantal bedreigingen toeneemt. De oorzaak hiervan kan worden gezocht in de voortschrijdende technologische ontwikkelingen en de onbegrensde omgeving waarin de bedreigingen zich kunnen manifesteren. Bedreigingen die samenhangen met het gebruik van internet zijn bijvoorbeeld virus- en ‘phishing'[Phishing is het oplichten van mensen door een vertrouwde website te kopiëren, en de nietsvermoedende personen al hun gegevens te laten ingeven zoals hun kredietkaartnummer en hun geheime code. De slachtoffers kunnen naar deze valse website gelokt worden door een e-mail met een link naar deze website (bron: nl.wikipedia.org/wiki/Phishing).]-aanvallen.

De vierde belangrijke trend is ‘tool-based auditing’. De IT-auditor zal bij het uitvoeren van zijn of haar werkzaamheden meer en meer gebruikmaken van Computer-Assisted Audit Techniques (CAAT’s). CAAT’s maken het werk van de IT-auditor niet alleen efficiënter en effectiever maar spelen ook een belangrijke rol bij het testen van interne beheersingsmaatregelen. Door Sarbanes-Oxley (SOX) en de code-Tabaksblat is het voor organisaties noodzakelijk om aantoonbaar ‘in control’ te zijn. Auditors kunnen CAAT’s benutten om feiten te onderbouwen. Daarnaast kunnen organisaties CAAT’s gebruiken om het functioneren van kritische internecontrolemaatregelen te monitoren.

Ten slotte heeft een aantal bovengenoemde trends een belangrijke impact op de wijze waarop de IT-auditor zijn of haar werkzaamheden uitvoert en vastlegt. De verschuiving van ‘tell me’ naar ‘prove me’, het toenemend belang van transparantie en de aard van de ‘in control’-verklaringen vereisen dat de IT-auditor te allen tijde de deugdelijke grondslag van de uitgevoerde audit moet kunnen aantonen. Dit betekent niet alleen standaardisatie van werkwijze (waaronder dossiervorming) maar ook standaardisatie van normenkaders. Belangrijk is om op te merken dat de IT-auditor tijdens de opdrachtaanvaarding en gedurende de opdrachtuitvoering steeds vaker zijn of haar onafhankelijkheid en onpartijdigheid moet kunnen aantonen.

Conclusie

Bij het toepassen van IT gaat het niet langer om de techniek maar om de inhoud. Het gaat om het ontwikkelen van inhoudelijk innovatieve concepten die mogelijk zijn geworden door de technologie: tracking en tracing van pakketten via internet. De nieuwe technologische ontwikkelingen geven organisaties die hierop weten in te spelen, goede mogelijkheden om hun eigen positie in de keten veilig te stellen.

Uit de trends in IT-auditing blijkt dat niet alleen technologische ontwikkelingen van invloed zijn op de ontwikkeling van het vakgebied. Vooral economisch-maatschappelijke ontwikkelingen drukken een belangrijk stempel op het vakgebied. De invloed van de Verenigde Staten is hierbij duidelijk zichtbaar. Het Amerikaanse de jure (rule based) lijkt het meer Nederlandse de facto (principle based) uitgangspunt steeds meer te overvleugelen. Volgens sommigen zijn we terug in het stenen tijdperk: alleen maar afvinken en documenteren. Een auditor zou echter niet alleen naar de letter moeten kijken, maar ook naar de geest.

Literatuur

[Noor06] P. Noordam, B. Derksen en A. van der Vlist, Trends in IT 2006|2007, Business & IT Trends Institute, 2006.

[Noor04] P. Noordam, B. Derksen en A. van der Vlist, Trends in IT 2004|2005, IT Trends Institute, 2004.

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

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

[Rutk04] E.P. Rutkens, H. Bouthoorn en L.P.F. Tushuizen, Risicoanalyse gemakkelijk gemaakt, Compact 2004/1.

[Steg06] R. Steger, Is het voorspellen van de toekomst ook weggelegd voor IT-auditors?, de EDP-auditor, nummer 1, 2006.

www.ibm.com

www.itti.nl

www.microsoft.com

www.nictiz.nl

www.commissiecorporategovernance.nl

Definities

Trends Korte beschrijving
.Net Internetgebaseerde ontwikkelomgevingen waarbij .Net van Microsoft is en J2EE (vanuit Java) het vrijemarktproduct is.
ASP Application Service Providing. Het (gezamenlijk) hosten van applicaties bij een provider.
BPM Business Process Management. Het managen van de processen ondersteund door geautomatiseerde systemen.
Business Intelligence/Datawarehouse Uit diverse bronnen afkomstige gegevens centraal opslaan en toegankelijk maken voor opvragen. Het uit bestaande gegevensverzamelingen afleiden van nieuwe informatie (bijv. koopgedrag van consumenten). Hierbij kunt u ook denken aan datawarehouse en -mining.
CMS Content Management Systeem. Het ‘managen’ van informatie op de website en webapplicaties. Hiermee wordt het proces van contentcreatie tot en met publicatie gemanaged (de levenscyclus van informatie).
CRM Computerondersteunde afhandeling en beheersing van grote stromen ingaand en uitgaand telefoonverkeer. Customer Care betekent ook het customergericht werken. Kernwoorden hierbij zijn: customer loyalty, customer knowledge.
EAI Enterprise Application Integration. Het integreren van de vele applicaties via een service broker.
E-business E-business is het in verregaande mate elektronisch verwerken zodat de producten/diensten zoveel mogelijk elektronisch totstandkomen. Vaak gaat dit samen met het integreren van internettechnologie met bestaande applicaties. In onze definitie is e-commerce een onderdeel van e-business.
EPM Enterprise Project Management Systemen. Ondersteuning van project- en programmamanagement in geïntegreerde systemen.
E-procurement Elektronisch inkopen. Meestal een webbased applicatie om het inkoopproces te standaardiseren/automatiseren.
ERP Software ter ondersteuning van alle bedrijfsprocessen en beheersing van materiaal-, middelen- en geldstromen.
J2EE Internetgebaseerde ontwikkelomgevingen waarbij .Net van Microsoft is en J2EE (vanuit Java) het vrijemarktproduct is.
Linux Het open besturingssysteem als tegenhanger van Microsoft 95/98/2000/XP.
Open Source applicaties Van Open Source Software is de broncode vrij beschikbaar. De software kan vrij worden gebruikt en weer gedistribueerd worden.
PDA The office in a small case, het gebruik van de PDA voor businessapplicaties via UMTS of GPRS (dus niet alleen de agenda/mail maar ook voor toegang tot de bedrijfsapplicaties als SAP e.d.).
Portal/marketplaces Een verzamelplaats op het internet voor afnemers, leveranciers, allianties en geïnteresseerden. Doelstelling is de portal optimaal af te stemmen op de bestaande systemen binnen de organisatie.
PSA Professional Service Automation is datgene voor de professionele projectgerichte processen wat ERP voor de industrie is.
RFID Radio Frequency Identification. Identificatie en processingkracht op korte afstand.
SOA Service Oriented Architecture. Nieuwe wijze van IT-architectuur waarbij de services (IT-diensten) centraal staan.
UMTS Gebruik van UMTS binnen de organisatie.
VoIP Internet Service Providers (ISP’s) die uitgroeien tot concurrerende telecomorganisaties? Dat is mogelijk met Voice over IP (VoIP), voice via het internetprotocol.
Wireless LAN Draadloze lokale netwerken. Ook wel bekend als Wi-Fi (de standaard).
XBRL EXtensible Business Reporting Language.

SAS 70 in een ICT-fabriek

De trend is gezet. Aantoonbaar in control zijn is en wordt steeds belangrijker in het hedendaagse bedrijfsleven. Ook een ICT service provider ondervindt inmiddels welke impact de Sarbanes-Oxley Act Sectie 404 heeft. Verantwoording afleggen vond in de afgelopen jaren grotendeels plaats door middel van service level rapportages en meetings. Dit is niet langer voldoende voor jaarrekening of SOX, een accountantsverklaring over de werking van de controls is vereist, ofwel een SAS 70 type II-verklaring. Dit artikel beschrijft de belangrijkste ontwikkelingen op dit gebied bij een ICT service provider.

Inleiding

Veel ICT service providers hebben klanten die actief zijn in diverse marktsegmenten. Zo hebben de meeste ICT service providers klanten uit de financiële sector maar ook de industriële productieondernemingen en in de telecom- en consumentenindustrie. Meer en meer zien wij in de praktijk dat deze klanten accountantsverklaringen vragen van hun ICT service provider, waarin ‘assurance’ wordt gegeven dat aan de voor hen relevante wet- en regelgeving wordt voldaan. Naast bijvoorbeeld ISO, BS7799, code-Tabaksblat of de Sarbanes-Oxley Act (SOXA) is hieronder een aantal voorbeelden genoemd:

  • Ondernemingen actief in de financiële sector hebben al snel te maken met toezichthouder DNB en de richtlijnen van Basel II.
  • Als ondernemingen in de farmaceutische of voedingsindustrie willen opereren in Amerika zijn de richtlijnen van Food and Drug Administration (FDA) aan de orde.
  • Ondernemingen actief in de telecom hebben bijvoorbeeld ook te maken met de OPTA als toezichthouder.

De consequentie hiervan is dat ICT service providers compliance moeten kunnen aantonen met al deze vormen van wet- en regelgeving. Vanzelfsprekend betekent dit dat de auditkosten van ICT service providers de afgelopen tijd sterk zijn toegenomen.

In dit artikel staat het SAS 70-onderzoek in relatie tot ICT service providers centraal. Het SAS 70-onderzoek wordt in toenemende mate toegepast om klanten van de gevraagde ‘assurance’ te voorzien, vooral als gevolg van de SOXA. Dit artikel is het eerste uit een serie van twee. Het tweede artikel dat in de volgende Compact verschijnt, legt het accent op de ‘gebruikers’ van het SAS 70-rapport, de klant van de serviceorganisatie en diens accountant.

Dit artikel beschrijft allereerst het krachtenveld waarin ICT service providers zich bevinden, om vervolgens in te gaan op de betekenis van de SOXA voor de ICT service providers. Het geven van zekerheid over de kwaliteit van de dienstverlening aan belanghebbenden kan worden afgegeven in de vorm van een SAS 70-rapport. In dit artikel wordt stilgestaan bij de verschillende vormen van SAS 70-rapporten, generiek en specifiek. Verder zal een onderzoeksbenadering worden beschreven waarmee een specifieke SAS 70-rapportage efficiënt kan worden opgesteld en waarbij de operatie van de ICT service provider zo minimaal mogelijk wordt verstoord met diverse audits. Tot slot zal een aantal tips worden gegeven voor zowel de gebruikers van het SAS 70-rapport als de verstrekkers ervan.

Krachtenveld ICT service providers

Bedrijven blijven er in toenemende mate voor kiezen hun IT-operatie of delen daarvan te outsourcen naar externe serviceorganisaties. Naast verwachte financiële voordelen zijn de meer kwalitatieve redenen die daarvoor worden aangevoerd ([Vank05]):

  • versterken van aandacht op kernactiviteiten;
  • verhogen van commerciële slagkracht;
  • vrijmaken van middelen voor investeringen.

Zo stelt bijvoorbeeld Heijmans NV in haar persbericht van 9 februari 2006 waarin de outsourcing van ICT wordt aangekondigd, dat met de outsourcing flexibeler kan worden ingesprongen op de complexe ICT-behoefte van haar innovatieve producten.

Ook ABN AMRO, dat in het kader van het Group Shared Serviceprogramma in 2005 aankondigde onder andere haar IT-infrastructuur te outsourcen, noemt hiervoor argumenten als ‘duurzame versterking van concurrentiekracht en verbetering van dienstverlening door toegang tot moderne technologie’.

Met andere woorden, er leeft een verwachting bij het management dat met het outsourcen van de IT-operatie kosten worden bespaard, de kwaliteit ervan toeneemt en de gewenste flexibiliteit voor het doorvoeren van veranderingen en innovaties hierdoor wordt ondersteund. Voorts verwacht de klant de individuele aandacht die hij altijd was gewend.

Hoewel de hier uitgesproken verwachtingen naar onze mening realistisch zijn, blijkt het realiseren ervan in de praktijk een lastige klus te zijn. Zeker bij grote ‘deals’, waarbij complete rekencentra, bestaande infrastructuren, mensen en werkwijzen worden overgenomen, is het bereiken van succes geen sinecure. Naast het feit dat tijdens een outsourcingsdeal integratie actief dient te worden gemanaged en geen genoegen mag worden genomen met het resultaat dat de services gewoon zijn blijven ‘doordraaien’, is er een aantal zeer belangrijke voorwaarden waaraan moet worden voldaan wil integratie voor zowel klant als provider succesvol zijn:

  • Kennis, kunde en ervaring dienen te worden gecentraliseerd, benut en verbeterd.
  • Processen dienen te worden gestandaardiseerd, gestroomlijnd en gespecialiseerd.
  • Er dient sprake te zijn van een ‘sustainable’, transparante en zoveel mogelijk klantonafhankelijke organisatievorm, waarin toekomstige ‘deals’ kunnen worden geabsorbeerd.
  • Een standaardraamwerk van controls, instructies en verantwoordingsinformatie dient te zijn ingericht.

De auteurs hebben in de praktijk integraties gezien die binnen een jaar nagenoeg waren afgerond, maar tevens voorbeelden van integraties die na twee jaar nog in de kinderschoenen stonden voornamelijk als gevolg van het niet voldoen aan één of meer van de bovengenoemde voorwaarden.

In dit artikel zal blijken dat de genoemde randvoorwaarden ook zeer belangrijk zijn om op een zo kosteneffectief mogelijke manier een op de klant en zijn accountant afgestemd SAS 70-rapport te leveren.

SOXA (Sarbanes-Oxley Act) en ICT service providers

Met de komst van SOXA hebben ook de ICT service providers er een uitdaging bij gekregen. Vanuit alle uithoeken komen de verzoeken binnen om aan te tonen dat de general IT controls in en rondom de voor de klant relevante infrastructuren, systemen en processen op orde zijn. Hierop kan grofweg op twee verschillende manieren antwoord worden verkregen:

  • via het door de klant uitoefenen van het ‘right of audit’ (indien dit is overeengekomen);
  • via een Statement on Auditing Standards nr. 70 (SAS 70) (type II)-rapport.

Vanuit het perspectief van de ICT service provider is het effectueren van het ‘right of audit’ het laatste waarop hij zit te wachten. Praktisch betekent dit namelijk het volgende:

  • Vanuit SOXA dient het management van degene die klant is bij de provider, zelfstandig vast te stellen dat key controls aanwezig en effectief zijn.
  • De accountant van de klant dient in het kader van de jaarrekeningcontrole en ter toetsing van de juistheid van de managementbewering zelfstandig testwerkzaamheden uit te voeren.

De serviceorganisatie wordt tweemaal belast met auditwerkzaamheden. Nu valt dit allemaal wel mee wanneer de ICT service provider slechts één klant heeft, het wordt pas echt lastig als iedere klant dit recht gaat uitoefenen. In het gunstigste geval zou dit betekenen dat er eerst tientallen managementteams of afvaardigingen daarvan, rondom een en dezelfde persoon staan om bijvoorbeeld via waarneming ter plaatse vast te stellen dat toch wel echt via een ‘securID’-token wordt aangelogd op het servicenetwerk en een paar weken later de auditors van die klanten rond diezelfde persoon staan om vast te stellen dat de bewering van het management klopt. In een minder gunstig geval komen de verzoeken verspreid binnen en vindt gedurende enkele maanden meerdere keren per week een audit plaats op een en dezelfde control. Dit is slechts één voorbeeld om aan te tonen waarom een ICT-serviceorganisatie dit niet zou willen.

Een SAS 70-rapport zou uitkomst kunnen bieden voor dit probleem. Om dit goed te kunnen begrijpen moet het concept iets verder worden toegelicht.

In het SAS 70-concept worden vier partijen onderscheiden:

  • de userorganisatie, dit is de organisatie die haar diensten heeft uitbesteed en de primaire vrager van het SAS 70-rapport;
  • de user-auditor, dit is de accountant van de userorganisatie;
  • de serviceorganisatie, dit is de externe (IT-)dienstverlener en de verstrekker van het SAS 70-rapport;
  • tot slot de service-auditor, de onafhankelijke door de PCAOB erkende auditor die een oordeel afgeeft bij het SAS 70-rapport.

SAS 70 bestond al lang voordat in 2002 de SOXA zijn intrede heeft gemaakt. Van oudsher is een SAS 70 een instrument om zekerheid te bieden aan de externe accountant van een klant die processen of delen daarvan heeft uitbesteed aan een derde partij en waarbij deze processen van invloed waren op de jaarrekening van de klant. Dit is niet veranderd.

Echter, sinds de publicatie van standaard nr. 2 van de PCAOB ([PCAO04]) heeft SAS 70 een breder bereik gekregen. In artikel B18 van PCAOB-standaard 2 is vrij vertaald opgenomen dat hoewel SAS 70 in beginsel een auditor-to-auditor rapport is, dit ook door het management mag worden gebruikt voor zijn ‘assessment of internal control over financial reporting’. Wel is hiervoor een SAS 70 type II-rapport vereist waarin naast opzet en bestaan ook zekerheid over de werking van controls wordt gegeven. Hiermee wordt het SAS 70-rapport enerzijds een verlengstuk van het internal control framework dat een organisatie in het kader van haar SOX-programma opzet, anderzijds behoudt het zijn initiële doelstelling om zekerheid te geven aan de user-auditor in het kader van zijn audit op de jaarrekening van de klant.

In een SAS 70-rapport worden vier secties onderscheiden (voor meer details zie [Bigg05]). Hoewel de structuur niet strikt voorgeschreven is, bevat in de praktijk Sectie 1 het oordeel van de service-auditor. Sectie 2 is een beschrijving van dienstverlening, control objectives en controls binnen de serviceorganisatie. Sectie 3 geeft de testwerkzaamheden en resultaten van de service-auditor weer. Sectie 4 is gereserveerd voor aanvullende informatie die de serviceorganisatie noodzakelijk vindt te vermelden. Over de inhoud van deze sectie wordt door de service-auditor geen zekerheid gegeven (zie voor meer details tabel 1).

C-2006-1-Biggelaar-t1

Tabel 1. Secties per type SAS 70-rapport.

Sectie 2 omhelst bij een ICT service provider vaak het onderwerp general IT controls. PCAOB-standaard 2 spreekt in dit kader over vier relevante gebieden:

  • Access to Programs and Data;
  • Program Changes;
  • Program Development;
  • Computer Operations.

In de praktijk zien de auteurs dat userorganisaties die hun IT-operatie of delen ervan hebben geoutsourcet, in het kader van hun eigen SOX-programma voor deze vier gebieden zogeheten control objectives definiëren. Deze control objectives geven in wezen per gebied specifieker aan waarover door de userorganisatie aan de serviceorganisatie zekerheid wordt gevraagd (zie voorbeelden tabel 2). De serviceorganisatie beschrijft op haar beurt welke ‘controls’ zij in operatie heeft om aan de control objectives te kunnen voldoen.

Aangezien elke userorganisatie vaak eigen control objectives definieert, dient de serviceorganisatie in principe telkens opnieuw controls te definiëren die zij heeft geïmplementeerd om aan de control objective te kunnen voldoen. Omwille van efficiency, zo zien de auteurs in de praktijk, definieert een ICT-serviceorganisatie op basis van bestaande processen een eigen internal control framework waaruit zij kan putten voor het beschrijven van controls. Hierover meer in het vervolg van dit artikel.

C-2006-1-Biggelaar-t2

Tabel 2. Voorbeelden van control objectives per PCAOB-domein.

Generieke of specifieke SAS 70-rapporten? … of …?

Zeker voor wereldwijd opererende ICT service providers, die van diverse multinationals de IT-operaties hebben overgenomen, is er sprake van een grote diversiteit aan dienstverlening. Deze diversiteit wordt bepaald door technologische en organisatorische aspecten, waarbij onder meer bepaald moet worden of er sprake is van:

  • diverse platformen die worden ondersteund (mainframes, Unix, Windows, etc.);
  • databasemanagementservices en zo ja, welke (Oracle, SQL-server, Informix, etc.);
  • technisch applicatiebeheer rondom bijvoorbeeld SAP en Oracle;
  • systeemontwikkelingsactiviteiten en zo ja, op welke ontwikkelomgevingen;
  • het aantal rekencentra;
  • netwerkbeheeractiviteiten.

Tevens vindt voor multinationale klanten in veel gevallen de dienstverlening verspreid over de wereld vanuit verschillende organisatorische eenheden plaats.

Gegeven deze situatie duiken twee belangwekkende, met elkaar samenhangende vragen op:

  • In hoeverre is het mogelijk om generieke SAS 70-verklaringen af te geven?
  • Welke waarde heeft een generieke SAS 70-verklaring voor de gebruikers ervan?

Strikt genomen is het mogelijk een generiek, niet-klantspecifiek, SAS 70-rapport op te stellen voor een gestandaardiseerde dienst. Wel is het dan belangrijk dat ook de controls binnen deze dienst uniform zijn. Hierbij dient echter wel afgewogen te worden welke geografische/organisatorische reikwijdte de verklaring beoogt te hebben. Wanneer deze dienst bijvoorbeeld over de wereld door verschillende organisatorische entiteiten wordt verricht waarbij deze entiteiten tevens van elkaar verschillende klanten bedienen, dan lijkt een generiek rapport over deze verschillende entiteiten op voorhand niet zinvol te zijn. In dit geval is een generiek rapport per entiteit wellicht verstandiger.

Belangrijker is echter te onderkennen dat de totale dienst die door een klant wordt afgenomen een complexe en unieke samenstelling is van een veelheid aan diensten rondom verschillende technische platformen en verspreid kan zijn over meerdere geografische locaties en organisatorische eenheden. Een klant wil in een SAS 70-rapport vaak een afbeelding zien van zijn specifieke situatie. Hiermee valt te begrijpen dat de behoefte van de klant meer is dan een optelsom van generieke per dienst opgestelde SAS 70-rapporten.

De hierboven genoemde behoefte in ogenschouw genomen en de omstandigheid dat sprake is van klantspecifieke control objectives afkomstig uit het eigen interne SOX-programma, verklaren waarom in deze situatie generieke SAS 70-rapporten meestal niet volstaan en als ‘te high level’ worden ervaren. Daardoor is er al snel sprake van een kostbaar maatwerktraject. Dit zijn echter niet de enige determinanten voor maatwerk. De keuze daarvoor wordt mede bepaald door:

  • De aard en organisatie van de dienst. Zo maakt het een verschil of de dienstverlening betrekking heeft op een inherent centraal georganiseerd platform zoals een mainframe of op een meer gedistribueerde omgeving en een inherent meer verspreide beheerorganisatie van bijvoorbeeld Unix- en Windows-systemen.
  • De volwassenheid van de insourcing (voltooiing van de integratie). Wanneer de insourcing nog niet voltooid is en infrastructuren en systemen nog niet zijn opgezet conform de standaard (security) baselines en de diensten nog niet volledig via de standaardprocessen verlopen, is maatwerk haast onvermijdelijk.
  • De mate waarin er überhaupt sprake is van de randvoorwaardelijke standaardprocessen en beheersingsmaatregelen.

Dit zijn in wezen alledrie interne factoren die door de ICT service provider zelf te beïnvloeden zijn. Stel dat de ICT service provider zich dusdanig heeft georganiseerd dat alle systemen conform gedefinieerde baselines zijn ingericht, of tenminste afwijkingen daarvan bekend en bewust overeengekomen zijn en dat IT-beheerprocessen en controls voor alle klanten hetzelfde zijn, zou dan een generiek SAS 70-rapport voor zowel klant als diens auditor voldoende zijn? Uit gesprekken die de auteurs met userorganisaties en hun auditors hebben gevoerd, valt af te leiden dat er een duidelijke behoefte bestaat dat de service-auditor de specifieke omgeving en situatie van de userorganisatie test bij het geven van ‘assurance’ op een afgenomen dienst. Met andere woorden, ook al blijkt bijvoorbeeld dat het change-managementproces van een Unix-service-unit, waardoor zowel servers voor klant A als voor klant B worden beheerd, op een uniforme manier wordt uitgevoerd, dan nog blijft de behoefte bestaan dat een selectie van klantspecifieke changes wordt getest. Terwijl in die situatie volstaan zou kunnen worden met een voor die service-unit relevante selectie.

Is daarmee voor de userorganisatie een kostbare en voor de serviceorganisatie een vaak terugkerende en operatieverstorende maatwerkaudit het enige alternatief? Of is er een vorm denkbaar waarin ingegaan wordt op de specifieke behoefte van de userorganisatie zonder dat dit leidt tot exponentieel hoge kosten en waarbij de serviceorganisatie minimaal wordt gestoord met operatieverstorende audits?

Building block approach

Vanuit het perspectief van de ICT service provider zijn er, zoals hierboven beschreven, interne en externe factoren die een ‘neiging’ naar maatwerkaudits bepalen. De interne factoren zijn door de service provider zelf te beïnvloeden en kunnen aan de bron zelfstandig worden opgelost. De externe factoren (klantspecifieke control objectives en testvereisten) zijn deels een gegeven waarmee op een creatieve manier moet worden omgegaan. Wat de klantspecifieke control objectives met elkaar gemeen hebben, is het feit dat ze zijn afgeleid van één gemeenschappelijk referentiepunt namelijk de general IT control-aspecten die door de PCAOB in standaard 2 worden genoemd (zie hierboven). In de praktijk zien wij dat:

  1. per klant het aantal control objectives per aspect sterk verschilt;
  2. de ene klant zijn control objectives met betrekking tot bijvoorbeeld ‘access to programs and data’ bondiger en concreter formuleert dan de ander.

Beide punten leiden ertoe dat het aantal door de ICT service provider te benoemen en door de service-auditor te testen controls per klant varieert.

Het is voor de ICT service provider van belang de grootste gemene deler van key-controls te definiëren en implementeren die de afdekking van de door zijn klanten gevraagde control objectives waarborgt. In de praktijk zien de auteurs dat CObIT ([ITGI00]) hiervoor een bruikbaar handvat biedt. Op deze manier kan per klantsituatie een mapping worden gemaakt tussen de generieke key-controls en de klantspecifieke objectives, waardoor een klantspecifieke SAS 70-rapportage efficiënt kan worden gerealiseerd.

Hiermee is één van de externe factoren opgelost. Hoe echter om te gaan met de factor van het klantspecifieke testen van controls enerzijds en het minimaal verstoren van de IT-operatie anderzijds? Hierin spelen twee zaken een belangrijke rol:

  1. Er dient in een zo vroeg mogelijk stadium bekend te zijn welke klanten van de ICT service provider over welke tijdsperiode een SAS 70 type II-verklaring wensen.
  2. In het plannen van het testen van de controls dient niet de klant, maar het organisatieonderdeel als primair uitgangspunt te worden genomen.

Er is al aangegeven dat een type II-verklaring naast opzet en bestaan ook zekerheid geeft over de werking van controls. De beoordeelde werkingsperiode dient daarbij in beginsel minimaal zes maanden te omvatten (paragraaf 4.36 in [AICP06]). De auteurs zien in hun praktijk een ontwikkeling dat deze minimale periode in de meeste gevallen door de userorganisatie en haar auditor wordt gevraagd en wel over het tijdvak van april tot en met september van het onderhavige kalenderjaar (in het geval er geen sprake is van een gebroken boekjaar). Met die wetenschap is het voor de ICT service provider en de service-auditor mogelijk in een vroeg stadium te bepalen welke organisatieonderdelen voor welke klanten in één testblok kunnen worden afgehandeld, waarin rekening kan worden gehouden met het klantspecifiek testen van controls (bijvoorbeeld het testen van beveiligingsparameters op specifiek door de klant gevraagde Unix-machines).

Samengevat heeft deze building block-benadering de volgende voordelen:

  • De klant (en diens externe auditor) ontvangt een specifiek op zijn SOX-programma aansluitend SAS 70-rapport tegen een aanvaardbare prijs.
  • De operatie van de ICT service provider wordt minimaal gestoord door een veelheid aan audits.
  • De werkzaamheden zijn zowel voor de service auditor als voor de ICT service provider veel beter te plannen.

Het klantorderontkoppelpunt ligt met andere woorden tussen het veldwerk, dat generiek en zoveel mogelijk anoniem wordt uitgevoerd, en de rapportage, die op basis van dit veldwerk specifiek op de klant tot stand wordt gebracht (zie tevens figuur 1).

Overigens sluit deze benadering ook volledig aan bij de manier waarop de ICT service providers hun dienstverlening aan hun klanten wensen te organiseren. Aan de voorkant een op de klant toegespitste Customer Care-organisatie, aan de achterkant anonieme gestandaardiseerde Service Delivery-processen.

C-2006-1-Biggelaar-1

Figuur 1. Building block-benadering.

Controls transformation, synergie onderkennen en benutten

Klanten van ICT service providers zijn op dit moment nog bereid om extra te betalen voor ‘assurance’. Dit zal waarschijnlijk echter maar van tijdelijke duur zijn. Vergelijk het met alle nieuwe vaak technologische ontwikkelingen waarvoor de klant in het begin bereid is te betalen, maar die naarmate de tijd verstrijkt vanzelfsprekend worden. Meer voor minder zal ook het ‘lot’ van SAS 70 en meer algemeen van ‘assurance’ zijn. Deze wetmatigheid is slechts één van de redenen waarom ICT service providers op zoek zullen moeten gaan naar randvoorwaarden om de kosten voor het bieden van ‘assurance’ te verminderen. Naast de SOXA worden steeds meer compliance-achtige vereisten door de klant overgedragen aan de ICT service provider. Denk hierbij aan de ROB, Basel II, FDA, BS7799, OPTA, etc. Vreemd genoeg biedt juist deze toename van ‘drivers’ de mogelijkheid om tot een relatieve kostenverlaging voor ‘assurance’ te komen. Wanneer namelijk een analyse wordt gemaakt tussen de ‘assurance’-vereisten van deze verschillende ‘drivers’, dan blijkt dat hierin een grote overlap bestaat. Met andere woorden, de eerder benoemde key-controls gedefinieerd en geïmplementeerd in de processen van de ICT service provider dienen verschillende doelen. Wanneer dit wordt onderkend en gestructureerd wordt vastgelegd in het samenspel van de key-controls (control framework), dan biedt deze vastlegging een belangrijk fundament om audits ten behoeve van deze verschillende ‘drivers’ op een efficiënte manier te plannen en uit te voeren.

Het probleem dat hierbij wel komt kijken, is dat geaccrediteerde certificerende instanties voor de verschillende audits kunnen verschillen of juist bewust verschillend door de ICT service provider zijn gekozen, waardoor de resultaten van de vastlegging in beginsel slechts beperkt kunnen worden benut. Tenzij de ICT service provider bij de uitvoering van zijn key-controls (handmatig en geautomatiseerd) een gestructureerde vastlegging van de resultaten maakt en die op een ‘dataroom-achtige’ manier beschikbaar stelt aan de auditors. Er zijn inmiddels geautomatiseerde hulpmiddelen beschikbaar die deze werkwijze ondersteunen. Hiermee worden als het ware internal compliance statements geïntegreerd met de normale management-controlhandelingen. Internal compliance statements vormen een belangrijke input voor een externe certificering.

Tips

Wij sluiten dit artikel af met een aantal tips voor zowel de verstrekker van het SAS 70-rapport (serviceorganisatie) als de gebruikers (userorganisatie en user-auditor) ervan.

In veel bestaande servicecontracten, die veelal een meerjarige looptijd hebben, zijn een SAS 70-rapport en de daarmee samenhangende kosten niet voorzien. Als gevolg daarvan zien wij een commerciële discussie ontstaan over wie nu moet opdraaien voor de kosten van een dergelijk rapport. Met de bestaande contractclausule rondom ‘the right of audit’ is hierover op voorhand geen uitsluitsel te geven, aangezien in dergelijke situaties de klant meestal opdraait voor de externe auditkosten en de ICT service provider voor de interne auditteekosten en organisatorische overhead. Voor organisaties die aan de vooravond staan een servicecontract te vernieuwen of aan te gaan, is aan te bevelen een SAS 70-rapport in de onderhandelingen mee te nemen.

Zoals al in een eerdere paragraaf beschreven wil een klant zijn specifieke situatie herkennen in een SAS 70-rapport. Deze specifieke situatie wordt bepaald door:

  • IT-platformen en -omgevingen waarop diensten betrekking hebben;
  • organisatorische onderdelen die de dienst verlenen;
  • IT-beheerprocessen die de dienst omvatten;
  • control objectives waarover ‘assurance’ wordt gevraagd.

Verwachtingsmanagement rondom een specifiek SAS 70-rapport begint dan ook bij het opstellen van een auditplan waarin onder meer bovengenoemde aspecten expliciet overeengekomen worden. Een vroegtijdige communicatie en afstemming tussen de vier ‘partijen’ in een SAS 70-onderzoek is dan ook een belangrijke succesfactor voor een herkenbaar en daardoor voor de ontvanger zinvol SAS 70-rapport.

Een hierop aansluitend onderwerp betreft een rechtvaardige scoping. De auteurs hebben in hun dagelijkse praktijk kunnen ondervinden, dat de user-auditor liever te veel ‘assurance’ vraagt dan te weinig. Zo zijn er meermaals discussies gevoerd of bijvoorbeeld ‘interne firewalls’ wel of niet in scope zouden moeten zijn van een onderzoek. Tevens blijkt dat de omvang van het aantal control objectives waarover ‘assurance’ wordt gevraagd niet altijd in een redelijke verhouding staat met het reële risico dat met de dienst(en) samenhangt. Ook hiervoor geldt dat een open vierpartijenoverleg de beste basis is om tot een zinvolle en rechtvaardige scoping te komen.

Conclusie

Of een SAS 70-rapport in een ICT-fabriek een accessoire, een fabrieksoptie of een onderdeel van de standaard is, is niet eenduidig te beantwoorden. Veel wordt bepaald door de mate waarin het totale dienstenpakket aan een klant specifiek en uniek is. In situaties waarin dit niet het geval is kan een generiek statement voor de gebruikers ervan zinvol zijn en is een SAS 70-rapport als standaard ook vanuit kostenoogpunt te adviseren. In situaties waarin de inrichting van diensten en processen klantspecifiek is, is maatwerk welhaast onvermijdbaar en als accessoire te beschouwen. In overige situaties kan door gebruikmaking van een ‘handige onderzoeksaanpak’ het compromis worden gevonden in een fabrieksoptie, waarbij in relatieve zin de operatie van de ICT service provider zo min mogelijk wordt verstoord en een klantspecifiek SAS 70-rapport kan worden geleverd tegen aanvaardbare kosten.

Literatuur

[AICP06] American Institute of Certified Public Accountants, AICPA Audit and Accounting Guide: Service Organizations: Applying SAS 70, as Amended, 2006.

[Bigg05] S.R.M. van den Biggelaar en P.C.V. Waldenmaier, Praktijkervaringen binnen SAS 70-trajecten, Compact 2005/2.

[ITGI00] IT Governance Institute/ISACA, CobiT, Governance, Control and Audit for Information and Related Technology, Management Guidelines, 2000, third edition.

[PCAO04] Public Company Accounting Oversight Board, Auditing Standard No. 2, An Audit of Internal Control Over Financial Reporting Performed in Conjunction with An Audit of Financial Statements, 2004/3.

[Vank05] G. Vankan, Th. Huibers en J. Schut, Opnieuw op zoek naar de kerncompetenties – de invloed van shared services, outsourcing en offshoring op de prestaties van uw onderneming, white paper naar aanleiding van het KPMG sourcing seminar, 2005/11.

Valkuilen bij implementatie van bankpakketten

Banken hebben bij vervanging van bancaire applicaties een keuze tussen het zelf ontwikkelen van een applicatie dan wel het aanschaffen van een standaard-bankpakket. Er zijn diverse softwareleveranciers die verschillende bancaire applicaties aanbieden, welke variëren van specifieke toepassingsapplicaties (bijvoorbeeld voor treasury- of effectenactiviteiten) tot generieke backofficeapplicaties (de zogenoemde ‘core banking’-applicaties). Valt de keuze op een standaard aan te schaffen bankpakket, dan wordt een project ingericht voor de implementatie van het gekozen bankpakket. Op basis van onze ervaring bij de beoordeling van dergelijke projecten zien wij in de dagelijkse praktijk dat zich een aantal valkuilen voordoet. In dit artikel wordt ingegaan op deze valkuilen en wordt getracht om een aantal mitigerende maatregelen aan te reiken.

Inleiding

Implementatie van een banksysteem (een systeem waarin klanten en hun bankproducten worden vastgelegd en dat één of meer bankprocessen ondersteunt, zoals betalen, lenen, sparen, vermogensbeheer, beleggen, etc.) is bijna per definitie een high-risk project. Het succes van banken hangt zeer sterk samen met klantvertrouwen, en dus is er een harde noodzaak om dergelijke projecten plaats te laten vinden zonder businessverstoring en met transparantie voor de klant. Vergelijk het maar met een openhartoperatie. Bovendien is er meestal sprake van een behoorlijk complexe materie. Bijvoorbeeld vanwege de hoeveelheid interfaces naar interne en externe systemen, of vanwege gecompliceerde producten die resulteren in complexe datamodellen en complexe conversies. Daarbij komt ook dat in vergelijking met andere sectoren bancaire processen minder gestandaardiseerd zijn.

KPMG IRM heeft ruime ervaring met deze risicofactoren. Het bankenteam van KPMG IRM Financial Services biedt banken ondersteuning bij implementatietrajecten van bankpakketten, zowel bij het beoordelen van lopende projecten als bij het coördineren van de transitieprocessen. In dit artikel worden de risico’s die zich specifiek bij dit soort projecten voordoen op een rijtje gezet. De systeemomgeving bij banken is sterk aan verandering onderhevig. De ‘drivers’ hiervoor zijn legio, zoals schaalvergroting, wet- en regelgeving, ‘straight through’-processing en vervanging van legacy systemen.

Op basis hiervan worden de voornaamste valkuilen bij implementatietrajecten van bankpakketten beschreven, waarbij ook adviezen voor een ‘best practice’-benadering van de problematiek worden gegeven.

Aandachtsgebieden Project Risk Management

Ten behoeve van het opzetten en inrichten van projecten, maar ook ten behoeve van het beoordelen van projectrisico’s en te treffen projectbeheersingsmaatregelen kan een aantal aandachtsgebieden worden onderkend. Hiervoor hanteren we de structuur van de Project Risk Assessment Methode (PRAM) van KPMG.

PRAM kent de volgende structuur ([KPMG06]):

Strategic environment

Wat zijn de strategische doelstellingen van projecten? Op welke wijze worden de externe factoren beheerst waarop het project zelf geen invloed heeft, die van invloed kunnen zijn op het behalen van deze doelstellingen? Hoe is portfoliomanagement ingericht, als instrument voor senior management om continue alignment tussen bedrijfsdoelstellingen en investeringen in IT te waarborgen?

Business focus

Worden projecten ondersteund door het juiste managementniveau? Is er een goedgekeurde en geldige business case en adequate uitgangsdocumentatie? Een belangrijk aandachtspunt is verder het continu bewaken van de realisatie van de business case.

Project Management

Zijn de managementprocessen voor de sturing en beheersing van projecten ingericht, zoals programmamanagement, teammanagement, planning, monitoring en risk management? Hoe wordt issuemanagement ingezet als middel om issues, risico’s en wijzigingen op gestructureerde wijze, volgens vaste procedures en procuratie, op het juiste project- of programmamanagementniveau te rapporteren?

Solution Management

Hanteert de organisatie een gestructureerde aanpak voor het ontwikkelen, inrichten en implementeren van applicatiesystemen? Wordt onder andere aandacht besteed aan:

  • definiëren nieuwe administratieve organisatie (procesbeschrijvingen en structuur);
  • kwaliteit systeemontwikkeling, gebaseerd op een formele methodiek met aandacht voor functionele specificaties, interfaces, documentatie, conversie en autorisaties;
  • voorbereiden beheerorganisatie, onder andere op het gebied van beheerprocedures, back-up en recovery, beveiliging en continuïteit;
  • betrokkenheid en afhankelijkheid derde partijen.

People Management

Hoe zorgt de organisatie ervoor dat de gebruikersorganisatie nieuwe oplossingen accepteert? Besteedt de organisatie aandacht aan:

  • betrokkenheid gebruikersorganisatie in het project;
  • inrichting van het organisatorisch verandermanagement;
  • opleidingen gebruikers en communicatie.

In de hiernavolgende paragrafen wordt per aandachtsgebied een aantal attentiepunten beschreven die van belang zijn bij de implementaties van een bankpakket.

Strategic environment en Business focus

Er is een groot aantal uiteenlopende redenen waarom een project tot implementatie van een standaard-bankpakket wordt opgestart.

Redenen voor aanpassing

Ter illustratie waarom banken op de aandachtsgebieden Strategic environment en Business focus voortdurend in beweging zijn, is in deze paragraaf een (niet-limitatieve) opsomming gegeven.

Compliance

In de categorie Compliance geven wijzigingen in wet- en regelgeving aanleiding tot ingrijpende aanpassing of vervanging van bestaande applicaties. In het algemeen worden door toenemende rapportage-eisen (bijvoorbeeld DNB-reporting) bestaande inflexibele legacy systemen vervangen door ‘modernere’ pakketten waarbij dataontsluiting ten behoeve van bijvoorbeeld financial reporting eenvoudiger te realiseren is. IFRS is een goed voorbeeld uit het nabije verleden, echter er zijn ook meer recente ontwikkelingen. Hieronder volgen enkele voorbeelden:

  • Basel II initieert omvangrijke aanpassingen aan de wijze waarop informatie uit bankproductadministraties wordt verzameld ten behoeve van credit-, market- en operational risk-scoringmodellen en -rapportage.
  • CDD (Customer Due Diligence)-wetgeving initieert aanpassingen ten behoeve van het verzamelen van informatie uit zowel bankproductadministraties, financiële administraties als transactieprocessingsystemen in het kader van Know-Your-Transaction en Know-Your-Customer monitoring. CDD heeft tot doel het monitoren van alle klanten van de banken, en systemen te ontwikkelen waardoor informatie over de identiteit kan worden uitgewisseld en het rekeningverloop kan worden gemonitord. Dit vraagt investeringen in en aanpassing van bestaande systemen.
  • De ‘Markets in Financial Instruments Directive’ (MiFID; richtlijn 2004/39/EG) stelt nieuwe ingrijpende eisen aan beleggingsinstellingen en banken ten aanzien van onder meer vergunningen en de informatievoorziening aan de klant. Specifieke bepalingen zijn opgenomen betreffende de interne controle bij beleggingsondernemingen, de bedrijfscontinuïteit, de uitbesteding van operationele functies, de segregatie van cliëntentegoeden, de interne gedragscodes en het bijhouden van gegevens.
Schaalvergroting

Enkele redenen in de categorie Schaalvergroting zijn:

  • Als gevolg van fusies tussen bancaire instellingen worden bestaande applicaties vervangen door standaard-bankpakketten.
  • Al sinds jaren is er de trend om lokaal in gebruik zijnde applicaties en backofficesystemen te consolideren in shared service centers. Het shared service center levert (met standaardpakket op een schaalbare infrastructuur) diensten aan operationele eenheden.
Technologie

Als redenen in de categorie Technologie kunnen worden genoemd:

  • Door de introductie van 24×7 ‘Direct Banking’ en het toepassen van op internettechnologie gebaseerde applicaties worden andere eisen gesteld aan de beschikbaarheid van gegevens, robuustheid van systemen en bijvoorbeeld toeleverende processen zoals het proces van aanleveren van koersinformatie.
  • Kennis van bestaande legacy systemen neemt af waardoor organisaties risico’s lopen ten aanzien van de toekomstige onderhoudbaarheid en flexibiliteit van de systemen.
Kostenbesparing

In de categorie Kostenbesparing vallen als redenen te onderkennen:

  • Zelfbouw of weinig in gebruik zijnde pakketten, waarvan kennis en onderhoud duur is, worden vervangen door meer gangbare pakketten waarvan gebruik en kennis in de markt in ruimere mate beschikbaar is.
  • Een standaard-bankpakket met geïntegreerde functionaliteit (ondersteunen van meerdere bancaire processen) kan meerdere applicaties vervangen waardoor kostenbesparing in toekomstig beheer kan worden gerealiseerd.
  • Trajecten tot uitbesteding van bankprocessen en systemen worden opgestart, waarbij ondersteuning van deze processen veelal gefaciliteerd wordt door de inzet van standaard-bankpakketten.
Optimalisatie van bedrijfsprocessen en serviceverlening

Voorbeelden van redenen in de categorie Optimalisatie van bedrijfsprocessen en serviceverlening zijn:

  • Druk op de ‘time-to-market’ leidt tot vervanging van legacy omgevingen door flexibeler architecturen en bankapplicaties. Banken zijn op zoek naar verbeterde ‘agility’ (bijvoorbeeld Service Oriented Architecture en processen om veranderingen sneller door te kunnen voeren) in hun bankomgeving, bijvoorbeeld ten behoeve van het invoeren van nieuwe producten zoals complexe derivaatproducten.
  • Verticale integratie: druk op servicekwaliteit leidt tot vervanging van losstaande front- en backofficeoplossingen tot geïntegreerde oplossingen ten behoeve van ‘straight through’-processing.
  • Horizontale integratie: ten behoeve van optimale en consistente dienstverlening investeren banken in Customer Relation Management-services die hoge eisen stellen aan dataontsluiting uit de centrale bankapplicaties. Legacy systemen die onvoldoende flexibiliteit bieden worden hierbij vervangen door systemen die meer aansluiten op bijvoorbeeld J2EE- of .Net-technologie.
  • De wens om eindgebruikers meer in control te brengen (en minder afhankelijk te laten zijn van IT) bij het beheer van bijvoorbeeld productadministraties (’empowerment of the business’) leidt tot vervanging van systemen.

Aandachtspunten

Binnen de aandachtsgebieden Strategic environment en Business focus zijn bij de implementatie van bankpakketten enkele specifieke attentiepunten van belang:

Business case management

Op basis van de gestelde strategische doelstellingen van een bank is het van belang een business case uit te werken, waarin de te behalen voordelen (baten) met de implementatie van een nieuw bankpakket worden afgezet tegen de benodigde investeringen (kosten). De omgeving van bancaire instellingen is behoorlijk dynamisch met als gevolg dat ook de business case geen statisch gegeven zal zijn. In de praktijk blijkt dat gedurende het project of programma de business case niet of onvoldoende onderhouden wordt ([KPMG05]). Bij veranderende omstandigheden, zoals een ingrijpende conjunctuurverandering of voortschrijdend inzicht als gevolg van nieuwe technologie, wordt weinig expliciet teruggegrepen naar de business case om een toetsing uit te voeren op de validiteit. De situatie kan zich voordoen dat er goede mogelijkheden zijn om het implementatieproject bij te sturen teneinde de business case te optimaliseren.

Het projectmanagement dient dan ook relevante wijzigingen te vertalen in gevolgen voor de business case. Deze vorm van change management kan zowel te maken hebben met de benodigde investering als met de beoogde doelstellingen (zie ‘Benefits management’).

Hierbij is het van belang een expliciete functiescheiding te creëren tussen de eigenaar van het banksysteem en de besluitvoerder over te plegen investeringen. Bij een dergelijke scheiding (tussen portfoliomanagement en programmamanagement) is het mogelijk op objectieve gronden een besluit te nemen over de haalbaarheid en wenselijkheid van projecten waarvan de uitgangspunten voor de business case zijn gewijzigd.

Benefits management

Het (achteraf en gedurende het programma of project) vaststellen van de realisatie van de beoogde doelstellingen is vaak niet goed verankerd in organisaties. Dit zogenoemde benefits management is dan niet expliciet verankerd bij een change of lijnmanager, waardoor een implementatietraject zich beperkt tot het geaccepteerd en operationeel krijgen van het nieuwe systeem ([KPMG05]). Dit resulteert in aanzienlijke risico’s. Allereerst ontbreekt hierdoor cruciale sturingsinformatie gedurende het project ten aanzien van de actualiteit van de business case, met name of deze als gevolg van wijzigingen binnen het project bijgesteld moet worden. Ten tweede loopt men het risico dat het implementatieproject en de geplande ‘benefits’ niet meer op elkaar afgestemd zijn. Dit heeft weer risico’s tot gevolg inzake de tijdige realisatie van de ‘benefits’. Deze ‘benefits’ kunnen zelfs geheel uit beeld raken, waardoor er informatie ontbreekt of de (IT-)investeringen daadwerkelijk de beoogde resultaten hebben opgeleverd voor de organisatie ([Koet05]).

De verantwoordelijkheid voor de te realiseren ‘benefits’, zoals verbetering van ‘straight through’-processing en van de time-to-market, en reductie van operationele kosten, dient bij specifiek daartoe aangewezen change managers binnen het project te worden belegd. Hoe eerder deze rollen worden geïmplementeerd, hoe kleiner de risico’s dat ‘benefits’ niet of niet optimaal worden gerealiseerd.

Project Management

Voor implementatietrajecten van standaard-bankpakketten zijn er enkele specifieke risico’s die kenmerkend zijn voor het aandachtsgebied Project Management.

Business involvement

In het algemeen worden bankprocessen geformeerd rond een front-, mid- en backoffice, zonder dat het eigenaarschap voor de hele procesketen duidelijk is belegd. Voor pakketimplementaties heeft dit tot gevolg dat de adressering van de ‘business’-vertegenwoordiging complex of incompleet is. Symptomen van onvoldoende betrokkenheid vanuit de business zijn dat te weinig medewerkers vanuit de business zijn vrijgemaakt voor het project of dat stuurgroepvergaderingen een puur formeel karakter hebben en materieel weinig bijdragen aan de projectbeheersing. Al eerder hebben we aangegeven dat dit nadelig is voor de afstemming tussen het projectresultaat en de te behalen ‘benefits’. Bijkomend effect is dat de organisatie niet volledig geïnformeerd is en geruchten over het project een eigen leven gaan leiden, waardoor een scheef beeld van het IT-project ontstaat dat van invloed kan zijn op de acceptatie van het nieuwe systeem. Een voorbeeld van een ‘self-fulfilling prophecy’.

Gezocht moet worden naar de optimale vertegenwoordiging in de stuurgroep vanuit de proceseigenaren om draagvlak te creëren voor en richting te geven aan het project.

Stakeholdermanagement

Implementatie van een bankpakket raakt bovengemiddeld veel partijen, waaronder interne belanghebbenden, de Interne Accountantsdienst (IAD) en risk-management- en controlafdelingen, alsmede externe toezichthouders zoals DNB en AFM. Daarnaast is doorgaans sprake van een aantal externe partijen, zoals systeemleveranciers en serviceverleners met betrekking tot betalingsverkeer (zoals Interpay en SWIFT) en beleggingsverkeer (beurs, clearing, brokers, custody). Ten slotte is er ook nog de klant, vaak in diverse gedaanten. Communicatie is bij een bankpakketimplementatie complex en onderschatting hiervan leidt tot projectvertraging, projectfalen en/of afbreukrisico’s.

Bij de start van een bankpakketimplementatie moet men alle partijen die belang hebben bij het project identificeren om te komen tot een intern en extern communicatieplan. Bij grote projecten is het nodig een communicatierol (die moet worden beschouwd als een specifieke deskundigheid) expliciet bij het projectbureau neer te leggen.

Kennismanagement

De te automatiseren bancaire processen en producten worden gekenmerkt door hun complexiteit en diversiteit. De processen in deze sector zijn immers nauwelijks gestandaardiseerd. Het analyseren van deze processen en producten bij implementatie van een nieuw banking backoffice kost vaak veel tijd en is in veel gevallen afhankelijk van kennis bij een beperkt aantal sleutelfiguren.

Deze kennisdragers dient zoveel mogelijk ruimte binnen het project geboden te worden door ze vrij te spelen van hun operationele rollen tot een architect binnen het project.

Projectmanagement

Regelmatig wordt de projectmanager niet zorgvuldig gekozen. Uit capaciteitsgebrek of vrees voor de complexiteit maken banken veelvuldig gebruik van de inhuur van externen met als risico dat bij afronding van het project niet voldoende kennis is opgebouwd in de eigen organisatie. Als er echter gekozen wordt voor een backofficemanager met behoud van lijntaken staat de beschikbare tijd voor het project onder druk. Indien wordt gekozen voor de persoon met de meeste kennis moet men zich afvragen of diens projectmanagementvaardigheden adequaat zijn voor het uit te voeren project. Intern beschikbare projectmanagementvaardigheden zijn niet zelden van onvoldoende niveau.

Wij adviseren de projectmanager zorgvuldig te kiezen en daarbij primair uit te gaan van procesmanagementcapaciteiten. Het is bij het inrichten van de projectorganisatie van belang een onderscheid te maken tussen lijnmanagement (ownership, change management), architectuurmanagement (proces- en IT-kennis) en projectmanagement (projectbeheersing, communicatie). De keuzen voor samenstelling van de projectorganisatie dienen duidelijk gecommuniceerd te worden.

Leveranciersselectie

De leveranciers van de standaard-bankpakketten zijn veelal internationaal georiënteerd. De veelzijdigheid van het aangeboden systeem vertaalt zich in de spreiding van kennis binnen de leveranciersorganisatie. In de regel zijn met name de businessanalisten zeer gewild bij gelijktijdig lopende implementaties. In de praktijk betekent dit dat lokaal niet altijd de gevraagde kennis en ervaring door leveranciers ter beschikking kan worden gesteld aan afnemers.

De keuze van de leverancier is net zo belangrijk als de keuze van het banksysteem. Het is van belang dat banken zeker stellen dat zij van de leverancier voldoende gekwalificeerde medewerkers krijgen ter ondersteuning van de implementatie. Stel vast hoe het bedrijf omgaat met kennismanagement en stel een lijst met kerncompetenties en namen op en hun betrokkenheid bij lopende implementatieprojecten. Hierbij is het ook van belang om vooraf vast te stellen of de leverancier beschikt over een aanpak voor de pakketimplementatie. Ervaring leert dat dit in de praktijk veelal ontbreekt dan wel niet wordt ingevuld.

Beveiliging, continuïteit en interne controle

De tijdige aandacht voor beveiliging, continuïteit en interne controle bij bankpakketimplementaties is vaak onderbelicht dan wel het belang hiervan wordt te laat in het project onderkend. Hierdoor dienen op een later moment tekortkomingen in de beveiliging, continuïteit en interne controle gerepareerd te worden, hetgeen onnodig tot additionele kosten leidt.

Bij het initiëren van het project dienen de vereisten ten aanzien van beveiliging, continuïteit en interne controle, alsmede het houden van aandacht hiervoor gedurende en na afloop van de implementatie van het bankpakketsysteem, te worden vastgelegd. Dit leidt al vroeg tot duidelijkheid over te nemen maatregelen ten aanzien van bijvoorbeeld back-up- en disaster recovery-faciliteiten en investeringen in redundante configuratie van databases en servers. Tevens kan dit leiden tot een goede spreiding van systeem- en functionele kennis van het bankpakket binnen de organisatie. Inzake beveiliging is de Code voor Informatiebeveiliging, recent opnieuw uitgegeven door ISO, een goede leidraad.

Solution Management

Ten aanzien van het aandachtsgebied Solution Management is bij implementatietrajecten van standaard-bankpakketten een aantal specifieke attentiepunten van belang. Bij Solution Management gaat het om de realisatie van de gestelde projectdoelstellingen en -activiteiten.

Conversiestrategie

Tenzij er sprake is van een ‘greenfield-operatie’ (een situatie waarbij het niet gaat om een overgang vanuit een operationeel bronsysteem naar het nieuwe systeem) houdt implementatie van een bankpakket in dat er een dataconversie plaatsvindt. De complexiteit van dataconversietrajecten wordt veelal onderschat. Tevens wordt bij de projectdefinitie geen analyse gemaakt van de benodigde resources en doorlooptijd voor conversie. Het resultaat kan zijn dat de implementatie een onverwacht lange conversievoorbereiding en testfase nodig heeft, wat geen reclame is voor het project binnen de organisatie en veelal leidt tot uitloop in de planning.

Bij de leveranciersselectie dienen de eisen ten aanzien van de doorlooptijd voor systeemimplementatie te worden geformuleerd en vertaald te worden naar de te selecteren oplossing. Bij een relatief nieuw systeem dat qua architectuur, structuur en datamodel sterk afwijkt van het bestaande banksysteem, zal sneller gekozen worden voor een incrementele conversie met een periode van schaduwdraaien. Indien de keuze valt op een leverancier met een ‘proven track record’ voor conversies vanuit het bronsysteem, kan gekozen worden voor een kortere conversieperiode met behulp van geautomatiseerde export- en importtools. Het draait hierbij om de vraag in hoeverre er kennis aanwezig is van het datamodel en de functionele inrichting van bron- en doelsysteem om een volledige, semantisch correcte data mapping te maken.

‘Empowerment of the business’

Vanuit eisen ten aanzien van ‘time-to-market’, ‘IT agility’ en ‘IT cost control’ zijn flexibele bankpakketten populair. De idee hierbij is dat de eindgebruiker zelf in verregaande mate in staat moet zijn nieuwe functionaliteit toe te voegen, zoals rapportages, ‘business rules’, en nieuwe producten zoals kredietconstructies en beleggingsinstrumenten. Valkuil hierbij is dat de complexiteit van dergelijke pakketten wordt onderschat. Het risico is dat de doorlooptijd van implementaties tegenvalt en ook na implementatie veel tijd nodig is om tot volledige benutting van het banksysteem te komen.

Bij een strategie tot implementatie van een bankpakket met een enorm datamodel en end user tools om dit datamodel nader in te richten, dient rekening te worden gehouden met investeringen in prototyping en training van eindgebruikers. Ook moet men zich afvragen of de eindgebruiker (bijvoorbeeld een backoffice voor derivatentransactieverwerking) over de capaciteiten beschikt om het nieuwe systeem in beheer te nemen. Aanvullend moet worden onderkend dat bij een dergelijk systeem de conversie complex zal zijn en veel inspanning zal kosten.

Proces- en data-analyse

De impact van een standaard-bankpakketimplementatie wordt onderschat voor wat betreft de benodigde voorbereiding. Er wordt te weinig aandacht besteed aan de data- en procesanalyse (‘as-is’-situatie versus ‘to be’-situatie). Dit heeft als risico dat vanwege de grote flexibiliteit van de pakketten, de parametersetting (bouw) van het pakket bemoeilijkt wordt c.q. vertraging oploopt, internecontrolestructuren niet worden ingebouwd, het pakket niet optimaal benut wordt ter ondersteuning van de processen en gewenste functionaliteit ‘vergeten’ wordt c.q. niet gerealiseerd kan worden (‘point of no return’).

Ook voor het implementeren van een bankpakket is het van belang om na te denken over een data- en procesontwerp. Er dienen keuzen te worden gemaakt over het al dan niet voeren van bepaalde producten, maar ook het maken van keuzen ten aanzien van de wijze van procesinrichting (interne controlestructuren) is van belang.

Architectuurrol

Al eerder is het belang aangegeven van het mobiliseren van kennis inzake bankprocessen en banksysteemarchitectuur. Gezien de veelheid en complexiteit van processen en interfaces is kennis vaak gefragmenteerd verspreid binnen de organisatie. De inhuur van externe capaciteit vergroot het risico dat kennis intern niet voldoende gestructureerd wordt opgebouwd.

Bij het opzetten van de projectorganisatie dienen architectuurrollen expliciet te worden benoemd. Deze rollen creëren het overzicht over complexe oplossingen en bewaken de consistentie van ontwerpvoorstellen bij bankpakketimplementatie. Afhankelijk van de scope van de bankpakketimplementatie kan het goed zijn deze rol op te splitsen. Doorgaans is het wel nodig aparte rollen te definiëren voor applicatiearchitectuur (inclusief datamodellering en security), infrastructuur (beschikbaarheid en continuïteit) en business (processen).

People Management

Bij People Management gaat het om factoren zoals de opleiding van de gebruikersorganisatie in het nieuwe pakket en de betrokkenheid van de gebruikersorganisatie. In dat kader kent bankpakketimplementatie geen specifieke issues vergeleken met andere organisaties.

In de praktijk is geconstateerd dat er sprake is van een spanningsveld tussen de door medewerkers uit te voeren lijnactiviteiten en de projectactiviteiten. Hierdoor ontstaat het risico dat de op te leveren ‘projectdeliverables’ kwalitatief niet aan de eisen voldoen. Aanvullend bestaat het risico dat opleveringen niet plaatsvinden overeenkomstig de opgestelde planning.

Wij adviseren om voldoende resources beschikbaar te stellen ten behoeve van deze projecten en deze resources bij voorkeur voor een vooraf vastgesteld aantal uren toe te wijzen aan het project. De uitnutting van de gebudgetteerde projecturen en uit te voeren activiteiten dient actief bewaakt te worden door de projectmanager.

Bij het invoeren van een nieuw bankpakket dat veelal leidt tot organisatorische veranderingen of zelfs banenverlies is het van belang om eventuele weerstand vanuit de gebruikersorganisatie te managen. Een goede communicatie vanuit het project maar ook vanuit de lijnorganisatie is hierbij essentieel. Tevens is het belangrijk dat gebruikers tijdig training ontvangen in het nieuwe bankpakket om de acceptatie hiervan te vergroten.

Conclusie

De implementatie van een standaard-bankpakket gaat gepaard met risico’s die kunnen leiden tot vertragingen, het niet bereiken van de oorspronkelijke doelstellingen en een toename van de gestelde kosten. Helaas is in de praktijk geconstateerd dat veel van de in dit artikel genoemde risico’s zich hebben voorgedaan bij implementatietrajecten bij bancaire instellingen. Juist vanwege de complexiteit van een bancaire omgeving (diversiteit in bankproducten en bankprocessen) in combinatie met de ‘flexibiliteit’ van standaard-bankpakketten vraagt dit soort projecten om een gedegen voorbereiding van zowel de projectmatige aspecten (zoals inrichting van de projectorganisatie) als de materiële aspecten (zoals het uitwerken van een data- en procesanalyse). Naast een goede en gedegen voorbereiding dienen ook voorwaarden te worden gesteld gedurende de projectuitvoering (heldere eisen ten aanzien van de inrichting van het pakket, aandacht voor de beveiliging, voor het beheer en voor de projectaansturing en -monitoring). Een gebalanceerde beheersing van de diverse risicofactoren zal leiden tot een succesvolle afronding van deze bovengemiddeld risicovolle en kostbare projecten.

Belangrijke beheersingsfactoren die in dit artikel aan de orde zijn geweest, zijn de betrokkenheid van de eindgebruiker, de keuze van de projectmanager, de eisen aan het nieuwe banksysteem, de complexiteit van de oplossing, de borging van kennis en de wijze van conversie. Het lijken ‘open deuren’ maar de praktijk toont anders aan. De in dit artikel opgesomde risico’s en aanbevelingen kunnen door u als een ‘lessons learned’-overzicht worden gehanteerd om na te gaan of er risico’s zijn die actueel zijn, dan wel kan dit overzicht worden gebruikt als risicoanalyse bij het opstarten en monitoren van een project tot implementatie van een bankpakket.

Een projectinitiatie waarbij de keuzen expliciet worden gemaakt, is een goede basis voor een beheerste implementatie. Hiervoor dient de bank voldoende kennis en ervaring te mobiliseren. Het moge duidelijk zijn dat, gezien de belangen, kosten en risico’s, deze kennis en ervaring stevig verankerd dienen te zijn en dat binnen de projectorganisatie bijzondere aandacht nodig is voor de beschreven risico’s.

Literatuur

[Koet05] Ir. H.H. Koets, mw. ir. K. Manschot RE en drs. H.B. Moonen MBA, Grip op effectief realiseren van veranderingen, Compact 2005/4.

[KPMG05] KPMG, International Programme Management survey, 2005.

[KPMG06] KPMG, Project Risk Assessment Methodiek, 2006.

Implementatie internal control framework: een energierijke inspanning

De liberalisering van de energiesector heeft als gevolg dat de verschillende organisaties binnen de sector onderling afhankelijk zijn geworden ten aanzien van de betrouwbaarheid van de processen. Hiermee stelt de liberalisering dan ook aanvullende eisen aan de inrichting en beheersing van de processen en systemen. Voor het realiseren van een geliberaliseerde energiemarkt echter zijn de processen en systemen binnen de organisaties drastisch gewijzigd. Het uitwerken en implementeren van ingrijpende proces- en systeemwijzigingen die ook nog eens voldoende de betrouwbaarheid waarborgen, is dan ook een complexe en omvangrijke opgave. De energiesector is daarom enkele jaren geleden al gestart met trajecten om de betrouwbaarheid van zijn processen te verbeteren.

Klik op het pdf-symbool om het volledige artikel te bekijken.

SOX – Scoping van de relevante ICT

In dit artikel wordt de werkwijze uiteengezet voor het vaststellen van de relevante ICT in het kader van SOX. Het is aan de ICT-auditor om vast te stellen of deze ICT zwakheden bevat betreffende het ontwerp of de werking, waardoor zogenaamde deficiënties met de accountant dienen te worden afgestemd.

Inleiding

Veel bedrijven hebben de afgelopen twee jaar geïnvesteerd in het documenteren en implementeren van Internal Controls over Financial Reporting (ICOFR), in verband met de Sarbanes-Oxley Act (SOX). De ICOFR betreffen beheersingsmaatregelen die de integriteit van de externe financiële verslaggeving waarborgen.

Eén van de uitdagingen van SOX is het vaststellen van de maatregelen die relevant zijn in het kader van ICOFR, hetgeen ook wel scoping wordt genoemd. Voor ICT in het bijzonder blijkt scoping als complex te worden ervaren. Hiervoor is een aantal oorzaken aan te wijzen:

  • het ontbreken van concrete theorie achter de wet- en regelgeving waarin de relatie tussen ICOFR en beheersing van ICT eenduidig wordt aangegeven;
  • de onder verschillende personen verdeelde kennis betreffende de samenhang tussen processen, applicaties en ICT, evenals de aan deze objecten verbonden risico’s;
  • de complexe relatie tussen de betrouwbaarheid van de financiële verslaggeving en ICT-maatregelen.

In dit artikel wordt een aanpak behandeld voor de scoping van de voor financiële verslaggeving relevante ICT-maatregelen, met inachtneming van publieke standaarden én de KPMG-werkmethoden die in de auditpraktijk zijn ontwikkeld.

Relevante wet- en regelgeving

De Amerikaanse beursautoriteit SEC (Security & Exchange Committee) heeft met de invoering van SOX een speciaal orgaan in het leven geroepen dat is belast met het opstellen van auditstandaarden en het zorg dragen voor de naleving van de auditstandaarden: de Public Company Accounting Oversight Board (PCAOB).

De PCAOB heeft met Auditing Standard 2 aangegeven op welke wijze de kwaliteit van Internal Controls over Financial Reporting (ICOFR) dient te worden beoordeeld. De standaard betreft een nadere uitwerking van de eisen uit de SOX404-wetgeving en bevat voorschriften die door externe auditors dienen te worden nageleefd.

In de PCAOB Standard 2 wordt specifiek ingegaan op de scoping van ICT voor SOX:

  • Artikel 40: ‘the auditor should determine whether management has addressed the following elements: … controls, including information technology general controls, on which other controls are dependent. …’
  • Artikel 50: ‘… information technology general controls over program development, program changes, computer operations, and access to programs and data help ensure that specific controls over the processing of transactions are operating effectively. …’

Afbakening van de relevante ICT

De scoping van de relevante ICT betreft twee activiteiten:

  1. het vaststellen van de key applicaties;
  2. het vaststellen van de aan key applicaties gerelateerde ICT.

Vaststellen key applicaties

De scoping vangt aan met een (strategische) analyse van de organisatie als geheel. Dit betreft onder andere de analyse van de mate van homogeniteit van organisatieonderdelen en de mate van (de)centralisatie, kritieke bedrijfsprocessen en externe en interne factoren ([Brou03]). Deze analyse resulteert in een overzicht van de relevante entiteiten en processen.

Voor de relevante processen worden de key proces controls gedefinieerd, die in samenhang de integriteit van financial reporting waarborgen.

De key proces controls zijn een mix van preventieve en detectieve maatregelen, samengesteld op basis van een risicoanalyse. De key proces controls waarborgen met een redelijke mate van zekerheid dat fouten worden voorkomen en/of (tijdig) worden gedetecteerd en gecorrigeerd. De key proces controls vallen uiteen in handmatige controls en applicatie controls.

Via de key applicatie controls worden de key applicaties geïdentificeerd. Hiertoe wordt vastgesteld welke (delen van) applicaties de key applicatie controls bevatten. Vervolgens wordt het samenstel van handmatige en applicatie controls geëvalueerd, rekening houdende met de gewenste mix van preventieve en detectieve maatregelen. Als gevolg hiervan kunnen mogelijk applicaties worden uitgesloten van de resulterende scope, als na evaluatie blijkt dat slechts in beperkte mate op een applicatie wordt gesteund in relatie tot key proces controls.

De key applicaties kunnen zowel financiële als operationele systemen betreffen.

C-2005-3-Kornelisse-01

Figuur 1. Stappen bij het vaststellen van de key applicaties.

Vaststellen van aan key applicaties gerelateerde ICT

De aan key applicaties gerelateerde ICT-componenten worden vastgesteld door het analyseren van de impact die ICT-componenten hebben, zowel op de integriteit van de dataverwerking door key applicaties, als op de integriteit van de door deze key applicaties bewerkte en opgeslagen data.

De ICT kan in een aantal groepen worden verdeeld:

  • Primaire ICT: de toegepaste ICT op het pad vanaf de werkplek van de gebruiker tot en met de opslag van de data, waarmee een specifieke applicatie wordt ondersteund.
  • Secundaire ICT: de ICT die niet direct kan worden toegerekend aan het pad van de gebruiker tot de data, maar wel noodzakelijk is voor het functioneren van de applicatie. Dit is het deel van de ICT dat niet voor een specifieke applicatie aanwezig is, maar dat voor meerdere applicaties wordt toegepast (bijvoorbeeld het interne netwerk). Deze generieke ICT wordt ook wel aangeduid als ICT-infrastructuur.
  • Tertiaire ICT: de ICT die de naleving van maatregelen controleert betreffende de primaire en de secundaire ICT, door het controleren van systeeminstellingen en het controleren van optredende gebeurtenissen. De tertiaire ICT is van belang, juist omdat vanuit de PCAOB wordt gevraagd om testing of operating effectiveness. Hiertoe dient een organisatie zelf de naleving van ICT-maatregelen te controleren.
Vaststellen primaire ICT

Op het logische toegangspad van de gebruiker tot de data bevinden zich de volgende primaire ICT-componenten die voor een applicatie specifiek zijn ingericht:

  • applicatie;
  • database/DBMS;
  • besturingssysteem.

Het waarborgen van de naleving van functiescheidingen vereist dat beveiliging op alle lagen van de ICT is gewaarborgd ([Bink05]).

In kader 1 wordt een voorbeeld gegeven van het logische pad voor een gebruiker die SAP R/3 benadert.

Kader 1. Voorbeeld van logisch toegangspad.

Pc > Applicatie client > Applicatie server > Database server

Een eindgebruiker logt aan op een Windows-pc, start de grafische schil van de client-serverapplicatie (SAPGUI) en logt aan met een persoonlijk account naar de SAP-applicatie op de server. De toegang tot applicatiegegevens wordt geregeld via de autorisaties binnen de SAP R/3-applicatie. Vervolgens zal de SAP R/3-applicatie ‘namens’ de gebruiker de database benaderen. De gebruiker heeft hierdoor niet een directe toegang tot de database.

Dit logische toegangspad gaat alleen uit van het gewenste logische toegangspad. Ook is het mogelijk dat een gebruiker een ander pad volgt. Mogelijk kan de gebruiker de database direct benaderen, buiten de SAP-applicatie om, gebruikmakend van een toegangspad buiten Windows en/of SAP om.

Alle mogelijke logische toegangspaden dienen te worden onderzocht om er zeker van te zijn dat in voldoende mate gesteund kan worden op de primaire ICT, teneinde de vanuit de key controls vereiste functiescheidingen af te dwingen.

Vaststellen secundaire ICT

Secundaire ICT betreft de ICT die niet direct kan worden toegerekend aan het pad van de gebruiker tot de data (zie kader 2). Dit is het deel van de ICT dat niet voor een specifieke applicatie aanwezig is, maar dat voor meerdere applicaties wordt toegepast (bijvoorbeeld het interne netwerk). De generieke ICT wordt ook wel aangeduid als ICT-infrastructuur.

Kader 2. Secundaire ICT.

Beveiligingsstandaarden

Aangaande ICT wordt verwacht dat de organisatie inrichtingseisen (security baselines) heeft gedefinieerd. Hiermee kan worden gewaarborgd dat ICT-componenten uniform en op een bewust overwogen beveiligingsniveau worden ingericht. Het opstellen van security baselines is een omvangrijke activiteit. Organisaties dienen een samenhangend stelsel van baselines te hebben, dat als basis dient voor een veilige ICT.

Indien een organisatie geen beveiligingsstandaarden zou toepassen, dan zou elke ICT-component ad hoc dienen te worden ingeregeld, waardoor borging van de beveiliging op elk van de ICT-componenten niet meer zou zijn te realiseren.

Intern netwerk, interne netwerkscheidingen, externe netwerkkoppelingen

Binnen interne netwerken wordt er veelal van uitgegaan dat ICT-componenten zich binnen het interne netwerk bevinden. Bijgevolg worden minder stringente beveiligingseisen gesteld aan de beveiliging van een ICT-component in een intern netwerk, dan wanneer een ICT-component aan een extern netwerk zoals internet zou zijn gekoppeld. Wij achten het dan ook veelal van belang de beheersing van externe koppelingen evenals de feitelijke implementatie van deze koppelingen binnen de scope van SOX te plaatsen.

Interne netwerkscheidingen zijn eveneens van belang, bijvoorbeeld tussen een datacentrum en het interne netwerk waarop de gebruikers zich bevinden.

Ook is het van belang gescheiden omgevingen te hebben voor ontwikkeling, testen en productie, om te voorkomen dat programmatuur en gegevens ongewenst tussen deze omgevingen worden uitgewisseld, waardoor de integriteit van programmatuur en gegevens kan worden geschaad.

Werkplekcomputers

Via pc’s kunnen gebruikers zich onder het pc-besturingssysteem authenticeren en kunnen onder andere transacties worden ingevoerd. Als de pc door een ongeautoriseerde gebruiker kan worden overgenomen, dan is het voor deze ongeautoriseerde gebruiker mogelijk transacties te wijzigen. Het is dan ook van belang dat pc’s afdoende zijn beveiligd.

Voorbeelden van maatregelen op een pc zijn: authenticatievoorzieningen met gebruik van tokens, voorzieningen tegen het ongeautoriseerd wijzigen van applicaties (beveiligde implementatie van het besturingssysteem), en de implementatie van een personal firewall en anti-virusprogrammatuur.

Identificatie-, authenticatie- en autorisatieservices

Een computernetwerk beschikt over een aantal ogenschijnlijk onzichtbare services die zeer veel worden gebruikt. Denk hierbij onder andere aan DNS-servers waarmee de conversie tussen computernamen en -nummers plaatsvindt, evenals Radius-servers waarmee gebruikers worden geauthenticeerd.

Uit efficiëntieoverwegingen en vanuit de behoefte aantoonbaar ‘in control’ te zijn, benutten applicaties steeds meer centraal aanwezige identificatie-, authenticatie- en autorisatieservices.

Als dergelijke services niet zouden worden meegenomen binnen de scope van SOX, dan is het veelal niet mogelijk activiteiten te herleiden tot unieke personen.

Programmeereisen

Met programmeereisen kunnen ontwikkelaars worden ondersteund bij het voorkomen van het introduceren van zwakheden in de programmacode, die kunnen leiden tot ongeautoriseerde toegang tot gegevens, evenals onjuiste of onvolledige verwerking van gegevens ([OWAS]).

Checksumcontrole

Om aantoonbaar ‘in control’ te zijn, kan de juiste verwerking van wijzigingen worden gecontroleerd door het verrichten van deelwaarnemingen. Hiermee kan echter niet de volledigheid van de daadwerkelijk uitgevoerde wijzigingen in kaart worden gebracht. Met behulp van bijvoorbeeld checksums zou wel kunnen worden gecontroleerd dat alleen geautoriseerde wijzigingen zijn uitgevoerd. Een checksum is een code die uniek is voor een set van data of een programma, en die wordt bepaald door een dusdanige berekening uit te voeren op de binaire informatie van een set van data of een programma, dat een wijziging aantoonbaar resulteert in een andere checksum.

Hulpmiddelen voor release- en versiebeheer

Organisaties maken tegenwoordig veelal gebruik van hulpmiddelen voor het beheren van verschillende versies van programmatuur, evenals voor het wijzigen van versies van programmatuur, van de ontwikkel- naar de test-, en van de test- naar de productieomgeving. Om de integriteit van programmatuur te waarborgen is het dan ook van belang deze hulpmiddelen als onderdeel van de scope van SOX te zien.

Beheeromgeving en -netwerk

ICT-componenten werden in het verleden veelal via een lokaal aanwezige terminal beheerd. Tegenwoordig vinden de beheeractiviteiten van beheerders echter veelal plaats via een netwerkverbinding. De netwerkverbinding kan lopen via het reguliere interne netwerk (in-band) en via een speciaal beheernetwerk (out-of-band).

Beheerders benaderen de ICT-componenten steeds vaker niet direct vanaf de eigen werkplek via het interne netwerk, maar in-band vanaf de eigen werkplek naar een zogenaamde stepping stone (een beheerplatform), waarop wordt ingelogd en vervolgens wordt doorgelogd naar het te beheren object.

Het is van belang de beheeromgeving en het beheernetwerk als onderdeel van de scope van SOX te definiëren, als voor de beveiliging van de applicaties en gegevens wordt gesteund op de beveiliging van de beheeromgeving en het beheernetwerk.

Verscheidene ICT-risicogebieden kunnen worden onderkend, die een wezenlijke invloed hebben op de beveiliging van het pad van de gebruiker naar de data, en die secundaire ICT betreffen (zie tabel 1).

C-2005-3-Kornelisse-02

Tabel 1. Risicogebieden met betrekking tot secundaire ICT.

Vrijwel alle organisaties beschikken over secundaire ICT. Voor SOX zullen deze organisaties moeten vaststellen of een (beveiligings)deficiëntie betreffende de secundaire ICT-component een relevante impact kan hebben op de primaire ICT. Indien hiervan sprake is, dan dient die secundaire ICT-component te worden opgenomen in de SOX-scope.

Vaststellen tertiaire ICT

Voor compliance aan SOX 404 is het van belang dat de organisatie aantoonbaar ‘in control’ is. Dit niveau van control is in figuur 2 in perspectief geplaatst.

C-2005-3-Kornelisse-03

Figuur 2. Volwassenheid van maatregelen.

Als de ICT aantoonbaar ‘in control’ is, dan bestaat een stelsel van preventieve en detectieve ICT-maatregelen ([Korn04]). De ICT-maatregelen die key proces controls wezenlijk ondersteunen, dienen dan te worden gecontroleerd op naleving. Denk bijvoorbeeld aan controle van primaire en secundaire ICT-componenten betreffende de implementatie van security baselines voor besturingssystemen en de wijze van inloggen door beheerders op ICT-componenten.

De monitoring van de ICT omvat de controle en rapportage inzake de geïmplementeerde parameters voor relevante ICT-componenten (bijvoorbeeld beveiligingsparameters binnen applicaties, middleware, databasemanagementsystemen, besturingssystemen en netwerkcomponenten). Uit alle ICT-componenten kan data worden geëxtraheerd, zowel betreffende de optredende gebeurtenissen (logging) als voor wat betreft de status (bijvoorbeeld mate van compliance aan een beveiligingsstandaard).

De gegevens betreffende optredende gebeurtenissen en statussen kunnen worden verzameld, geanalyseerd, gerapporteerd en gearchiveerd.

Intussen hebben veel bedrijven onderkend dat het integraal en systematisch verwerken van dergelijke monitoringgegevens een structurele aanpak vraagt. Het is niet afdoende onafhankelijk van de te stellen eisen aan de ICT, logging te activeren en de status van ICT-componenten te meten.

Monitoring dient plaats te vinden op basis van de aan ICT gestelde eisen. Voor elk van de vastgestelde eisen moet worden bepaald of en zo ja, op welke wijze monitoring kan plaatsvinden.

Rekening houdende met het grote volume aan monitoringgegevens dat hiermee wordt verzameld, is het tevens van belang hulpmiddelen in te zetten om informatie bij de bron (de ICT-componenten) te verzamelen en voorzover mogelijk centraal te verwerken. Tot slot moet worden overwogen gedurende welke periode logging dient plaats te vinden.

C-2005-3-Kornelisse-04

Figuur 3. Verwerking van logging.

Tot slot

De scoping van ICT begint bij het vaststellen van de key proces controls inclusief de key applicatie controls. Via de key applicatie controls worden de key applicaties bepaald. Vervolgens wordt nagegaan welke ICT een relevante impact heeft op de data en programmatuur van key applicaties.

Bij de selectie van de voor SOX relevante ICT dient in de eerste plaats te worden uitgegaan van de primaire ICT, de ICT op het pad van de gebruiker tot de data die een bedrijfsfunctie automatiseert.

Daarnaast dient secundaire ICT expliciet te worden opgenomen binnen de scope van SOX, als deze een relevante impact heeft op de primaire ICT en daarmee op key applicaties.

Tevens dient tertiaire ICT (monitoring) te worden opgenomen binnen de scope. Het inrichten van monitoring van de ICT vraagt allereerst om een bewuste visie ten aanzien van de principes volgens welke monitoring dient plaats te vinden: betreffende welke eisen dient controle op naleving van ICT-maatregelen plaats te vinden, voor welke systemen dient de naleving te worden gecontroleerd, op welke wijze dient de ICT te worden aangepast om monitoring van diezelfde ICT te waarborgen?

Als bij een audit in het kader van SOX 404 blijkt dat ICT-component controls niet adequaat zijn, dan moet op basis van een risicoanalyse de impact van een ICT-deficiëntie worden vertaald naar het effect op gerelateerde key proces controls van een organisatie. Besef hierbij dat primaire ICT veelal betrekking heeft op één of slechts enkele key applicatie controls, terwijl secundaire en tertiaire ICT betrekking hebben op (vrijwel) alle key applicatie controls.

Literatuur

[Bink05] Ing. L. Binken en A.A. van Dijke, Beoordeling van de beveiliging van Oracle-databases, Compact 2005/3.

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

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

[OWAS] OWASP, www.owasp.org.

[PCAO04] PCAOB, Standard 2, PCAOB, 2004.