Appendix XIII: Interview #11 167

Zoals ik al enigszins in de uitnodiging heb uitgelegd, ben ik een scriptie aan het schrijven over audit planning. Om te beginnen heb ik wat meer introductievragen en later gaan de vragen meer over audit planning. Als eerste, kan je me wat vertellen over jouw rol in de organisatie waarvoor je werkt?

Ja, die is twee weken geleden veranderd. Ik zat bij internal audit en internal audit is onderdeel van de afdeling audit & security en daarin zitten echt de bedrijfsrechercheurs die op pad gaan bij fraudegevallen. Daar zit risk management en internal control onder als afdeling en daar zit intenal audit onder als subafdeling en ik zat dat bij internal audit als senior auditor. Audit planner en senior auditor. En dan in mijn rol ben ik verantwoordelijk voor bepaalde delen van de organisatie waar ik dan van op de hoogte moet blijven en daar de informatie vandaan moet krijgen om zo de kennis binnen de afdeling op dat onderdeel binnenshuis te houden en om het uit te voeren natuurlijk. En dan gaat het om het plannen van de audit, het opzetten van de audit en afwikkelen van de audit. Van de openings meeting tot aan de closings meeting aan toe.

En dat is wat je de afgelopen jaren hebt gedaan?

De afgelopen twee maanden ben ik overgestapt naar de controlling hoek. De andere kant van de lijn zeg maar. Mijn verhaal vertel ik meer vanuit mijn vorige rol.

Hoe lang ben je al onderdeel van de organisatie waar je nu zit?

6 jaar.

Zoals aangegeven heb ik veel informatie geput uit TeamMate en je gaf aan dat je TeamMate ook kent. Werk je veel met planning programma’s?

Nee. Wij hebben TeamMate en gebruiken dat voor internal audit, maar daar gebruiken we eigenlijk alleen de database van. Niet de hele planningssectie. TeamSchedule en TeamRisk dat gebruiken we allemaal niet. We gebruiken meer de working papers, ook om het in de database op te slaan en om audits gewoon vast te kunnen leggen. Per audit maken we een dossier aan in TeamMate en in ieder dossier behandelen wij onze bevindingen, onze documenten, beschrijvingen en dat sluiten we af in de database en dat is hoe we TeamMate gebruiken. Voor de planning gebruiken we gewoon Excel sheets. Om duidelijk te stellen: in audits heb je twee soorten planning. 1 is planning wat ga je auditen en waarom ga je iets auditen en wanneer ga je iets auditen. Wanneer en wie. En het tweede is echt per project planning per audit, waar ga je heen, wie moet ik spreken, welke onderdelen hebben risico, hoeveel tijd ga ik er aan besteden. Hoeveel samples neem ik, etc. Op welke spits jij je onderzoek?

168

Daar komen we straks op terug, maar ik ben me ervan bewust dat er twee niveaus zijn van planning. Je jaarlijkse planning en je engagement planning. Ik ga me niet zozeer op een van de twee toespitsen op dit moment.

Voor de duidelijkheid: wij doen de engagement planning in TeamMate en de jaarplanning in Excel.

Wat zie jij als het voornaamste doel van een audit?

Het voornaamste doel is vaststellen of er risico’s zijn die de organisatie niet heeft afgedekt. En dan zowel financiële risico’s als operationele risico’s.

Hoe zou je het audit proces beschrijven?

Je begint in eerste instantie met, je zou een reden moeten hebben om een audit uit te voeren. Dat zou gebaseerd moeten zijn op risico analyse. Op het moment dat jij ergens een risico detecteert of vermoedelijk risico hebt, waar jij wilt vaststellen of er voldoende interne controlemaatregelen zijn om het risico af te dekken. Dan zou je daar een audit kunnen plannen. Dus het begint bij risico analyse. Daarna ga je de scope bepalen; wat ga je afdekken. Welke risico’s wil je afdekken met welke audit werkzaamheden ga je dat doen. Je moet bedenken hoe diep je moet gaan. In het begin is dit nogal globaal. Op dat moment ga je de audit inplannen. Je gaat je werkprogramma’s maken die aansluiten met je scope. Vervolgens ga je afspraken maken met de business. Je gaat de audit uitvoeren, je bevindingen bespreken en erover rapporteren. Dat is globaal hoe ik het audit proces zie.

Als ik het goed begrijp is het risk assessment het belangrijkste onderdeel?

