5313 -
InformatiesystemenRol(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 con- currentie 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 ver- werken 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-
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 aan- vullende 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 Angel- saksische managementbenadering van de jaren negentig, gericht op het integreren van de audit- activiteiten, 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 in- frastructuuromgeving toetsen, zoals de effectiviteit van security, incident en change manage- mentprocessen (bijvoorbeeld ISO27 001 en ITIL)1. Daarnaast heeft de IT-auditor een steeds be- langrijker 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 oorspronke- lijk 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
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 ‘verdedigings- linies’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 ri- sicobeheersing.
_ 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 werkzaam- heden 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 finan- cie¨le consolidatie. De interne IT-auditor (derde lijn) evalueert de volledigheid van de beheers- maatregelen 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 nood- zakelijkerwijs 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, onaf- hankelijke 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
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 ef- fectiever 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 ineffi- cie¨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 overwe- gingen een rol spelen. Hierna worden een aantal aspecten ter illustratie genoemd in een niet- limitatieve 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 tegen- hanger 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 ad- viespartners 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 aanbeve- ling om de inzet en mogelijke rollen van externe auditpartijen voor assurance- en advieswerk- zaamheden te formaliseren in een beleidsdocument. Op programma/projectniveau moeten ver- volgens 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)ma- nagement (eerste lijn) en de tweedelijns functies kunnen hierbij ondersteuning geven. Zo kan de
afdeling business control (tweede lijn) de projectleider ondersteunen bij het opstellen en mo- nitoren van de projectbegroting en uitgaven.
Dit wordt onderscheiden van Quality Assurance (QA), of Project assurance in Prince2-termi- nologie4) 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.5Hier 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 kwaliteits- aspecten 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 gemeen- schappelijk 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 voort- gangsbewaking 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 ge- neriek 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 rollen6gecategoriseerd:
_ de assurance rol: bijvoorbeeld project reviews, milestone reviews en post go-live re- views;
_ 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 risico- aversie (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
het IIA en NOREA. Ze zijn in het algemeen toepasbaar voor de gehele audit beroepsgroep. Voor- beelden 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.
QA programma review QA project review
QA project resultaten Reviews na go-live
Advies programmaman.
Advies projectman.
Advies inhoudelijkKlankbord rol Coach en trainer
Assurance rol van de internal
auditor
Gelegimiteerde rol internal auditor met
randvoorwaarden
Geen rol voor internal auditor
Pro-actieve expertise rol
Pro ject coördinati
e
Documentatie controls Pro-a
ctieve QA partner
Bepalen risico-aversie Opleggen project processManagen van risico’
s
Implementeren oplossingen Verantwoording resultaten
Verantwoording project
ASSURANCE ADVISEREND/
PARTICIPEREND ASSURANCE
ADVISERE ND
PARTICIPE REND
GEE N RO
L
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 randvoor- waarden) kunnen worden vervuld, en de rollen die de auditor niet mag vervullen (zie ook tabel 1 voor toelichting).
Type
projectenrollen
Projectrollen Omschrijving Specifi eke voorbeelden voor de IT-auditor
Assurancerol
Quality Assurance (QA)-programma/
project reviews
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 (post- implementation reviews)
Beoordelen van de projectinrich- ting, het project-management, uitvoering en het in kaart bren- gen van risico’s gerelateerd aan de systeemimplementatie
Quality As- surancepro- jectresultaten (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 architec- tuurontwerp
Review na go-live Oordeel over de effectiviteit van de integratie van de projectre- sultaten in de organisatie
Het beoordelen van de effectivi- teit van autorisaties een half jaar na de go-live
Adviserende rol
Advies program- ma en projectma- nagement
Advies aan projectmanagement met betrekking tot projectin- richting en risicomanagement methodologie
Het inrichten van een project met specifi eke mijlpalen zoals goedkeuring van het functio- neel 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 applicatie- controls en procedures te komen
Klankbordrol Het stellen van vragen ter refl ectie
Klankbord rol bijvoorbeeld met betrekking tot het komen van een projectaanpak om vroegtij- dig belangrijke gebruikers van een systeem te identifi ceren en in het project te betrekken. Hier- mee 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 specifi eke competentie gebieden van de auditor zoals risicomanagement
Faciliteren van een projectrisi- coanalyse
Type
projectenrollen
Projectrollen Omschrijving Specifi eke voorbeelden voor de IT-auditor
Participerende rol
Proactieve expertise rol
Beschikken over specifi eke ken- nis 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/proces- coördinatie
Coördinatie van projectmatige activiteiten
Het coördineren van het opzet- ten van een autorisatieraamwerk en aan-reiken van templates (invul-ling is aan gebruikers) Documentatie
van beheersmaat- regelen.
Ondersteunen van documentatie van beheersmaatregelen
Het ondersteunen bij het opstel- len van een control raamwerk en het documen-teren van controls die zijn bepaald door de proces- eigenaar
Proactieve QA partner rol
QA partner die niet alleen helpt risico’s te identifi ceren maar deze ook vertaalt in concrete business issues met behorende aanbevelingen
Het helpen identifi ceren van mo- gelijke 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 ge- vraagd 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 geauto- matiseerde 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 ont- werp is geı¨ntegreerd in de functionele ontwerpen, in nauwe samenwerking met de pro- ceseigenaar 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
randvoorwaarde en de rollen die de IT-auditor absoluut niet zou mogen vervullen verder uit- gewerkt.
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 op- geleverd, met de bijbehorende kwaliteitscriteria waaraan die producten moeten voldoen. Een voorbeeld is het opleveren van een projectvoorstel met een business case, kwaliteitsverwachtin- gen 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 project- opzet, 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 proceseige- naar, 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
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 bud- getten en beschikbaarheid van medewerkers, is gekozen voor een aanpak om regelmatig de thermometer in het project te steken. Tevens kan worden bezien in hoeverre aan- bevelingen 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
Thema PRINCE2 Mogelijke rol van de auditor
Voorbeelden voor IT- auditor (met verwijzing naar randvoorwaarden in hoofdstuk 3)
Project voorbereiding/
start
Opstarten project
Plannen, Risico, Organisatie, Business case
- Quality Assurance (QA) programma/
project reviews
Review om vast te stellen of project of projectdoelstel- lingen consistent zijn met de ondernemingsdoelstellingen Initiëren van
een project
Plannen, Kwaliteit, Risico, Business case
- Advies - program- ma- en projectma- nagement
Advies met betrekking tot het opzetten en inrichten van het project en kwali- teitsprocessen
Project- executie
Beheersen van een fase
Voortgang, Wijziging
- QA programma/pro- ject reviews
Mijlpaal review ter beoor- deling van voortgang en kwaliteit van projectproduc- ten (bijvoorbeeld functioneel ontwerp, technisch ontwerp) Managen van
opleveren pro- ject producten
Wijziging, Kwaliteit, Voortgang
- Advies - inhoudelijk - Klankbordrol - Pro-actieve exper-
tiserol - Project/proces
coördinatie - Documentatie be-
heersmaatregelen
Advies met betrekking tot het opstellen van het security design van een applicatie
Faciliteren in het documen- teren van applicatie controls Ondersteuning in de coördinatie van het control ontwerp van een proces en bijbehorend systeem Managen van
mijlpalen
Risico, Voortgang - Pro-actieve QA- partner rol
Ondersteuning in het iden- tifi ceren en vastleggen van projectrisico’s
Project- afsluiting
Sluiten van project
Kwaliteit, Business case
- QA programma/
project management
Projectevaluatie ten behoeve van leerpunten voor toe- komstige projecten Tabel 2. Voorbeelden rollen van de (IT-)auditor per fase in een project (ontleend aan Huibers, 2008)
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 func- tioneren van het onderzoeksobject van de audit op basis van verzameld bewijsmateriaal. An- derzijds kan de auditor op verzoek van het management advies uitbrengen over mogelijke oplos- singsrichtingen.
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 ge- meenschappelijk doel is uiteindelijk de organisatiedoelstellingen te realiseren en de ondersteu- nende processen te verbeteren. Van cruciaal belang zijn daarbij de zogenoemde waarborgen (randvoorwaarden bij rollen in paragraaf 2) die bij het uitoefenen van adviserende en parti- ciperende 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 vast- stellen 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 gedo- cumenteerd 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 onafhankelijk- heid 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 onder- kend 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-
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 on- afhankelijke 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 voor- beelden 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 pro- ducten van het project in overleg met het management, niet de IT-auditor
Managen van de risico’s die zijn geïdentifi ceerd in het kader van de Quality Assurance
Keuzes maken in autorisatiebeheer. Het management maakt zelfs keuzes in wijzigingen in het autorisatiebe- heer. 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 verantwoorde- lijkheid 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
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 busi- ness 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 compe- tenties 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 IT- auditor 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 werk- instructies van het proces. Het IIA (2008) noemt deze toenemende auditaanpak integrated audit- ing, 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 werke- lijke 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 tegen- strijdig 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-inzetbaar- heid 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
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, Ken- merkstandaard 1000 – Doel, bevoegdheid en verantwoordelijkheid.
4. PRINCE2 is een algemeen aanvaarde projectmanagementmethode gebaseerd op een procesgerichte aanpak, zie paragraaf 2.2.3 voor een nadere uiteenzetting.
5. Omschrijving QC en QA ontleend aan IIA, Project Auditing, Handvatten voor de internal auditor, 2010.
6. 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 (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- merkstandaard 1000 – Doel, bevoegdheid en verantwoordelijkheid.
11. IIA, De internationale standaarden voor de beroepsuitoefening van internal auditing, 2011, Ken- merkstandaard 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 ontwikke- ling’, 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.kluwerfinancieelmanage- ment.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.
_ 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, 2011.
_ K. Wegrzynowicz and S. Stein, Global Technology Audit Guide (GTAGÕ), 12: Auditing IT-projects, The IIA, 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 projectma- nagement. 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.
