Rol(len) van de (IT-)auditor in projecten

Transcriptie

1 Informatiesystemen Rol(len) van de (IT-)auditor in projecten Drs. Sam C.J. Huibers EMIA RO Dit hoofdstuk heeft ten doel om een overzicht te geven van de soorten rollen die de (IT-)auditor in projecten zou kunnen vervullen. Na een korte introductie in paragraaf 1 komen in paragraaf 2 aan de orde de assurance rol, de adviserende rol en de participerende rol. Tevens wordt in paragraaf 3 ingegaan op de randvoorwaarden en de rollen die de auditor niet kan vervullen. Centraal staat dat de auditor in een vroeg stadium bij de projecten wordt betrokken. In dit hoofdstuk worden tevens praktische richtlijnen en voorbeelden uit de praktijk gegeven. Aan het slot van het hoofdstuk worden referenties naar gehanteerde literatuur gegeven en wordt een opgave gedaan van relevante websites. Dit hoofdstuk wordt in het bijzonder aanbevolen voor (IT-)-auditors en studenten. De Redactie 1. Introductie In een veranderende omgeving als gevolg van globalisering, toenemende internationale concurrentie en aanscherping van wet- en regelgeving zien veel organisaties zich genoodzaakt hun strategie te herzien en de organisatie, processen en systemen aan te passen. Deze veranderingen worden vaak geïmplementeerd door middel van grote projecten. In zeer veel projecten speelt IT een belangrijke rol en is onlosmakelijk met de invoering van nieuwe processen verweven. Er zijn talrijke voorbeelden van IT-projecten waarvan een deel van de doelstellingen niet wordt gerealiseerd, het budget fors wordt overschreden, of die geheel mislukken. ERP-implementaties brengen risico s van grote operationele verstoringen met zich mee, zoals het niet kunnen verwerken en leveren van de klantorders. Zo heeft bijvoorbeeld een falende ERP-implementatie bij één van de grootste voedselfabrikanten ter wereld geleid tot twee winstwaarschuwingen en een daling van de aandelenkoers van 27% (GTAG 2009). Steeds vaker wordt een beroep gedaan op de IT-auditor om aanvullende zekerheid te verschaffen teneinde deze projecten in goede banen te leiden. Om die reden wordt in dit hoofdstuk van het Handboek EDP-auditing aandacht besteed aan de vraag welke rollen een auditor in projecten kan vervullen en welke beperkingen daarbij gelden. Doel van dit hoofdstuk is om een overzicht te geven van de soorten rollen die de IT-auditor in projecten zou kunnen vervullen, te weten: de assurance rol, de adviserende rol, alsmede de participerende rol. Daarbij staat centraal dat de auditor al in een vroeg stadium bij het project betrokken kan worden in plaats van achteraf de balans op te moeten maken. In het hoofdstuk worden tevens praktische richtlijnen gegeven met betrekking tot randvoorafl. 43 (juni 2012)

2 waarden bij adviserende en participerende rollen in het kader van de onafhankelijkheid van de (IT-)auditor. Verder wordt ingegaan op de rollen die de auditor niet kan vervullen, omdat hij anders op de stoel van het management zou gaan zitten. Eén en ander wordt nader toegelicht aan de hand van voorbeelden uit de praktijk. Voor een overzicht van soorten audits wordt verwezen naar hoofdstuk 5314 Soorten projectaudits in dit handboek (Peter Hartog 2012). 2. Overzicht rollen van de (IT-)auditor in projecten 2.1 Algemene ontwikkeling rol van de auditor Oorspronkelijk richtte de rol van de auditor zich in veel organisaties vooral op de betrouwbaarheid van de financiële rapportage in het kader van de jaarrekening. Medio jaren 80 ontstond een trend naar de uitbreiding van de reikwijdte van de activiteiten gericht op de effectiviteit van de interne operationele processen, al dan niet financieel van aard. Daarbij kwam het verschaffen van aanvullende zekerheid met betrekking tot het realiseren van de ondernemingsdoelstellingen meer centraal te staan. De blik van de auditor verruimde van financiële rapportage naar onder andere het realiseren van doelstellingen, procesbeheersing en risicomanagement (COSO ERM). De Angelsaksische managementbenadering van de jaren negentig, gericht op het integreren van de auditactiviteiten, werd de volgende stap in de ontwikkeling van de auditfunctie. Door de toenemende mate van automatisering van bedrijfsprocessen heeft de IT-auditor een essentiële rol gekregen. Zo kan hij de beheerkaders in de organisatie van de applicatie- en infrastructuuromgeving toetsen, zoals de effectiviteit van security, incident en change managementprocessen (bijvoorbeeld ISO en ITIL) 1. Daarnaast heeft de IT-auditor een steeds belangrijker aandeel in de auditwerkzaamheden als het bijvoorbeeld gaat om het beoordelen van de opzet, bestaan en effectief werken van beheersmaatregelen van processen en systemen in een onderneming. Een specifiek aandachtspunt van de IT-auditor is te toetsten of het systeem voldoet aan eisen en/of kwaliteitsaspecten. Met het door de jaren heen toenemend aantal projecten met een grote IT-component rijst de vraag welke rol(len) de IT-auditor in deze projecten zou kunnen vervullen. Het fenomeen projecten als zodanig is niet nieuw, maar er zijn wel belangrijke verschuivingen geweest in de benadering van de toegevoegde waarde van de auditor (added value). Het blikveld van de auditor was oorspronkelijk meer naar het verleden gericht (retrospectief) door te beoordelen wat niet goed is gegaan in een project. Om meer toegevoegde waarde te hebben is een meer prospectieve benadering van belang waarbij tussentijdse bijsturing nog mogelijk is. Hierbij staat centraal op welke wijze de IT-auditor in een vroegtijdig stadium van het project kan worden betrokken en zijn kennis actief kan inbrengen. Om die reden wordt ook nader ingegaan op de rol van de auditor in verschillende fasen van het project. In paragraaf 2.2 komen eerst de soorten rollen van de (IT-)auditor in projecten aan de orde. 2.2 Rollen van de (IT-)auditor in projecten Context en definities In deze subparagraaf worden een aantal algemene aspecten toegelicht om vervolgens, in de volgende subparagraaf, de rol van de auditor in projecten te kunnen positioneren. Aan de hand van het zogenoemde lines of defense model wordt eerst hieronder de rolverdeling in perspectief