Ja, dat is de reden waarom je de audit uitvoert inderdaad ja. Als je geen risico’s ergens hebt of materiele fouten naar voren komen, dan zal je niet heel snel een audit uitvoeren. Dan praat ik wel over een situatie waarin je de tijd goed kan besteden. Op het moment dat je tijd zat hebt in je planning, dan ga je ook naar plekken waar het goed loopt, om te kijken of het daadwerkelijk wel goed loopt. Maar ik neem aan dat niet veel bedrijven tijd over hebben. Dus wil je je tijd goed besteden, dan doe je dat waar je denkt dat je risico loopt.

En dat is de reden waarom je een risico analyse doet, zodat je aan het pinpointen bent daar zijn de grootste risico’s en daar moeten we onze aandacht op vestigen.

Ja, je maakt een audit plan op basis van een risico analyse. Een audit jaarplan. Hoe het jaarplan tot stand komt is dat we afspraken maken met alle FD’s van de bedrijfsonderdelen. Daar bespreken wij de ontwikkelingen door die er geweest zijn of die er komen en waar zij eventuele risico’s zien. En met onze kennis daarbij en wat wij zelf hebben gehoord, komt een audit plan tot stand met de belangrijkste risico’s. Daarmee classificeren wij audits op niveau 1, 2 en 3. Waarbij 3

de minder belangrijke, waar de minder grote risico’s zijn. Die zullen ook geschrapt worden als er verzoeken of nieuwe dingen naar voren komen.

Dus het is een samenspel van de financial directors en het audit team om de grootste risico’s te bepalen. Dan ga je de grootste risico’s afwegen, die ga je classificeren. En dan pak je degene met de hoogste risico daar ga je je als eerste op focussen?

Wellicht niet als eerste, maar die komen sowieso aan de beurt. Urgente risico’s gaan altijd voor. Als wij als internal audit een berichtje krijgen dat er fraude is gepleegd, dan staan we de volgende dag op de stoep.

Nou is met name risk assessment is een term die ik ken uit het Coso framework. In hoeverre wordt het Coso framework gebruikt in auditing?

Je zou bijna willen zeggen dat het meeste wel gestoeld is op het Coso framework. Het komt in heel veel literatuur terug en volgens mij wordt er heel veel naar verwezen. In feite gaat het ook om welke controls jij in je environment hebt ingericht om risico af te dekken. En daar gaat Coso ook helemaal over. Translation: You'd say that most of it is based on the Coso framework. It comes back a lot in literature and I think there is quite a lot of reference to it. In fact it is also a question of what controls you have in your environment designed to hedge risk. And that’s what Coso is all about.

Coso geeft ook een bepaalde verplichting om een aantal stappen door te lopen.

Ja, ik denk dat de elementen allemaal terug komen. Het is als het ware zo’n ingeburgerd begrip. Het is allemaal zo verweven. Veel dingen die in het Coso framework staan, die kom je ook tegen in je audits.

Een ander deel van mijn onderzoek zijn ERP systemen. Ben je daar bekend mee?

Nauwelijks moet ik eerlijk zeggen. Ik doe er niet veel mee. Je hebt SAP natuurlijk, dat is er eentje. En dat gebruiken wij in onze organisatie. Ik ben geen expert in SAP.

Mijn onderzoek gaat ook niet over in hoeverre hoe een ERP systeem in elkaar steekt, maar er zijn een aantal dingen die typisch zijn aan een ERP systeem en dan doel ik met name op dat de data maar op 1 punt in het systeem wordt gezet, omdat je maar 1 database hebt over de verschillende onderdelen van een proces heen. Het tegenovergestelde is dat iedere onderdeel van een proces heeft zijn eigen systeem met zijn eigen database. En dat er tussen de databases ofwel gecommuniceerd moet worden ofwel dat de data in de twee verschillende systemen ingevoerd moeten worden. Mijn onderzoek is dan of het gebruik van een ERP systeem, wat voor impact dat heeft op de risk assessment van de audit planning.

Tuurlijk heeft dat impact. Er komen hele andere risico’s daarbij kijken. Samenvatting van deel met bedrijfsgevoelige informatie: Er kunnen problemen ontstaan in de master data. Translation:

