5313 -
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 e´e´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 randvoor-
afl. 43 (juni 2012)
5313-1
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. Ee´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 financie¨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 financie¨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 essentie¨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 ISO27 001 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
2.2.1 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
afl. 43 (juni 2012)
5313-2
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 financie¨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 financie¨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 financie¨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 e´e´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
afl. 43 (juni 2012)
5313-3
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 inefficie¨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 efficie¨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 e´n externe auditor synergie opleveren. Het is van belang om mogelijke onduidelijkheid over potentie¨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 bestuur3. 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
afl. 43 (juni 2012)
5313-4
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-terminologie4) 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 gecoo¨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. 2.2.2 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 rollen6 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
afl. 43 (juni 2012)
5313-5
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.
n.
Doc Project coördin ume atie ntat Pro ie co -ac t n i Be eve trols pa QA len par t ner ris ico -a ve rsi e
ASSU RAN CE
ma
QA programma review
Assurance rol van de internal auditor
Gelegimiteerde rol internal auditor met randvoorwaarden
ASSURANCE
ADVISEREND/ PARTICIPEREND
ss
ce
ro tp
jec
ROL EN GE
trainer
t resu
Coach en
lijk
ma
ive ltate n QA project review
rojec
rol
o-l
d kbor
am
ag
. an
sn
gr
ctm
iew
oje
ro
QA p
e oud
pr
sp
Rev
inh
s vie
vie
Klan
ies Adv
Ad Ad
Pro-actieve expertise rol
PART ICIP ERE ND
D EN ER S I V AD
co’s risi n a e g nv n leg age singe Op Man ren oplos e t n me Imple ltaten rding resu Verantwoo Verantwoording project
ro np
Geen rol voor internal auditor
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).
afl. 43 (juni 2012)
5313-6
Type projectenrollen
Projectrollen
Omschrijving
Specifieke voorbeelden voor de IT-auditor
Quality Assurance (QA)-programma/
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)
Beoordelen van de projectinrichting, het project-management, uitvoering en het in kaart brengen van risico’s gerelateerd aan de systeemimplementatie
Quality Assuranceprojectresultaten (deliverables)
Review op de kwaliteit van de projectresultaten (deliverables), inclusief adequate documentatie ervan
Bijvoorbeeld het beoordelen van een autorisatie-strategie en bijbehorende rollen of het beoordelen van een architectuurontwerp
Review na go-live
Oordeel over de effectiviteit van de integratie van de projectresultaten in de organisatie
Het beoordelen van de effectiviteit van autorisaties een half jaar na de go-live
Advies programma en projectmanagement
Advies aan projectmanagement met betrekking tot projectinrichting en risicomanagement methodologie
Het inrichten van een project met specifieke mijlpalen zoals goedkeuring van het functioneel ontwerp, vertalen naar een technisch ontwerp, ontwikkeling, testen
Advies inhoudelijk
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
Advies over het opzetten van een control raamwerk om tot een goede balans tussen applicatiecontrols en procedures te komen
Klankbordrol
Het stellen van vragen ter reflectie
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
Coach/trainer
Het optreden in een coachende rol en faciliteren van trainingen met betrekking tot specifieke competentie gebieden van de auditor zoals risicomanagement
Faciliteren van een projectrisicoanalyse
project reviews
Assurancerol
Adviserende rol
afl. 43 (juni 2012)
5313-7
Type projectenrollen
Participerende rol
Projectrollen
Omschrijving
Specifieke voorbeelden voor de IT-auditor
Proactieve expertise rol
Beschikken over specifieke kennis en deze actief inbrengen door alternatieve oplossingen aan te dragen en het formuleren van aanbevelingen
Bijvoorbeeld het aanreiken van alternatieven op het gebied van beheersingsmaatregelen en IT beveiliging
Project/procescoördinatie
Coördinatie van projectmatige activiteiten
Het coördineren van het opzetten van een autorisatieraamwerk en aan-reiken van templates (invul-ling is aan gebruikers)
Documentatie van beheersmaatregelen.
Ondersteunen van documentatie van beheersmaatregelen
Het ondersteunen bij het opstellen van een control raamwerk en het documen-teren van controls die zijn bepaald door de proceseigenaar
Proactieve QA partner rol
QA partner die niet alleen helpt risico’s te identificeren maar deze ook vertaalt in concrete business issues met behorende aanbevelingen
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 2.2.3 wordt ingegaan op de rol per fase van het project. In hoofdstuk 3 worden de
afl. 43 (juni 2012)
5313-8
randvoorwaarde en de rollen die de IT-auditor absoluut niet zou mogen vervullen verder uitgewerkt. 2.2.3 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 definie¨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 (initie¨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 zijn8: _ 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
afl. 43 (juni 2012)
5313-9
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. PRINCE2 process
Project Opstarten voorbereiding/ project start
Projectexecutie
Projectafsluiting
Thema PRINCE2
Plannen, Risico, Organisatie, Business case
Initiëren van een project
Plannen, Kwaliteit, Risico, Business case
Beheersen van een fase
Voortgang, Wijziging
Managen van opleveren project producten
Wijziging, Kwaliteit, Voortgang
Managen van mijlpalen
Risico, Voortgang
Sluiten van project
Kwaliteit, Business case
Mogelijke rol van de auditor
Voorbeelden voor ITauditor (met verwijzing naar randvoorwaarden in hoofdstuk 3) - Quality Assurance Review om vast te stellen of (QA) programma/ project of projectdoelstelproject reviews lingen consistent zijn met de ondernemingsdoelstellingen - Advies - programAdvies met betrekking tot ma- en projectma- het opzetten en inrichten nagement van het project en kwaliteitsprocessen - QA programma/pro- Mijlpaal review ter beoorject reviews deling van voortgang en kwaliteit van projectproducten (bijvoorbeeld functioneel ontwerp, technisch ontwerp) - Advies - inhoudelijk Advies met betrekking tot het opstellen van het - Klankbordrol security design van een - Pro-actieve experapplicatie tiserol Faciliteren in het documen- Project/proces teren van applicatie controls coördinatie Ondersteuning in de - Documentatie becoördinatie van het control heersmaatregelen ontwerp van een proces en bijbehorend systeem - Pro-actieve QAOndersteuning in het idenpartner rol tificeren en vastleggen van projectrisico’s - QA programma/ Projectevaluatie ten behoeve project management van leerpunten voor toekomstige projecten
Tabel 2. Voorbeelden rollen van de (IT-)auditor per fase in een project (ontleend aan Huibers, 2008)
afl. 43 (juni 2012)
5313-10
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 onderscheiden9: _ 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 bestuur10. De rollen in het project moeten duidelijk worden benoemd en in lijn zijn met het audit charter. _ De auditor kan e´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). Ee´n van de belangrijkste randvoorwaarden om de onafhankelijkheid van de auditor te waar-
afl. 43 (juni 2012)
5313-11
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 verplicht11. 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 definie¨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
Voorbeelden van rollen die de IT-auditor niet mag vervullen
Bepalen van de risicoaversie
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
Opleggen van het projectmanagementproces
De projectmanager bepaalt de koers, mijlpalen en producten van het project in overleg met het management, niet de IT-auditor
Managen van de risico’s die zijn geïdentificeerd in het kader van de Quality Assurance
Keuzes maken in autorisatiebeheer. Het management maakt zelfs keuzes in wijzigingen in het autorisatiebeheer. De IT-auditor kan deze wel toetsen
Nemen van besluiten met betrekking tot de voorgestelde oplossingsrichtingen
De IT-auditor neemt geen besluiten over het control ontwerp; de proceseigenaar keurt het ontwerp goed
Implementeren van de oplossingen namens het management
De IT-auditor voert niet de wijzigingen in het systeem door; dit dient onder regie van het management te gebeuren
Eindverantwoordelijkheid dragen over de projectresultaten
De IT-auditor kan niet eindverantwoordelijk zijn voor de invoering van een nieuw systeem; deze verantwoordelijkheid kan en mag het management niet delegeren
Eindverantwoordelijkheid nemen over project voortgang- en budgetbewaking
De IT-auditor is niet eindverantwoordelijk over de voortgang en budget van het gehele project. Hij kan wel een signalerende rol hebben
Eindverantwoordelijkheid dragen over het borgen van de projectresultaten in de organisatie
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
afl. 43 (juni 2012)
5313-12
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 IIA12) 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 definie¨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, e´e´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
afl. 43 (juni 2012)
5313-13
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. IIA, De internationale standaarden voor de beroepsuitoefening van internal auditing 2011, Ken-
3.
merkstandaard 1000 – Doel, bevoegdheid en verantwoordelijkheid. PRINCE2 is een algemeen aanvaarde projectmanagementmethode gebaseerd op een procesgerichte
4.
aanpak, zie paragraaf 2.2.3 voor een nadere uiteenzetting. Omschrijving QC en QA ontleend aan IIA, Project Auditing, Handvatten voor de internal auditor,
5.
2010. Hiervoor is gebruik gemaakt van een analogie van basisrollen van een zogenoemd ‘position paper’
6.
van het Institute of Internal Auditors met betrekking tot de rol van de auditfunctie in Enterprise Risk Management (IIA, 2004). 7.
Ontleend aan OCG (http://www.prince-officialsite.com/).
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, 2010.
10.
IIA, De internationale standaarden voor de beroepsuitoefening van internal auditing, 2011, Ken-
11.
merkstandaard 1000 – Doel, bevoegdheid en verantwoordelijkheid. 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: http://www.iia.nl/ 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, 2005. Croonenberg, San Eddy van der Geest en Michael Schoevaart,‘Meetlat voor beheersing: GRC in ontwikkeling’, Accountant, maart, nr. 3, 2011.
_
P. Hartog en Ron de Korte, Naar Integrated Auditing, 3 etapes, 10 wegwijzers, ESAA, 2008.
_
P. Hartog, ‘Soorten Projectaudits’, Handboek EDP-auditing, hfdst. 9330, 2012.
_
Het Instituut van Internal Auditors Nederland (IIA), De Internal Auditor in Nederland, Naarden: Position Paper Update 2008.
_
_
Het Instituut van Internal Auditors Nederland (IIA), Project Auditing, Handvatten voor de internal auditor, www.iia.nl, 2010 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 2008. Online toegankelijk in database op de site van het IIA Nederland (www.iia.nl); http://financebase.kluwerfinancieelmanagement.nl/, Kluwer 2009 en op de site van het IIA Nederland (http://www.iia.nl/educatie/universiteiten/ scripties).
_
S.C.J. Huibers,‘Rol van de internal auditor in veranderingsprojecten’, Finance en Control, versie 5, oktober
_
2009, Kluwer 2009. 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, 2010.
_
Prem Mancham, Bart van Staveren en Erwin Veth, ‘De Multi inzetbaarheid van de RE’, IT-Auditor, nr. 4, 2010.
afl. 43 (juni 2012)
5313-14
_
A. Molenkamp, ‘Internal Auditprofessie bewijst haar bestaansrecht’, Finance & Control, april 2005.
_
The Institute of Internal Auditors, position paper, The Role of Internal Audit in Enterprise-wide Risk
_
Management, www.theiia.org, 2004. Het Instituut van Internal Auditors Nederland, De Internal Auditor in Nederland, Naarden: Position Paper Update 2008.
_
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,
2011. March 2009. Websites _
www.norea.nl
_
www.iia.nl
_
www.pwc.nl
_
www.prince2.org.uk en www.ogc.gov.uk;
_
www.ipma.ch;
_
www.theiia.org
_
www.auditing.nl www.itil.nl
_
www.27 000.org
_
www.projectflow2009.nl
_
www.apmg-international.com/APMG-Benelux/PRINCE2
_
www.prince-officialsite.com
_
www.bis.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.
afl. 43 (juni 2012)
5313-15
afl. 43 (juni 2012)
5313-16