3 geplaatst. Daarbij zal verder worden ingaan op het onderscheid tussen Quality Control en Quality Assurance en de begrippen project versus programma. Lines of defense In een organisatie zien we veelal een lines of defense -model met de volgende verdedigingslinies 2 : First line of defense (eerste lijn): dit is het lijnmanagement dat direct verantwoordelijk is voor het risicomanagement en beheersing van de onder haar ressorterende processen. Second line of defense (tweede lijn): bestaande uit functies en/of afdelingen die het verantwoordelijke lijnmanagement ondersteunen (bijvoorbeeld verbijzonderde (groeps-)afdelingen voor risicomanagement, compliance, en interne controle) bij risicobeheersing. Third line of defense (derde lijn): is de internal auditfunctie die onder andere de inrichting en werking van de eerste en tweede lijn controleert. De externe auditor wordt niet in alle modellen genoemd, maar kan op zijn beurt als de vierde lijn van defense worden benoemd. Fourth line of defense (vierde lijn): de externe auditor die kan steunen op werkzaamheden van de derde lijn. Om een concreet voorbeeld te geven voor de mogelijke rol van een IT-auditor aan de hand van dit model: business control (tweede lijn) is betrokken bij het opstellen van beheersmaatregelen in een herontwerpproject van het rapportageproces, zoals het opstellen van procedures voor de financiële consolidatie. De interne IT-auditor (derde lijn) evalueert de volledigheid van de beheersmaatregelen bijvoorbeeld door de balans tussen preventieve maatregelen (system controls) en corrigerende maatregelen (correctie van cijfers op basis van door de proceseigenaar opgestelde doelstellingen) te beoordelen. De externe auditor (vierde lijn) kan de werkzaamheden van de interne auditor reviewen ten einde vast te stellen in hoeverre hij daarop kan steunen bij de werkzaamheden in het kader van de jaarrekeningcontrole. De externe IT-auditor kan daarbij bijvoorbeeld de effectiviteit van de IT-controls in de financiële systemen toetsen in het kader van de beoordeling van de jaarrekening. Bovenstaande voorbeelden zijn redelijk zwart/wit en dienen met name om het lines of defense - model te illustreren. In de gedachte van het lines of defense -model beperkt de rol van de externe accountant (vierde lijn) zich veelal tot werkzaamheden vanuit de wet met betrekking tot de financiële verslaggeving in het kader van de jaarrekening en SOx. Benadrukt wordt dat bij de afweging welke externe deskundige(n) in projecten te betrekken de keuze zeker niet noodzakelijkerwijs tot de externe accountant beperkt hoeft te blijven. Hierop wordt nader ingegaan in de volgende subparagraaf. Rol interne en externe auditor in projecten Er zijn diverse factoren die een rol kunnen spelen om één of meer externe partijen in een project te betrekken. Hierbij kunnen onder andere zaken als expertise, kennis van de organisatie, onafhankelijke positie, ervaring met soortgelijke projecten en capaciteit een rol spelen. Uitgangspunt is dat, in beginsel, een externe auditor dezelfde rollen zou kunnen vervullen in projecten als de interne auditor. Daarbij dient in het kader van dit hoofdstuk de term externe auditor in brede zin te worden gezien. Dit kan mogelijk de eigen accountant zijn of een accountant of auditor van een ander accounts- en advieskantoor dat diensten verleend aan de organisatie. Een belangrijke