170 Then you’re dealing with completely different risks. Problems can arise in the master data. Als je allerlei verschillende systemen hebt, dan wordt het belangrijk om een IT auditor te betrekken bij de audit om de interfaces te bekijken tussen de systemen. Bij het gebruik van een ERP systeem, kom je veel meer op het gebied van toegangsrechten, gebruikersrechten, beveiliging, beheer van je data. Tuurlijk heb je dat ook bij het gebruik van verschillende systemen, maar dat is meer lokaal geregeld en het risico is kleiner, omdat je maar een klein deel van je data daar hebt staan. Bij een ERP systeem staat alles centraal en als iemand al die informatie heeft, dan krijgt deze wel heel veel kennis en macht en gelegenheid tot wat je maar kan bedenken. En daarmee een groot risico. En bij de audit over losse onderdelen zal de focus gelegd worden op de juistheid van de interface, input = output, ga zo maar door. Terwijl bij een ERP systeem het risico veel meer ligt bij gebruikersrechten. Translation: While in an ERP system the risk is much more in user rights. Bij de implementatie van een ERP systeem wil je als audit ook meekijken, al is dat meer een IT auditor.

Iets verder kijken naar een omgeving met mutliple points of data entry. Bij een non ERP omgeving heb je verschillende punten van data entry, in het geval dat er geen interfaces zijn. Je hebt dus verschillende databases. Daarbij heb je een controlemethode om de verschillende databases met elkaar te vergelijken. En daar waar het niet overeenkomt, daar kan je op inzoomen. Dat is een controlemethode. Bij een ERP systeem is er maar 1 punt waar de data wordt ingevoerd. En heb je deze controlemethode niet. Hoe zie je dat dat impact heeft op de risk assessment?

Ik heb daar nooit eerder over nagedacht. Als het goed is heb je automated controls in je ERP systeem zitten die dat voorkomen. Je zou de application controls of database controls moeten controleren of die daadwerkelijk werken. Translation: Automated controls in your ERP system should prevent that. You should check the application and database controls if they work correctly.

Dat zijn controles dat je geen hele gekke getallen invult, bijvoorbeeld?

Ja, zulk soort dingen, maar ook dat twee mensen tegelijk de data kunnen veranderen. Dat heb je natuurlijk ook. Als het goed is zit daar ook een databasecontrol, automated control op in een ERP systeem. Dat als op het moment dat iemand in de database is aan het muteren, dat een ander niet kan muteren. Dan wordt hij on hold gezet. Op het moment dat dat niet het geval is, dan krijg je hele corrupte data. Je zit hier op de IT auditors hoek naar de risico’s te kijken. Ik denk dat je risico analyse veel belangrijker is bij een ERP systeem, dat je daar een IT auditor bij betrekt.

Ja, het zit allemaal onder water. De interne controlemaatregelen zitten allemaal onder water. Terwijl je elders heb je twee databases tegelijk, dus heb je een soort norm. 1 systeem is de norm en daar zou het andere systeem aan gelijk moeten zijn. Op het moment dat je dat niet kan vaststellen omdat er maar 1 database is, dan zal je andere controlemaatregelen moeten hebben. En zal je de audit en zijn risico’s daarop moeten richten.

Dat is met name dan je segregation of duties en een aantal controles in het systeem zodat je niet gelijktijdig of dat je niet dezelfde data kan invoeren en zorgen dat niet iedereen overal bij kan.

Ja, maar het is in beide gevallen net zo belangrijk hoor. Ik zou me kunnen voorstellen dat bij een single entry point je zekerheid (assurance) moet halen uit automated controls. IT controls.

Bij een ERP systeem krijg je dat bijvoorbeeld een inkoper een purchase order in het systeem schiet en deze is niet per se een financieel persoon, maar zijn input heeft uiteindelijk wel invloed op de financial statement. Zie je daar een impact op de risico analyse?

In zoverre dat de risico analyse kijkt naar hoe het proces is ingericht. Een purchase order hoeft niet per se door een financieel persoon ingeklopt te worden. Sales is misschien hetzelfde verhaal. Die voeren ook sales orders in. Het zijn meer de controles er omheen. Als die purchaser zelf gemachtigd is om alle purchase orders in te voeren en de facturen worden automatisch betaald als deze matched met de purchase order, dan zit er een risico in. Dan ga je naar autorisatie levels kijken. Wie mag tot welk bedrag goedkeuren? En is die purchase order wel goedgekeurd. Dan ga je naar je reguliere purchase to pay risico’s kijken.

Dat is dus niet anders tussen een ERP omgeving en een non ERP omgeving?