4 kanttekening is hier op zijn plaats. Voor zover een project veranderingen beoogt in de processen en systemen ten behoeve van de totstandkoming van de jaarrekening kan het in ieder geval raadzaam zijn de eigen externe accountant reeds in de ontwerpfase te informeren. Dit kan effectiever zijn dan te wachten tot het project is afgerond en de projectresultaten een voldongen feit zijn. Op deze wijze is de externe accountant alvast op de hoogte van de komende veranderingen en kan hij zijn auditstrategie hierop afstemmen. Bij de toebedeling van projecttaken is het uiteraard van belang te voorkomen dat zich inefficiënties voordoen en rollen elkaar overlappen. Bij het maken van keuzes of activiteiten binnen een project worden toegewezen aan de interne of een externe auditor kunnen een aantal overwegingen een rol spelen. Hierna worden een aantal aspecten ter illustratie genoemd in een nietlimitatieve opsomming: kennis van de business: de interne auditor zal door de bank genomen beter de business en organisatie kennen en als zodanig op een meer efficiënte wijze in staat kunnen zijn toegevoegde waarde te leveren; inbreng van best practices: de externe auditor kan best practices en ervaringen van andere klanten inbrengen die soortgelijke projecten hebben uitgevoerd. Dit is de tegenhanger van het bovengenoemde punt; kennis van het proces/systeem: de externe auditor kan het ontwerp van een proces en systeem valideren op basis van ervaringen bij andere klanten; opdrachtgever: de projectstuurgroep zou de interne auditor kunnen vragen om een risicoanalyse uit te voeren. Het bestuur van de onderneming kan de externe auditor vragen om te adviseren bij de invoering van een systeem op basis van ervaringen bij andere klanten. Het is belangrijk het bovenstaande in het achterhoofd te houden bij het samenstellen van een projectteam. Daarbij kan ook juist de combinatie van de inzet van de interne én externe auditor synergie opleveren. Het is van belang om mogelijke onduidelijkheid over potentiële rollen van assurance- en adviespartners in de organisatie te voorkomen door deze te formaliseren. Op organisatieniveau worden het doel, het mandaat en de aard van de activiteiten van de interne auditor vastgelegd in het audit charter en goedgekeurd door het bestuur 3. Het verdient aanbeveling om de inzet en mogelijke rollen van externe auditpartijen voor assurance- en advieswerkzaamheden te formaliseren in een beleidsdocument. Op programma/projectniveau moeten vervolgens de individuele opdrachten in lijn zijn met de taken en verantwoordelijkheden in het audit charter en interne beleidsrichtlijnen en worden vastgelegd in het project charter. De mogelijke rollen van een IT- auditor en de randvoorwaarden, zoals uiteengezet in de volgende subparagraaf zijn algemeen toepasbaar in de zin dat ze zowel voor een interne als externe auditor van toepassing zijn. Quality Control versus Quality Assurance Quality Control (QC) betreft de activiteiten die de projectleider ondersteunen in de dagelijkse beheersing van het project. Quality Control is de verantwoordelijkheid van de het (project)management (eerste lijn) en de tweedelijns functies kunnen hierbij ondersteuning geven. Zo kan de

5 afdeling business control (tweede lijn) de projectleider ondersteunen bij het opstellen en monitoren van de projectbegroting en uitgaven. Dit wordt onderscheiden van Quality Assurance (QA), of Project assurance in Prince2-terminologie 4 ) waarmee de activiteiten moeten worden verstaan die namens en ten behoeve van de opdrachtgever (aanvullende) zekerheid geven dat het project op een juiste wijze wordt uitgevoerd en de risico s worden beheerst. 5 Hier ligt een rol voor internal audit, in de derde line of defense, om aanvullende zekerheid te geven over de activiteiten van de eerste en tweede lijn. Wellicht ten overvloede wordt benadrukt dat ongeacht welke rol de auditor in een project heeft, het management te allen tijde primair verantwoordelijk is voor het borgen van de kwaliteitsaspecten van een project (eerste lijn). Zo is het bewaken van de voortgang en het monitoren van het budget de verantwoordelijkheid van de projectmanager. Projecten versus programma s In dit hoofdstuk wordt gesproken over projecten en project auditing, maar de strekking daarvan is veelal ook toepasbaar op programma s en het auditen daarvan. In dit licht is een programma een geheel van samenhangende projecten en activiteiten, gericht op het realiseren van een gemeenschappelijk doel. Vaak worden deze projecten gecoördineerd door middel van een zogenoemd PMO-orgaan (Project-/Programma Management Office). Het PMO bewaakt de samenhang en voortgang van de onderliggende projecten. Inhoudelijk kunnen specifieke aspecten inherent aan programmamanagement in de scope van de auditwerkzaamheden worden opgenomen zoals: het toetsen van de onderliggende samenhang van de projecten en op welke wijze wordt bijgedragen tot het realiseren van een gemeenschappelijke doelstelling; het toetsen van de risico s met betrekking tot de wederzijdse afhankelijkheden en de tijdige oplevering van de onderliggende projecten van een programma; het auditen van de naleving van de programmaprocedures zoals budget- en voortgangsbewaking door de projectleiders van de onderliggende projecten. Bovenstaande voorbeelden zijn specifiek voor het auditen van programma s. De rollen van de auditor in projecten, alsmede de randvoorwaarden, zoals beschreven in dit hoofdstuk, zijn generiek en algemeen toepasbaar voor zowel projecten als programma s Soorten rollen van de (IT-)auditor in projecten In het referaat en publicaties over de rol van de auditor in projecten (Huibers, 2008/2009/2010) worden de rollen van de auditor in projecten in 4 soorten rollen 6 gecategoriseerd: de assurance rol: bijvoorbeeld project reviews, milestone reviews en post go-live reviews; de adviserende rol: deze rol kan worden vervuld met randvoorwaarden; de participerende rol: deze rol kan eveneens onder voorbehoud (met randvoorwaarden) worden vervuld; rol die de auditor niet kan vervullen in projecten: bijvoorbeeld het bepalen van de risicoaversie (risk appetite) of het actief managen van de projectrisico s. Mogelijke rollen van de auditor met bijbehorende randvoorwaarden zijn gebaseerd op algemene uitgangspunten in het kader van de onafhankelijkheid van de auditor, zoals geformuleerd door

6 het IIA en NOREA. Ze zijn in het algemeen toepasbaar voor de gehele audit beroepsgroep. Voorbeelden bij de type rollen van de auditor in projecten worden nader uitgewerkt in figuur 1 en toelichting hierop wordt gegeven in de bijbehorende tabel 1. In deze tabel wordt tevens nader ingegaan op de specifieke rol van de IT-auditor door middel van voorbeelden uit de dagelijkse praktijk. In hoofdstuk 3 wordt ingegaan op de randvoorwaarden en de rollen die de auditor niet mag vervullen. ASSURANCE ADVISEREND Reviews na go-live QA project resultaten QA project review Advies projectman. Advies programmaman. QA programma review Advies inhoudelijk Klankbord rol Coach en trainer Pro-actieve expertise rol Project coördinatie PARTICIPEREND Documentatie controls Pro-actieve QA partner Bepalen risico-aversie Managen van risico s Opleggen project process Implementeren oplossingen Verantwoording resultaten Verantwoording project GEEN ROL Assurance rol van de internal auditor Gelegimiteerde rol internal auditor met randvoorwaarden Geen rol voor internal auditor ASSURANCE ADVISEREND/ PARTICIPEREND Figuur 2. Rollen van de auditor in projecten (Huibers, 2008/2009/2010) Toelichting op de figuur De assurance rol, de adviserende en participerende rollen die onder voorbehoud (met randvoorwaarden) kunnen worden vervuld, en de rollen die de auditor niet mag vervullen (zie ook tabel 1 voor toelichting)

7 Type projectenrollen Assurancerol Adviserende rol Projectrollen Omschrijving Specifieke voorbeelden voor de IT-auditor Quality Assurance (QA)-programma/ project reviews Quality Assuranceprojectresultaten (deliverables) Review na go-live Advies programma en projectmanagement Advies inhoudelijk Klankbordrol Coach/trainer Reviews in verschillende fases van het project o.a.: initiële projectfase; project mijlpalen; moment vóór go-live (business readiness review); na go-live (postimplementation reviews) Review op de kwaliteit van de projectresultaten (deliverables), inclusief adequate documentatie ervan Oordeel over de effectiviteit van de integratie van de projectresultaten in de organisatie Advies aan projectmanagement met betrekking tot projectinrichting en risicomanagement methodologie Optreden als adviseur in een afgebakende rol door het beantwoorden van vragen en het aandragen van mogelijke alternatieven zonder directe betrokkenheid te hebben in de besluitvorming en/of realisatie Het stellen van vragen ter reflectie Het optreden in een coachende rol en faciliteren van trainingen met betrekking tot specifieke competentie gebieden van de auditor zoals risicomanagement Beoordelen van de projectinrichting, het project-management, uitvoering en het in kaart brengen van risico s gerelateerd aan de systeemimplementatie Bijvoorbeeld het beoordelen van een autorisatie-strategie en bijbehorende rollen of het beoordelen van een architectuurontwerp Het beoordelen van de effectiviteit van autorisaties een half jaar na de go-live Het inrichten van een project met specifieke mijlpalen zoals goedkeuring van het functioneel ontwerp, vertalen naar een technisch ontwerp, ontwikkeling, testen Advies over het opzetten van een control raamwerk om tot een goede balans tussen applicatiecontrols en procedures te komen Klankbord rol bijvoorbeeld met betrekking tot het komen van een projectaanpak om vroegtijdig belangrijke gebruikers van een systeem te identificeren en in het project te betrekken. Hiermee kan de acceptatie tijdens de go-live fase worden verhoogd Faciliteren van een projectrisicoanalyse

8 Type projectenrollen Participerende rol Projectrollen Omschrijving Specifieke voorbeelden voor de IT-auditor Proactieve expertise rol Project/procescoördinatie Documentatie van beheersmaatregelen. Proactieve QA partner rol Beschikken over specifieke kennis en deze actief inbrengen door alternatieve oplossingen aan te dragen en het formuleren van aanbevelingen Coördinatie van projectmatige activiteiten Ondersteunen van documentatie van beheersmaatregelen QA partner die niet alleen helpt risico s te identificeren maar deze ook vertaalt in concrete business issues met behorende aanbevelingen Bijvoorbeeld het aanreiken van alternatieven op het gebied van beheersingsmaatregelen en IT beveiliging Het coördineren van het opzetten van een autorisatieraamwerk en aan-reiken van templates (invul-ling is aan gebruikers) Het ondersteunen bij het opstellen van een control raamwerk en het documen-teren van controls die zijn bepaald door de proceseigenaar Het helpen identificeren van mogelijke risico s in de acceptatie van een nieuw systeem en het aanreiken van alternatieven om deze risico s te verminderen Tabel 1. Rollen van de (ITß)auditor in projecten (Huibers, 2008/2009/2010) In het kader hieronder wordt de adviserende en participerende rol van de IT-auditor in een project nader toegelicht aan de hand van een voorbeeld uit de praktijk. Voorbeeld Bij een grote multinational is een Business Intelligence (BI)-programma opgezet om alle groepsfuncties van managementinformatie te voorzien. Een (externe) IT-auditor is gevraagd om actief kennis en ervaring in te brengen met betrekking tot het opzetten en documenteren van controls aan de hand van standaarden die in de organisatie gebruikt worden. Achterliggende gedachte is dat er in de business weinig kennis is over het structureel identificeren van procesrisico s en het opstellen van bijbehorende controls. Een specifiek aandachtspunt voor dit project was het adviseren in de mogelijkheden tussen geautomatiseerde controls en het implementeren van procedures buiten het systeem. Een reden was onder meer dat de kennis en de manier van werken met de nieuwe applicatie ontbrak. De externe IT-auditor kon in een adviesrol ervaringen inbrengen van implementaties bij andere klanten. De rol van de auditor en het management in dit programma was overigens expliciet vastgelegd in het project charter. De IT-auditor functioneerde als een soort van controls integrator naast de implementatiepartner. Het management was verantwoordelijk voor alle keuzes, het uitwerken van de procedures en implementeren ervan. Het control ontwerp is geïntegreerd in de functionele ontwerpen, in nauwe samenwerking met de proceseigenaar die het ontwerp ook formeel heeft goedgekeurd, waarmee een solide basis is gelegd in het project. In paragraaf wordt ingegaan op de rol per fase van het project. In hoofdstuk 3 worden de