Ik heb zo veel verschillende manieren gezien hoe je tot een betaling van een factuur kan komen, waarbij de ene uitgaat van het invoeren van een purchase order in het systeem, en op het moment dat de factuur wordt ingeboekt en er is geen verschil met de purchase order, wordt hij ook automatisch betaald. Dan moet de purchase order ook voldoende betaalbevoegdheid autoriteit moet hebben. Op het moment dat jij een purchase order invoert van 1 miljoen, dan zal iemand moeten tekenen die een betalingsbevoegdheid heeft tot 1 miljoen. Op het moment dat deze autorisatie pas gegeven wordt bij het invoeren van de factuur, dan wordt een purchase order al minder belangrijk, omdat de autorisatie pas bij de factuur komt. Natuurlijk voor je proces moet je nog steeds je purchase order autorisatie hebben. Je wilt natuurlijk niet dat iedereen in het bedrijf maar gaat bestellen wat ze willen. Maar het wordt wel gesignaleerd door de juiste personen als de factuur komt. Dan is het risico niet heel groot. Als de factuur betaalbaar wordt gesteld op basis van de purchase order, dan wordt het risico bij de purchase order wordt natuurlijk groter. Ik denk dat het niet zozeer afhangt van de persoon die het invoert, maar hoe het proces is ingericht.

172

Je hebt bijvoorbeeld ook te maken met verschillende locaties. Bij een ERP systeem kan een invoer in een warehouse kan 100 km van het accounting systeem af zijn.

Ik zou dat niet als een risico zien als dat nou op de begane grond zou zijn of aan de andere kant van de wereld. Daar zie ik geen risico in. Translation: I wouldn’t see that as a risk. It does not result in a higher risk if it is entered on the ground floor compared to entering on the other side of the world.

En ook niet als het om totaal andere culturen gaat?

Daar zou wel een extra risico in kunnen zitten. Als je kijkt naar Afrika, maar daar is je algehele risico hoger. En dan ga je zelf ook zoeken als auditor naar meer zekerheid. Dan ga je hogere deelaannemingen nemen. Daar in landen waar omkoping en samenspanning op management een heel dominante rol heeft, dat zie je sowieso als een hoger risico.

Maar dat is onafhankelijk of je een ERP systeem zou hebben of niet. Dat ligt gewoon aan de cultuur die er eventueel is.

Ja, klopt. Ik zie dat niet als ERP issue.

Nog heel even terugkomend op mijn algehele vraag van mijn onderzoek: of een ERP systeem impact heeft op de risk analyse binnen de audit planning. En zelf heb je ook aangegeven dat er twee niveaus zijn van audit planning en daarmee ook twee niveaus van risico analyse. Bij de jaarlijkse audit planning en die risico analyse, denk je dat het gebruik van een ERP systeem daar invloed op zou hebben of niet?

Ja, dat denk ik wel. Ik denk dat je sowieso een veel centralere rol oppakt. Je audit object is 1 database. En 1 set van automated controls, application controls, noem maar op. Bij geen ERP systeem heb je te maken met losse systemen, losse locaties, losse bedrijfsafdelingen, andere mensen, waarbij je veel meer tijd kwijt bent vermoedelijk met het auditen van deze onderdelen. Translation: Your audit object is one database and one set of controls, application controls amongst other controls. With non ERP systems you’re dealing with separate systems, different locations, different departments, other people, where you probably need a lot more time in auditing these parts. Plus het feit dat je bij ERP systemen dat je IT hebt. Dat is dan technisch vooral. Maar procesmatig, elke locatie heeft zo zijn eigen processen, maar de inrichting van IT is wat dat betreft, geen interfaces, iedereen heeft dezelfde set of controls onder water zitten. En bij niet ERP systemen is dat heel verschillend natuurlijk. Dan moet je elke keer opnieuw uitzoeken hoe dat zit. Dat is misschien heel anders ingericht. Dan kan ik me voorstellen dat je een roulatiesysteem, waarbij je het ene jaar het ene systeem en het andere jaar het andere systeem controleert. Want je kan waarschijnlijk niet alles in 1 jaar pakken. En dat kan bij een ERP systeem waarschijnlijk wel. In die mate kan ik me zeker voorstellen dat het invloed heeft op je

audit planning. Translation: But processwise, each location has its own processes, but the design of IT is, no interfaces, everyone has the same set of controls underneath. And at non ERP systems that is very different of course. Then you have to investigate every time again. That might be quite different. Then I can imagine that you have a rotation system, where you check one year one system and the other year the other system. Because you probably can’t do everything in one year. And in an ERP system you probably can. To that extent, I can certainly