9 randvoorwaarde en de rollen die de IT-auditor absoluut niet zou mogen vervullen verder uitgewerkt Rollen per fase van project De rollen kunnen per fase van het project verschillen. In tabel 2 worden voorbeelden gegeven van de rollen per fase op basis van de algemeen aanvaarde PRINCE2 projectmethode. PRINCE2 is een projectmanagement-methode gebaseerd op een procesgerichte aanpak. Het is een gestructureerde methode voor het inrichten en besturen van een project. De methode is geschikt voor alle type projecten en kan naar behoefte worden aangepast. De processen worden bepaald aan de hand van de te behalen doelstellingen. Deze doelstellingen worden concreet omschreven door middel van te realiseren producten en het uitvoeren van activiteiten die daarvoor nodig zijn. Bijvoorbeeld in de projectinitiatiefase ligt de nadruk op het definiëren van de producten die moeten worden opgeleverd, met de bijbehorende kwaliteitscriteria waaraan die producten moeten voldoen. Een voorbeeld is het opleveren van een projectvoorstel met een business case, kwaliteitsverwachtingen en acceptatiecriteria. De methode bestaat uit zeven principes, processen (initiëren van een project, managen van product opleveringen etc.) en thema s (bijvoorbeeld business case, plannen, kwaliteitsbewaking etc.). 7 De auditor dient er rekening mee te houden dat het proces in iedere organisatie kan verschillen en een variant kan zijn op de stappen, zoals beschreven in deze PRINCE2 methode. Generieke fasen van projecten op een hoger abstractieniveau zijn 8 : projectvoorbereiding en planning; projectexecutie; projectafronding. In tabel 2 staan per fase van het project in algemene termen de PRINCE2 processen en thema s aangegeven. In de tabel worden per fase mogelijke rollen van de IT-auditor beschreven. Hierbij zij opgemerkt dat bij adviserende en participerende rollen randvoorwaarden van toepassing zijn die worden beschreven in paragraaf 3. Voorbeeld Bij een grote multinational wordt op wereldwijde schaal een ERP-systeem uitgerold dat alle basisprocessen van de werkmaatschappijen in de landen raakt. De IT-auditfunctie geeft aanvullende zekerheid over het behalen van de doelstellingen aan de stuurgroep en heeft een standaard auditaanpak ontwikkeld die per uitrol in de landen wordt uitgevoerd. Het uitgangspunt is om in een vroegtijdig stadium reeds bij het project betrokken te zijn. Op drie belangrijke momenten in het project wordt vervolgens een review gedaan met specifieke aandachtpunten: 1. Start van het project: beoordelen van de business case, projectrisico s en de projectopzet, zoals de organisatie, project governance en projectplanning. 2. Tussentijdse review: timing van deze review is aan het einde van de ontwerpfase; aandachtspunten zijn onder meer de voortgang, betrokkenheid van de proceseigenaar, het in kaart brengen van hiaten tussen de huidige manier van werken en de nieuwe processen en het veranderplan. 3. Review voor de go-live: timing van de review is ongeveer zes weken voor go-live. De auditfunctie beoordeelt in hoeverre de organisatie klaar is voor de go-live en doet

10 aanbevelingen om indien nodig nog te kunnen bijsturen. Zo wordt bekeken of er eenduidige go-live criteria zijn, of de trainingen goed zijn voorbereid en of er een overdrachtsplan is naar de staande organisatie. Aangezien projecten aan veranderingen onderhevig zijn en er continue druk is op budgetten en beschikbaarheid van medewerkers, is gekozen voor een aanpak om regelmatig de thermometer in het project te steken. Tevens kan worden bezien in hoeverre aanbevelingen uit een voorgaande review zijn meegenomen. Door dit auditprogramma in alle werkmaatschappijen uit te voeren kan de auditor het projectmanagement ook voorzien van voorbeelden uit andere implementaties ter ondersteuning van nieuwe projecten. Project voorbereiding/ start Projectexecutie Projectafsluiting PRINCE2 process Opstarten project Initiëren van een project Beheersen van een fase Managen van opleveren project producten Managen van mijlpalen Sluiten van project Thema PRINCE2 Plannen, Risico, Organisatie, Business case Plannen, Kwaliteit, Risico, Business case Voortgang, Wijziging Wijziging, Kwaliteit, Voortgang Risico, Voortgang Kwaliteit, Business case Mogelijke rol van de auditor - Quality Assurance (QA) programma/ project reviews - Advies - programma- en projectmanagement - QA programma/project reviews - Advies - inhoudelijk - Klankbordrol - Pro-actieve expertiserol - Project/proces coördinatie - Documentatie beheersmaatregelen - Pro-actieve QApartner rol - QA programma/ project management Voorbeelden voor ITauditor (met verwijzing naar randvoorwaarden in hoofdstuk 3) Review om vast te stellen of project of projectdoelstellingen consistent zijn met de ondernemingsdoelstellingen Advies met betrekking tot het opzetten en inrichten van het project en kwaliteitsprocessen Mijlpaal review ter beoordeling van voortgang en kwaliteit van projectproducten (bijvoorbeeld functioneel ontwerp, technisch ontwerp) Advies met betrekking tot het opstellen van het security design van een applicatie Faciliteren in het documenteren van applicatie controls Ondersteuning in de coördinatie van het control ontwerp van een proces en bijbehorend systeem Ondersteuning in het identificeren en vastleggen van projectrisico s Projectevaluatie ten behoeve van leerpunten voor toekomstige projecten Tabel 2. Voorbeelden rollen van de (IT-)auditor per fase in een project (ontleend aan Huibers, 2008)

11 3. Randvoorwaarden en rollen die de auditor niet zou mogen vervullen 3.1 Randvoorwaarden Enerzijds geeft de auditor vanuit zijn assurancerol een objectieve beoordeling over het functioneren van het onderzoeksobject van de audit op basis van verzameld bewijsmateriaal. Anderzijds kan de auditor op verzoek van het management advies uitbrengen over mogelijke oplossingsrichtingen. Op basis van de dagelijkse praktijk kunnen diverse opdrachtgevers worden onderscheiden 9 : de stuurgroep: de projectaudit kan aanvullende zekerheid verschaffen aan de stuurgroep die eindverantwoordelijk is voor de resultaten van het project; de directie of de raad van bestuur van de organisatie waar het project wordt uitgevoerd:de audit wordt dan geheel onafhankelijk van het project uitgevoerd; de projectmanager: hij kan zelf om aanvullende zekerheid vragen, bijvoorbeeld in de vorm van advies om het project in te richten of risico s in kaart te brengen. Met de toenemende vraag van het management naar de diensten van de auditor is de vraag hoe de auditor zijn assurancerol kan verbreden naar een meer adviserende rol als een proactieve partner in projecten, zonder daarbij zijn onafhankelijke positie in het gedrang te laten komen. Het gemeenschappelijk doel is uiteindelijk de organisatiedoelstellingen te realiseren en de ondersteunende processen te verbeteren. Van cruciaal belang zijn daarbij de zogenoemde waarborgen (randvoorwaarden bij rollen in paragraaf 2) die bij het uitoefenen van adviserende en participerende rollen in acht genomen dienen te worden om de onafhankelijkheid van de auditor te borgen. Hieronder worden de belangrijkste randvoorwaarden opgesomd: Management blijft te allen tijde verantwoordelijk voor de projectrisico s en het vaststellen van de risico-voorkeur; met andere woorden hoeveel risico tot een vertraging van de oplevering van het project wil het management nemen? De aard van de verantwoordelijkheden van de interne auditor dient te worden gedocumenteerd in het audit charter dat moet worden goedgekeurd door het bestuur 10.De rollen in het project moeten duidelijk worden benoemd en in lijn zijn met het audit charter. De auditor kan én mag geen projectrisico s managen en mitigerende maatregelen treffen namens het management. De auditor kan advies, reflecties en ondersteuning geven aan het management met betrekking tot besluitvorming; in tegenstelling tot het zelf nemen van besluiten of het implementeren van oplossingen namens het management. De auditor moet mogelijke belangenverstrengelingen in het kader van de onafhankelijkheid voorkomen, vooral ook als de perceptie van de onafhankelijkheid in de organisatie in het gedrang komt. Indien nodig dient functiescheiding of verdeling/uitbesteding van taken worden toegepast. Alle activiteiten buiten de grenzen van assuranceactiviteiten dienen te worden onderkend als adviesopdrachten en de IIA/interne standaarden met betrekking tot dergelijke adviesopdrachten zijn van toepassing (bijvoorbeeld het toetsen van de opdracht door de afdeling risicomanagement van een grote accountants- en adviesorganisatie). Eén van de belangrijkste randvoorwaarden om de onafhankelijkheid van de auditor te waarafl. 43 (juni 2012)

12 borgen, is dat hij geen managementverantwoordelijkheid neemt. Dit geldt voor alle onderdelen van het project: vanaf het moment van het bepalen van de risicoaversie van het project tot aan het implementeren van de resultaten. De auditor dient onafhankelijk te opereren en op basis van feiten een eigen oordeel te vormen. De auditor dient ervoor te zorgen dat hij objectief blijft en dat zijn oordeel niet wordt beïnvloed door een vooroordeel, belangentegenstelling of een ongepaste beïnvloeding door een derde. In het geval van enig afbreukrisico met betrekking tot zijn onafhankelijke positie, in werkelijkheid of in schijn, is het kenbaar maken ervan voorafgaande aan de overeenkomst verplicht 11. In dit geval kan het project charter als de overeenkomst worden gezien. Daarnaast moet de auditor, vanuit professionele beroepsstandaarden, te allen tijde zijn bevindingen aan het hoogste bestuursorgaan kunnen melden. 3.2 Rollen die de (IT-)auditor niet mag vervullen Het is de primaire verantwoordelijkheid van de projectmanager om projectrisico s te managen. De (IT-)auditor kan helpen met het transparant maken van risico s, maar het is aan het management van de business om de risicoaversie vast te stellen en corrigerende maatregelen te definiëren en te implementeren. Daarbij is het verankeren van projectproducten in de staande organisatie een verantwoordelijkheid van het lijnmanagement. Als de (IT-)auditor deze rollen op zich neemt gaat hij te ver en kan hij zijn onafhankelijke positie onvoldoende waarborgen. In onderstaande tabel worden de rollen die de auditor niet mag vervullen in projecten toegelicht met specifieke voorbeelden voor de IT-auditor. Rollen die de auditor niet mag vervullen in projecten Bepalen van de risicoaversie Opleggen van het projectmanagementproces Managen van de risico s die zijn geïdentificeerd in het kader van de Quality Assurance Nemen van besluiten met betrekking tot de voorgestelde oplossingsrichtingen Implementeren van de oplossingen namens het management Eindverantwoordelijkheid dragen over de projectresultaten Eindverantwoordelijkheid nemen over project voortgang- en budgetbewaking Eindverantwoordelijkheid dragen over het borgen van de projectresultaten in de organisatie Voorbeelden van rollen die de IT-auditor niet mag vervullen De IT-auditor mag niet bepalen hoeveel risico het management mag nemen dat data verloren gaat bij het bepalen van de frequentie van een back-up procedure De projectmanager bepaalt de koers, mijlpalen en producten van het project in overleg met het management, niet de IT-auditor Keuzes maken in autorisatiebeheer. Het management maakt zelfs keuzes in wijzigingen in het autorisatiebeheer. De IT-auditor kan deze wel toetsen De IT-auditor neemt geen besluiten over het control ontwerp; de proceseigenaar keurt het ontwerp goed De IT-auditor voert niet de wijzigingen in het systeem door; dit dient onder regie van het management te gebeuren De IT-auditor kan niet eindverantwoordelijk zijn voor de invoering van een nieuw systeem; deze verantwoordelijkheid kan en mag het management niet delegeren De IT-auditor is niet eindverantwoordelijk over de voortgang en budget van het gehele project. Hij kan wel een signalerende rol hebben De IT-auditor kan een post-go live review uitvoeren maar is niet verantwoordelijk voor het managen van de taken in de staande organisatie Tabel 4. Rollen die de (IT-)auditor niet zou mogen vervullen

13 In deze paragraaf is aangegeven welke rollen de auditor niet mag vervullen in projecten toegelicht met voorbeelden in de praktijk van de IT-auditor. In eerdere publicaties van Huibers (2008/2009/ 2010, online beschikbaar op de site van het IIA 12 ) wordt verder toegelicht op welke wijze de auditor tevens mogelijk conflicterende rollen kan vervullen, zoals die van een adviserende business partner en iemand die assurance verstrekt zonder dat hij daarbij zijn onafhankelijke positie verliest. 4. Tot slot Door de verschillende facetten van projecten is een geïntegreerde aanpak en multidisciplinaire teamsamenstelling vaak van belang. In projecten met een systeemcomponent zijn de competenties van de IT-auditor vaak essentieel voor een goede invulling van de projectrollen. Voor ieder groot project waarbij auditors met verschillende specialisaties zijn betrokken, kan een auditmanager taken en verantwoordelijkheden toewijzen aan verschillende auditdisciplines en zo assurance, advies en participerende rollen verdelen over betrokken disciplines. Zo kan de ITauditor op basis van zijn expertise adviseren in het definiëren van de applicatiecontrols in een control ontwerp, terwijl de operational auditor zich kan concentreren op de procedures en werkinstructies van het proces. Het IIA (2008) noemt deze toenemende auditaanpak integrated auditing, waarbij de doelen van de business als uitgangspunt worden genomen in plaats van het afzonderlijk uitvoeren van audits per auditdiscipline. Met de toenemende vraag van management naar de diensten van de auditor is in dit hoofdstuk richting gegeven aan hoe de auditor zijn assurancerol kan verbreden naar een meer adviserende rol als proactieve partner in projecten, zonder daarbij zijn onafhankelijke positie in het gedrang te laten komen. De roltypering van de auditor en het raamwerk met richtlijnen zijn getoetst door middel van interviews met Chief Audit Executives (CAE s) van een aantal grote Nederlandse multinationals en een aantal partners van grote accountantskantoren. De gemeenschappelijke visie is dat de werkelijke toegevoegde waarde van de auditor ligt in een betrokken en proactieve deelname vanaf het begin van het project in plaats van achteraf de balans op te maken. Dit hoeft zeker niet tegenstrijdig te zijn met de onafhankelijke positie van de auditor. Integendeel, één van de CAE s maakte de volgende opmerking: Voor de positionering van de auditor (...) is dit een kans in plaats van een bedreiging. Hij gaf aan dat de werkelijke toegevoegde waarde van audit in projecten het geven van advies is. Door bijvoorbeeld het aanreiken van het referentiemodel van een projectaudit (normenkader) in een vroeg stadium van het project kan de auditor invulling geven aan deze adviserende rol, zonder zelf op de stoel van het management te gaan zitten. Aangezien een IT-implementatie onderdeel is van veel grote projecten biedt de multi-inzetbaarheid van de IT-auditor in projecten veel kansen en mogelijkheden voor de beroepsgroep. Noten 1. Information Technology Infrastructure Library, afgekort ITILÕ, is ontwikkeld als een set van best practices voor het inrichten van beheerprocessen binnen een (ICT)-organisatie. 2. Het lines of defense -model wordt veelvuldig in de literatuur aangehaald (zie onder andere

14 Croonenberg et al. 2011). Voor banken is het model als uitgangspunt gebruikt in de documenten van het Basel Committee on banking Supervision om richting te geven aan corporate governance en de rol van de interne auditfunctie daarbij. 3. IIA, De internationale standaarden voor de beroepsuitoefening van internal auditing 2011, Kenmerkstandaard 1000 Doel, bevoegdheid en verantwoordelijkheid. 4. PRINCE2 is een algemeen aanvaarde projectmanagementmethode gebaseerd op een procesgerichte aanpak, zie paragraaf voor een nadere uiteenzetting. 5. Omschrijving QC en QA ontleend aan IIA, Project Auditing, Handvatten voor de internal auditor, Hiervoor is gebruik gemaakt van een analogie van basisrollen van een zogenoemd position paper van het Institute of Internal Auditors met betrekking tot de rol van de auditfunctie in Enterprise Risk Management (IIA, 2004). 7. Ontleend aan OCG ( 8. In een publicatie van het IIA Nederland (2010) worden handvatten gegeven voor projectauditing met een praktisch overzicht van verschillende projectmethoden en de toepasbaarheid ervan als handreiking voor de auditor. 9. Ontleend aan IIA, Project Auditing, Handvatten voor de internal auditor, IIA, De internationale standaarden voor de beroepsuitoefening van internal auditing, 2011, Kenmerkstandaard 1000 Doel, bevoegdheid en verantwoordelijkheid. 11. IIA, De internationale standaarden voor de beroepsuitoefening van internal auditing, 2011, Kenmerkstandaard 1130.C2, Aantasting van onafhankelijkheid of objectiviteit. 12. Referaat en artikelen zijn te downloaden op de site van het IIA via deze link: educatie/universiteiten/scripties. Referenties H. Cleton, en P.A. Hartog, Positionering en rol van de IAD bij kwaliteitsborging van ICT- programma s en projecten, Audit Magazine, Number 1, March, Croonenberg, San Eddy van der Geest en Michael Schoevaart, Meetlat voor beheersing: GRC in ontwikkeling, Accountant, maart, nr. 3, P. Hartog en Ron de Korte, Naar Integrated Auditing, 3 etapes, 10 wegwijzers, ESAA, P. Hartog, Soorten Projectaudits, Handboek EDP-auditing, hfdst. 9330, Het Instituut van Internal Auditors Nederland (IIA), De Internal Auditor in Nederland, Naarden: Position Paper Update Het Instituut van Internal Auditors Nederland (IIA), Project Auditing, Handvatten voor de internal auditor, S.C.J., Huibers, The role(s) of the Internal Auditor in Projects, referaat Amsterdam Business School, Universiteit van Amsterdam, Executive Master of Internal Auditing, juli Online toegankelijk in database op de site van het IIA Nederland ( Kluwer 2009 en op de site van het IIA Nederland ( scripties). S.C.J. Huibers, Rol van de internal auditor in veranderingsprojecten, Finance en Control, versie5, oktober 2009, Kluwer S.C.J. Huibers, Proactiviteit en onafhankelijkheid van de auditor in projecten: contradictio in terminis?, Audit Magazine, nr. 1 maart 2010, Instituut voor Internal Auditors in Nederland, VM Uitgevers, Prem Mancham, Bart van Staveren en Erwin Veth, De Multi inzetbaarheid van de RE, IT-Auditor, nr. 4,

15 A. Molenkamp, Internal Auditprofessie bewijst haar bestaansrecht, Finance&Control, april The Institute of Internal Auditors, position paper, The Role of Internal Audit in Enterprise-wide Risk Management, Het Instituut van Internal Auditors Nederland, De Internal Auditor in Nederland, Naarden: Position Paper Update The Institute of Internal Auditors, The Professional Practices Framework, The IIA Research Foundation, K. Wegrzynowicz and S. Stein, Global Technology Audit Guide (GTAGÕ), 12: Auditing IT-projects, The IIA, March Websites en org Auteur Sam Huibers is werkzaam als Audit Manager Global Audit bij Heineken International. Eerder bekleedde hij in het bedrijfsleven diverse internationale managementfuncties in finance & control, advies- en projectmanagement. Tevens was hij als onderzoeker verbonden aan de Universiteit van Maastricht waar hij heeft gewerkt aan projecten in opdracht van de Europese Commissie. Hij heeft diverse publicaties over de rol van de auditor in projecten op zijn naam staan en heeft deel uitgemaakt van een vaktechnische groep van het IIA die in 2010 een publicatie over project auditing heeft uitgebracht (IIA, 2010). Hij is vast lid van de Commissie Vaktechniek van het IIA en de Sonding Board Risk Management Nederland

16