Onderzoek naar het geautomatiseerd gegevensgericht testen van functiescheidingen in het inkoopproces

Onderzoek naar het geautomatiseerd gegevensgericht testen van functiescheidingen in het inkoopproces Student Ruud Schellekens M. Sc. (1172816) Deloitte Accountants B.V. E-mail rschellekens@deloitte.nl Telefoon +31 (0)6 2078 9945 Student Drs. Suzanne de Vries (1005294) Deloitte Accountants B.V. E-mail sdevries@deloitte.nl Telefoon06 1258 0225 Begeleider Deloitte Mr. Wouter-Bas van der Vegt RE Deloitte Accountants B.V. E-mail wvandervegt@deloitte.nl Telefoon +31 (0)6 5111 0742 Begeleider VU Dr. Bob van Kuijck RA RC E-mail vankuijck.bob@hetnet.nl Telefoon +31 (0)6 5136 6752 1

Inhoudsopgave Voorwoord 4 1 Inleiding 5 1.1 Aanleiding voor het onderzoek 5 1.2 Probleemstelling 8 1.3 Onderzoeksvragen 8 1.4 Onderzoeksaanpak 9 1.5 Leeswijzer 9 2 Theoretische studie: inkoopproces, functiescheiding en vastlegging 11 2.1 Inleiding 11 2.2 Inkoopproces 11 2.3 Functiescheiding 14 2.4 Minimaal benodigde informatie 16 2.4.1 Vastlegging van data in ERP-applicaties 16 2.4.2 Rijkdom van de informatie 17 2.4.3 Benodigde informatie voor testen functiescheiding in het inkoopproces 18 2.5 Conclusie 20 3 Theoretische studie: randvoorwaarden voor geautomatiseerde gegevensgerichte analyse 21 3.1 Inleiding 21 3.2 Primaire vastleggingen in de ERP-applicatie 21 3.3 Organisatorische inrichting 22 3.3.1 Implementatie van functiescheidingen in logische toegangsbeveiliging 23 3.3.2 Logische beveiliging van de audit trail 24 3.4 Conclusie 24 4 Theoretische studie: analysetechnieken 26 4.1 Inleiding 26 4.2 Criteria ter beoordeling van automatische analysetechnieken 26 4.2.1 Integriteit van de data tijdens de analyse 27 4.2.2 Data Volumes en Formaten 27 4.2.3 Data Verwerking en Analyse 28 4.2.4 Analysesnelheid 29 4.2.5 Conclusie 29 4.3 Mogelijke analysetechnieken 30 4.4 Beoordeling Process Mining (ProM) en Linear Temporal Logic (LTL) 30 4.5 Beoordeling Audit Command Language (ACL) 32 4.6 Beoordeling SAS 33 2

4.7 Beoordeling Structured Query Language (SQL) 34 4.8 Analyse 35 4.9 Conclusie 38 5 Casusbedrijf 1: Het productiebedrijf 39 5.1 Inleiding 39 5.2 Beschrijving organisatie 39 5.3 Het inkoopproces bij het productiebedrijf 40 5.4 Aanwezige randvoorwaarden 40 5.5 Dataset definitie 42 5.6 Te testen functiescheidingen 43 5.7 Keuze analysetechniek 44 5.8 Resultaten 45 5.9 Analyse 51 5.10 Conclusie 52 6 Casusbedrijf 2: Het detailhandelsbedrijf 54 6.1 Inleiding 54 6.2 Beschrijving organisatie 54 6.3 Het inkoopproces bij het detailhandelsbedrijf 55 6.4 Aanwezige randvoorwaarden 55 6.5 Dataset definitie 56 6.6 Te testen functiescheidingen 57 6.7 Keuze analysetechniek 59 6.8 Resultaten 60 6.9 Analyse 62 6.10 Conclusie 63 7 Algemene analyse en conclusie 65 7.1 Inleiding 65 7.2 Discussie terugkoppeling van de resultaten naar het theoretische model 65 7.3 Randvoorwaarden 66 7.4 De gevolgde analyse aanpak 67 7.5 Resultaten 70 7.6 Gevolgen voor de jaarrekeningcontrole 71 7.7 Conclusie 73 Literatuur 75 3

Voorwoord Deze scriptie is voor beide auteurs de afsluiting van de EDP-auditopleiding aan de Vrije Universiteit van Amsterdam. De afgelopen jaren hebben wij zowel in de praktijk als aan de opleiding ervaring opgedaan op het gebied van IT-auditing. Binnen dit vakgebied hebben wij beide een focus op datagerichte controles. Een interessant werkgebied om diverse redenen. In het algemeen, maar ook specifiek binnen de accountantscontrole moet steeds meer rekening gehouden worden met kritische gegevens die in toenemende mate alleen in digitale vorm beschikbaar zijn. Daarnaast kan de jaarrekeningcontrole ook efficiënter en effectiever worden uitgevoerd door meer gebruik te maken van informatie die in applicaties binnen een organisatie wordt vastgelegd. Grote hoeveelheden data zijn beschikbaar door alle vastleggingen in applicaties. Door middel van (geautomatiseerde) analyse van deze data is het mogelijk antwoord te geven op diverse vragen van de accountant in het kader van de jaarrekeningcontrole. Eén van de vragen die een accountant heeft ten aanzien van de jaarrekening, is hoe te bepalen wat de impact is van geconstateerde functievermenging in de autorisatiematrix. Deze scriptie geeft een handvat om antwoord te geven op deze vraag. Wij hopen hiermee een bijdrage te hebben geleverd aan een meer efficiënte en effectieve uitvoering van de jaarrekeningcontrole. Daarnaast hopen wij hiermee een voorbeeld te geven voor overige data analyses die kunnen bijdragen aan het oplossen van vraagstukken voor de accountant. Wij hebben met plezier gewerkt aan deze scriptie. Bij deze willen wij onze begeleiders, Bob van Kuijck en Wouter-Bas van der Vegt, hartelijk bedanken voor hun kritische en constructieve bijdrage in het proces om te komen tot dit eindresultaat. 4

1 Inleiding Zoals in bijna ieder vakgebied inmiddels wel het geval is, is ook in het audit domein de impact van automatisering merkbaar. Deze heeft niet alleen de functie als ondersteunende software (bijvoorbeeld een tekstverwerker of een presentatieprogramma), maar ook steeds vaker in de actieve rol als audit tool. Hierdoor ontstaat er een nieuwe manier om een audit uit te voeren naast de traditionele werkwijze, evenals nieuwe mogelijkheden qua auditmethodiek en -technieken. Voor onze scriptie zullen we een van die mogelijkheden onderzoeken op haalbaarheid in de praktijk evenals het theoretische kader scheppen waarbinnen deze nieuwe aanpak gegrond kan worden. Dit hoofdstuk start met een paragraaf over de aanleiding voor ons onderzoek. Dit begint met het in hoofdlijnen beschrijven van de huidige dominante audit aanpak in de jaarrekeningcontrole en de beperkingen hiervan. Vervolgens zullen wij ingaan op de nieuwe ontwikkelingen die spelen in het audit domein. Op basis van de nieuwe ontwikkelingen formuleren we de onderzoeksvraag. De onderzoeksvraag wordt ingeperkt door een aantal keuzes op het gebied van de scope. Tot slot van het hoofdstuk wordt de onderzoeksvraag uitgesplitst naar de verschillende subvragen en wordt de structuur van de scriptie gegeven. 1.1 Aanleiding voor het onderzoek Huidige dominante audit aanpak Traditioneel gaat de accountant uit van de systeemgerichte controleaanpak. De accountant bekijkt de organisatie en de risico s daarin en maakt dan een controle aanpak die vaak gericht is op het controleren van processen. Indien er in het proces gebruik gemaakt wordt van IT-systemen en deze dominant genoeg aanwezig zijn, zal er een IT-auditor betrokken worden in het controle proces. De IT-auditor test dan voor de betrokken IT-systemen of de beheersingsmaatregelen in opzet, bestaan en werking effectief zijn geweest in de controleperiode. Hiermee verkrijgt de accountant zekerheid over het bedrijfsproces en de vastleggingen hierin waardoor deze minder gegevensgericht hoeft te controleren tijdens de jaarrekeningcontrole (Kemp, 2006) en (NIVRA, 2009). Deze strategie wordt als efficiënt beschouwd omdat hiermee gegevensgerichte controles beperkt kunnen worden door de zekerheid verkregen uit de systeemgerichte controle op de processen. Gegevensgerichte controles namelijk zijn vaak duur om uit te voeren vanwege de grote hoeveelheid handmatig werk die hiermee gepaard gaat om elke casus te beoordelen. De beperkingen van de huidige aanpak Een beperking aan een systeemgerichte aanpak is dat deze geen kwantificering van het risico geeft indien een beheersingsmaatregel niet effectief is geweest. Een voorbeeld hiervan is het testen van de inrichting van functiescheidingen in een geautomatiseerde omgeving. 5

Indien de geïmplementeerde functiescheidingsmaatregel niet effectief is geweest gedurende de te controleren periode geeft dit nog geen uitspraak over: 1. hoe vaak zich een transactie heeft voorgedaan waarbij daadwerkelijk sprake was van functievermenging in het proces (onrechtmatigheid in de procedure); 2. of er in geval van functievermenging ook daadwerkelijk sprake is van een niet getrouw beeld van de informatie (was de transactie naast onrechtmatig ook ongeoorloofd); 3. hoe groot de monetaire de impact is van de transacties. Hierdoor is het risico voor het getrouwe beeld van de jaarrekening dus lastig te bepalen op basis van alleen de systeemgerichte aanpak. Of de functievermenging zich daadwerkelijk heeft voorgedaan en wat voor bedrag hier mee gemoeid ging, blijkt niet uit het ineffectief zijn van een maatregel. Het schatten van het risico, de kans van optreden keer de verwachte impact, is in dit geval moeilijk. Om alsnog het risico te kwantificeren moet de accountant additioneel werk verrichten op de gegevens en de diepgang van het onderzoek dus vergroten. Echter, uit zijn systeemgerichte aanpak komen verder geen aanwijzingen over welke transacties mogelijk afwijkend zijn van het standaardproces en dus extra aandacht verdienen. Hij moet eerst zoeken naar transacties waarbij functievermenging is opgetreden alvorens hij kan nagaan of deze transacties inderdaad ongeoorloofd waren. Om toch zekerheid te verkrijgen zou de accountant een steekproef op de applicatie kunnen doen, waarbij de brondocumentatie moet worden opgezocht en gecontroleerd. In de traditionele situatie betekent dit dat handmatig facturen, bestellingen etc. gecontroleerd moeten worden. In een (hoog) geautomatiseerde omgeving moet additioneel werk gedaan worden in de vorm van de analyse van logbestanden en transactiebestanden om zo te achterhalen welke handeling met betrekking tot een bepaalde transactie door welke medewerker is uitgevoerd. De accountant kan op deze wijze de functievermenging constateren en, als de verbinding te leggen is naar het transactiebedrag, ook de maximale fout berekenen voor de controle. In beide omgevingen, traditioneel en geautomatiseerd, is dit traject van beschreven werkzaamheden echter voor accountant en klant een erg arbeidsintensieve manier van controleren. Nieuwe ontwikkelingen met impact op het audit domein Momenteel zijn een aantal ontwikkelingen waarneembaar in de techniek die hun impact hebben op de jaarrekeningcontroles. Hieronder lichten we er drie uit die relevant zijn voor de hierboven beschreven problematiek. De eerste ontwikkeling is de verschuiving van vastleggingen in het proces van fysieke vastlegging naar digitale vastlegging. De tweede ontwikkeling is het soms geheel ontbreken van fysieke vastleggingen bij internetgebaseerde bedrijven. De derde is de toename in reken- en opslagcapaciteit. 6

Verschuiven van fysieke naar digitale vastlegging Vaak vanuit efficiency oogpunt, is er bij veel bedrijven momenteel een digitaliseringslag gaande. Trend is dat steeds vaker van fysieke documentatie wordt afgestapt. Een voorbeeld hiervan is dat papieren facturen worden vervangen door digitale facturen (ANP, 2009). De fysieke vastlegging op papier is aan het verdwijnen of wordt in ieder geval in de procesgang slechts in digitale vorm, na inscannen, gebruikt. Opkomst van volledig digitale bedrijven Sommige bedrijven, internet gebaseerde bedrijven, hebben hun hele bedrijfsproces gedigitaliseerd (Bolluijt, 2001). Het verkopen van digitale muziek via internet bijvoorbeeld of het verkopen van online advertenties. Alle vastleggingen in het proces zijn digitaal. Er is geen product meer dat opgeslagen hoeft te worden, geen pakbonnen en afgifte bewijzen of facturen. Dit impliceert dat voor sommige bedrijven geen primaire fysieke vastlegging meer te achterhalen is buiten de ICT-systemen om. In de controle aanpak van de accountant is het in dit geval niet mogelijk om het systeem heen te controleren. De accountant zal hier rekening mee moeten houden in zijn aanpak. Uitbreiding van de reken- en opslagcapaciteit Een derde ontwikkeling is dat de verwerkingscapaciteit en de opslagcapaciteit nog steeds elke anderhalf jaar tot twee jaar ongeveer verdubbelen (Moore, 1965; Walter, 2005). Hierdoor is het inmiddels mogelijk om grote volumes data te verwerken en op te slaan op relatief goedkope en toegankelijke IT-middelen. Daarnaast zijn betere softwareprogramma s beschikbaar om deze datavolumes snel en effectief mee te doorgronden. Wellicht is het nu mogelijk om geautomatiseerd gegevensgericht beheersingsmaatregelen te testen in gevallen waar dit eerst niet efficiënt was of in gevallen waar de beheersingsmaatregel gefaald heeft. Evaluatie De systeemgerichte controle aanpak heeft dus beperkingen indien de controle als conclusie heeft dat niet alle beheersingsmaatregelen effectief waren. Het is dan lastig om het risico te kwantificeren. In dit geval is additioneel handmatig audit werk nodig om het risico helder te krijgen. Dit vergt veel extra tijd aan zowel de zijde van de accountants als aan de zijde van de klant. Echter, door nieuwe technieken in te zetten en gegevensgerichte testwerkzaamheden te automatiseren is het wellicht mogelijk om de diepgang van de accountantscontrole en de impact op de jaarrekening integraal vast te stellen. Dit vergt wel dat de te controleren omgeving een digitaliseringgraad heeft dit hoog genoeg is. Omdat veel bedrijven momenteel al aan het digitaliseren zijn, wordt deze aanpak in de toekomst alleen maar relevanter. Voor sommige (vaak internetgebaseerde) bedrijven vindt al geen fysieke vastlegging meer plaats. Dit vraagt om een onderzoek naar de haalbaarheid van het geautomatiseerd gegevensgericht controleren. 7

1.2 Probleemstelling Zoals in de inleiding aangegeven is het voor een accountant moeilijk om in de huidige controle aanpak het risico voor de jaarrekening te bepalen indien de systeemgerichte controleaanpak op sommige punten niet effectief blijkt te zijn. Daarom willen we het volgende in deze scriptie onderzoeken: Gegeven een bedrijf waarbij is vastgesteld dat functievermenging in het inkoopproces mogelijk is opgetreden gedurende de audit periode, is de probleemstelling: Kun je uit de logbestanden en transactie data in de financiële administratie bepalen of in de praktijk daadwerkelijk functievermenging heeft plaatsgevonden en wat zijn de gevolgen hiervan voor de jaarrekeningcontrole? Deze probleemstelling zal beantwoord worden aan de hand van praktijksituaties. Hiervoor nemen we praktijkcasussen van bedrijven die een ERP-applicaties in gebruik hebben. Omdat dit onderzoek slechts een beperkte tijd kent, hebben we de volgende keuzes gemaakt met betrekking tot de scope van het onderzoek: 1. In dit onderzoek beperken we ons tot het inkoopproces. 2. We beperken ons tot het testen van de beheersingsmaatregelen voor functiescheiding en zullen dus geen andere maatregelen beoordelen. 3. In onze analyse beperken we ons tot twee datasets van verschillende bedrijven. Gegeven de scope en onderzoeksvraag kunnen we een aantal onderzoeksvragen en subvragen definiëren. Zie hieronder de structuur voor alle onderzoeksvragen en bijbehorende hoofdstukken. 1.3 Onderzoeksvragen In de nu volgende paragrafen zullen we de structuur van dit onderzoek en de diverse onderzoeksvragen uiteen zetten. Het doel van deze scriptie is het onderzoeken of het automatisch testen van functiescheidingen mogelijk is. De probleemstelling valt uiteen in de volgende onderzoeksvragen tevens de volgende hoofdstukken: Wat is het theoretische referentiekader van het inkoopproces van waaruit we de casussen zullen beoordelen? (Hoofdstuk 2) Welke randvoorwaarden moeten vervuld zijn in de organisatie en in de applicaties om op opgetreden functievermenging te testen? (Hoofdstuk 3) Welke analyse technieken zijn er om geautomatiseerde gegevensgerichte analyses uit te voeren voor functiescheidingen? (Hoofdstuk 4) 8

Wat is het resultaat van toepassing van het theoretisch kader in de praktijk? (Hoofdstuk 5 & 6) In het laatste hoofdstuk, hoofdstuk 7, bekijken we of we de onderzoeksvraag kunnen bevestigen dan wel weerleggen op basis van de resultaten van het onderzoek. 1.4 Onderzoeksaanpak Omdat het uitvoeren van een gegevensgerichte functiescheidingscontrole, voor zover bij de auteurs bekend, nog niet eerder is uitgevoerd is het pad daar naartoe per definitie een onderzoekspad. Er is in de literatuur dus geen best practice te vinden om dit op te baseren. We hebben onze onderzoeksaanpak gebaseerd op de standaard aanpak voor data analyse zoals gebruikelijk is binnen de data-analyse praktijk van Deloitte. Hierin hebben we de volgende stappen onderkend: 1) Onderzoeken van de software pakketten die betrokken zijn bij het inkoopproces 2) Verkrijgen van het schema dat aangeeft waar in de applicatie de benodigde informatie zit met betrekking tot de door ons gekozen functiescheidingen (zie hoofdstuk 2) 3) Extraheren/transporteren van de data uit de ERP-applicatie 4) Plotten van de ontvangen data naar de mogelijk te testen functiescheidingen in het standaard inkoopproces (in het geval van incomplete of niet eerder geanalyseerde data) 5) Geautomatiseerd gegevensgericht testen van de functiescheidingen met behulp van analyse software 6) Validatie van de resultaten met de gecontroleerde partij Deze stappen zullen we aanhouden bij het uit te voeren onderzoek bij de twee casusbedrijven in hoofdstuk 5 & 6. 1.5 Leeswijzer We zullen beginnen met het scheppen van het theoretisch raamwerk in hoofdstuk 2. Dit raamwerk dient als norm om de uiteindelijke analyseresultaten te kunnen plaatsen in een context. In hoofdstuk 3 geven we de belangrijke randvoorwaarden die nodig zijn geautomatiseerd gegevensgericht te controleren. Vervolgens geven we in hoofdstuk 4 een theoretische vergelijking van de verschillende analysetechnieken die mogelijk zijn voor de werkzaamheden. Op basis hiervan kan later een keuze gemaakt worden per casusbedrijf voor de meest geschikte analysetechniek. Nu het theoretische raamwerk in de eerste vier hoofdstukken is neergezet, kunnen we in hoofdstuk 5 en 6 een beschrijving geven van de twee casusbedrijven. In deze hoofdstukken zetten we per casusbedrijf uiteen wat de resultaten zijn van de toepassing van het theoretisch kader in de praktijk. In beide hoofdstukken worden ook de gevolgen van deze resultaten voor de jaarrekeningcontrole behandeld. 9

Tot slot zullen we de resultaten uit de casussen terugkoppelen naar de onderzoeksvraag in hoofdstuk 7. Ook bediscussiëren we hier of de onderzoeksvraag beantwoordt kan worden op basis van het onderzoek. 10

2 Theoretische studie: inkoopproces, functiescheiding en vastlegging 2.1 Inleiding In dit hoofdstuk zullen we de basis leggen van de theoretisch achtergronden. Doel van het theoretisch kader is om de onderzoeksresultaten die later uit de casussen met bedrijfdata komen te kunnen plaatsen en te kunnen vergelijken in een vooraf gedefinieerde context. De onderzoeksvraag voor dit hoofdstuk is dus gericht op het literatuur onderzoek en luidt: Wat is het theoretische referentiekader van het inkoopproces van waaruit we de casussen zullen beoordelen? Het is belangrijk vooraf goed uit te denken welke informatie cruciaal is in het geautomatiseerd gegevensgericht testen van de functiescheidingen. Hiervoor is het allereerst nodig de stappen in het inkoopproces goed te kennen, maar ook om te weten wat functiescheiding zelf inhoudt en waar dit belangrijk is in het inkoop proces. De onderzoeksvraag voor dit hoofdstuk valt dus uiteen in de volgende subvragen: Hoe ziet het standaard inkoopproces eruit? Wat is functiescheiding? Welke functiescheidingen onderkennen we in het standaard inkoopproces? Wat zijn de benodigde informatie behoeften om de functiescheidingen in het inkoopproces te kunnen testen? De structuur van dit hoofdstuk is als volgt. In paragraaf 2.2 wordt het inkoopproces uiteen gezet, gevolgd in paragraaf 2.3 door een uitleg over functiescheiding in het algemeen en functiescheiding in het inkoopproces. Als dan duidelijk is op welke punten geautomatiseerd gegevensgericht testen wenselijk is, wordt in de paragraaf 2.4 beschreven welke informatie hiervoor benodigd is in de applicatie. Dit hoofdstuk wordt afgesloten met een conclusie. 2.2 Inkoopproces Dit onderzoek richt zich specifiek op functiescheiding in het inkoopproces. (Weele, 2008) definieert inkoop als volgt: Inkoop omvat de analyse, planning, implementatie en beheersing van activiteiten die gericht zijn op het ontwikkelen, uitbouwen en onderhouden van de relaties met de leveranciersmarkt ter bevrediging van de korte- en lange termijn inkoopbehoeften van een onderneming, teneinde een optimale bijdrage aan de ondernemingsdoelstellingen te bewerkstelligen. 11

In deze definitie is inkoop een marktgerichte ondernemingsactiviteit die verder strekt dan een zuiver uitvoerende en administratieve activiteit. Grofweg kan het operationele inkoopproces in de volgende stappen onderverdeeld worden: 1. Impuls tot inkopen 2. Aanvragen van offerten 3. Bestellen 4. Goederenontvangst 5. Factuurcontrole 6. Factuurregistratie 7. Factuurbetaling In deze stappen is te zien dat een initiatief tot aankoop wordt omgezet in een bestelling, wat leidt tot een goederenontvangst en een factuur die betaald moet worden. Voor dit onderzoek naar functiescheidingen laten wij het eerste deel van het proces buiten beschouwing. In dit eerste stadium van het proces wordt de inkoopbehoefte gespecificeerd, de leverancier(s) geselecteerd en wordt bepaald bij welke leverancier de bestelling daadwerkelijk geplaatst zal worden. Vanaf het punt dat de bestelling wordt opgemaakt, start het proces dat in dit onderzoek bekeken zal worden. Door naar dit tweede deel van het inkoopproces te kijken, van bestelling tot en met factuurbetaling, onderzoeken we de volgende onderdelen van het inkoopproces: 1. Aanmaken en verwerken van bestellingen Nadat een keuze is gemaakt voor een bepaald product wordt de daadwerkelijke bestelling aangemaakt na afgifte van goedkeuring door de geautoriseerde personen. De bestelling wordt in de administratie verwerkt. 2. Registreren van de verplichting behorend bij de bestelling De in de administratie verwerkte bestelling levert (geautomatiseerd) een bijbehorende verplichting op aan de crediteur in kwestie. 3. Ontvangen van goederen of diensten De bestelde goederen of diensten worden na controle op basis van de gegevens van de bestelling in ontvangst genomen. 4. Verwerken en registreren van financiële transacties De factuur wordt voldaan nadat door de geautoriseerde personen goedkeuring is verleend om de betaling uit te voeren. Hierbij worden de factuurgegevens vergeleken met de ontvangstgegevens en de gegevens van de bestelling. Deze functies van het inkoopproces zijn tegelijkertijd de processtappen waarin functiescheidingen essentieel zijn. Indien deze functies in handen zijn van slechts één enkele persoon, is het voor die persoon gemakkelijk om te frauderen. Hier zullen we in meer detail op in gaan in paragraaf 2.3. 12

In de volgende figuur is het procesdeel voor inkoop meer uitgewerkt. Dit is een bewerkte versie van het model dat Jans (Jans, 1989) hanteert. In dit model worden verticaal de verschillende functies in een organisatie onderkend. Het stroomschema laat zien hoe de verschillende documenten door de organisaties stromen en welke activiteiten worden uitgevoerd (Starreveld, van Leeuwen, & van Nimwegen, 2002). Inkoopproces Leverancier Inkoop Magazijn Voorraadadm. Factuurcontrole Crediteurenadm. Grootboek Bestelsignaallijst Bestelsignaallijst Controle bestelling Invoer stam gegevens crediteuren Bestelling Bestelling Bestelling Bestelling Bestelling Boeken op rekening te ontv fact Goederen Goederen Voorraad boeking Controle met bestelling Magazijn ontvangstbon Magazijn ontvangstbon Factuur Magazijn ontvangstbon Magazijn ontvangstbon Voorraad boeking Boeking crediteur Factuur Factuur Betalen factuur Controle factuur Boeken op grbkrekg crediteuren Figuur 1 - Schematische weergave van het inkoopproces (Bron Jans, 1989) Voor het geautomatiseerd gegevensgericht testen van functiescheiding in het inkoopproces gaan we er vanuit dat de handelingen met betrekking tot het inkoopproces zich binnen een ERP-applicatie afspelen. Een bestelling ontstaat als een de behoefte gespecificeerd is en de bestelling door de afdeling inkoop geplaatst wordt bij een leverancier. Dit is doorgaans de eerste vastlegging van de kwalitatieve en kwantitatieve gegevens in de financiële administratie. Deze bestelling wordt uiteraard aan de leverancier doorgegeven, daarnaast wordt de bestelling geboekt in het grootboek als aangegane verplichting. Ook is de bestelling vanaf nu benaderbaar voor het magazijn. Op het moment dat de bestelde goederen binnenkomen in het magazijn, wordt door de magazijnmedewerker de bestelling gecontroleerd en wordt een magazijnontvangstbon (digitaal) opgesteld. Op basis van de magazijnontvangstbon vindt een voorraadboeking plaats. De leverancier zal een factuur opsturen voor de geleverde goederen. De factuur komt binnen op de administratie, hier wordt de factuur gecontroleerd en vervolgens geboekt en betaald door de crediteurenadministratie. Om de risico s in het inkoopproces te beheersen zijn er onder andere twee belangrijke (geprogrammeerde) beheersingsmaatregelen te definiëren, te weten de three-way-match 13

en functiescheiding. Als eerste de three-way-match; dit houdt in dat voorafgaand aan de uitvoering van de betaling een controle wordt uitgevoerd waarbij drie documenten uit het eerder genoemde inkoopproces worden vergeleken. Hierbij worden de kwantitatieve en kwalitatieve kenmerken van de bestelling, de magazijnontvangstbon en de factuur tegen elkaar afgezet. Kenmerken waar het om gaat zijn onder andere de hoeveelheid, de kwaliteit, de prijs van de goederen en de leverancier. Op het moment dat er afwijkingen zijn op een bepaald kenmerk, is dit een reden voor verder onderzoek. Als geen afwijkingen geconstateerd zijn, kan de factuur betaalbaar worden gesteld. Functiescheiding vormt de tweede belangrijke maatregel in het beheerst laten verlopen van het inkoopproces. Deze maatregel vormt is een voorwaarde voor een goed functionerende three-way-match. Bij functiescheiding kan men denken aan scheiding van de registratie- en de beschikkingsfuncties, maar ook aan de autorisatielagen bij de uitvoering van een betaling. Dit onderzoek richt zich specifiek op functiescheiding als beheersingsmaatregel, de three-way-match is niet in scope. In de volgende paragraaf weiden wij verder uit over functiescheiding in het algemeen en over functiescheiding in het inkoopproces. 2.3 Functiescheiding Functiescheiding is één van de kernbegrippen in interne controle en geldt als een organisatorische beheersingsmaatregel. Volgens ISACA wordt functiescheiding als volgt omschreven: A basic internal control that prevents or detects errors and irregularities by assigning to separate individuals responsibility for initiating and recording transactions and custody of assets to separate individuals. De kern van functiescheiding is dat de (combinatie van) functies waarmee ongezien waarde aan de organisatie onttrokken kan worden, niet worden gecombineerd in de taken en verantwoordelijkheden van één functionaris. Hiermee wordt hiermee wordt het risico bestreden dat één enkele persoon in staat is om ongezien waarde aan de organisatie te ontrekken. Er blijft altijd een restrisico van samenspanning tussen meerdere personen bestaan, waartegen ook functiescheiding geen oplossing biedt. Starreveld (Starreveld, van Leeuwen, & van Nimwegen, 2002) geeft de volgende richtlijnen met betrekking tot de doorvoering van functiescheidingen in de organisatie: Functionarissen mogen slechts een beperkt aantal schakels van het totale omloopproces beïnvloeden; Beslissingen over het beschikken over zaken mogen alleen worden genomen door personen die niet zelf met de bewaring van die zaken belast zijn; Personen die als uitvoerders verantwoordelijk zijn voor het rendement van bepaalde technische of commerciële omzettingsprocessen, mogen niet tevens belast zijn met een relatief langdurige bewaring van de aan te wensen respectievelijk verkregen goederen c.q. gelden; 14

Er moeten mogelijkheden worden geschapen tot het verkrijgen van elkaar wederzijds controlerende verantwoordingsverslagen van personen met nietidentieke en waar mogelijk tegengestelde belangen; Geen der bij beschikken, uitvoeren of bewaren betrokken functionarissen mogen deelnemen aan enig deel van de registratie van dat kritisch is ten aanzien van de op hun activiteit uit te oefenen controle; Ten aanzien van die onderdelen van de administratieve organisatie die praktisch mede een bewaringskarakter hebben, moet de controle in handen worden gelegd van een ander dan degene door wie dat onderdeel van de administratie wordt bijgehouden. Deze globale eisen met betrekking tot functiescheiding zijn voor dit onderzoek naar functiescheiding in het inkoopproces nader te concretiseren. Hier zijn voor de jaarrekeningcontrole specifiek de onderstaande (chronologische) functiescheidingen van belang. In figuur 2 ziet u nogmaals het inkoopproces in een schema. Hierin zijn de gewenste functiescheidingen te herkennen aan de vakken die overeenkomen in kleur. Deze kleur wordt in de onderstaande lijst ook vermeld bij de omschrijving van de te scheiden functies. Een medewerker die mutaties in stamgegevens van crediteuren doorvoert, verricht geen transacties in het inkoopproces en omgekeerd (zwart); Een medewerker die een bestelling plaatst, is niet de medewerker die goedkeuring verleent op die bestelling en omgekeerd (geel); Een medewerker die een bestelling plaatst, is niet de medewerker die de goederen in ontvangst neemt en andersom (oranje); Een medewerker die een factuur ontvangt en registreert, is niet de medewerker die de controle op de factuur uitvoert en andersom (rood); Een medewerker die een factuur registreert/controleert, is niet de medewerker die de factuur betaalbaar stelt en andersom (paars). Functiescheiding heeft een minimale omvang van de organisatie nodig om effectief te kunnen zijn. Een eenmanszaak zal geen functiescheiding kennen omdat het simpelweg niet mogelijk is om een functie bij een tweede persoon te beleggen. Bij een organisatie van meer dan twee personen kan het evengoed zo zijn dat meerdere functies bij een persoon belegd zijn. Zolang er in het hele proces in ieder geval minimaal één kritieke stap is die door een andere functionaris wordt uitgevoerd, is dit voldoende om (beperkte) functiescheiding te waarborgen. In dit geval is het niet mogelijk dat één medewerker het volledige proces afhandelt. Het kan voorkomen dat er geen tweede functionaris beschikbaar is om een kritieke stap in het inkoopproces uit te voeren. In dat geval kan er nog steeds sprake zijn van een adequate interne controle als er compenserende maatregelen zijn genomen om de functionaris met te veel vrijheden alsnog achteraf te controleren. Dit kan bijvoorbeeld door een aantal transacties te controleren per periode die door de functionaris alleen zijn uitgevoerd. 15

Inkoopproces Leverancier Inkoop Magazijn Voorraadadm. Factuurcontrole Crediteurenadm. Grootboek Bestelsignaallijst Bestelsignaallijst Controle bestelling Invoer stam gegevens crediteuren Bestelling Bestelling Bestelling Bestelling Bestelling Boeken op rekening te ontv fact Goederen Goederen Voorraad boeking Controle met bestelling Magazijn ontvangstbon Magazijn ontvangstbon Factuur Magazijn ontvangstbon Magazijn ontvangstbon Voorraad boeking Boeking crediteur Factuur Factuur Betalen factuur Controle factuur Boeken op grbkrekg crediteuren Figuur 2 - Inkoopproces inclusief functiescheiding en three-way-match Tijdens dit onderzoek zullen wij voor zover mogelijk met de beschikbare data alle functiescheidingen betrekken. Dit is afhankelijk van de informatie die beschikbaar is in de applicatie. In de volgende paragraaf zullen wij aangeven welke informatie uit de financiële administratie benodigd is om de functiescheidingen te kunnen testen. 2.4 Minimaal benodigde informatie In de vorige paragraaf hebben we de relevante functiescheidingen gedefinieerd. Nu is het noodzakelijk om de informatiebehoefte te definiëren die het mogelijk maakt om de functievermenging ook geautomatiseerd gegevensgericht te kunnen testen. Hieronder beschrijven we eerst op welke wijze vastlegging van informatie met betrekking tot functiescheiding in ERP-systemen plaatsvindt. Nu duidelijk is waar de informatie gevonden kan worden, is het zaak te bepalen welke informatie hier precies wordt vastgelegd. Dit wordt behandeld in de paragraaf 2.4.2. Hier is in generieke termen te vinden welke informatie benodigd is. Vervolgens wordt dit specifiek gemaakt voor het testen op functiescheiding in het inkoopproces. 2.4.1 Vastlegging van data in ERP-applicaties Informatie in ERP-applicaties ligt typisch vast in twee verschillende vormen. De eerste vorm is in de daadwerkelijke transactiedata. Dit ligt meestal vast in de database van de ERPapplicatie. Deze informatie heeft direct met de verrichte transactie te maken. Bijvoorbeeld, bij het aanmaken van een bestelling wordt de leverancier, het bedrag, de hoeveelheid 16

bestelde goederen, een omschrijving van de goederen, etc. vastgelegd in de tabel met bestellingen. Dan is er een tweede vastlegging mogelijk en dat is de vastlegging van gebeurtenissen in de vorm van een log. Dit log kan in de database van de applicatie vastgelegd worden maar kan ook naar een bestand, bijvoorbeeld een tekstbestand, zijn weggeschreven. Logbestanden bevatten meta informatie over de transactiedata die in de ERP-applicatie zit. Soms wordt bijvoorbeeld de gebruiker die de transactie uitvoert niet bij de bestelling vastgelegd. Dit wordt dan wel gelogd naar een logbestand of logtabel. Mogelijkheden tot vastlegging in logbestanden in een applicatie kunnen typisch aan of uitgezet worden in verband met performance overwegingen van de applicatie. Beide bronnen kunnen aangesproken worden in het geautomatiseerde gegevensgerichte testen door middel van data analyse. De combinatie van transactiedata en logbestanden heet de audit trail. Voor dit onderzoek dient het audit trail genoeg informatie te bevatten om te geautomatiseerd gegevensgericht te kunnen testen op functievermenging. 2.4.2 Rijkdom van de informatie Ook de rijkdom van de informatie, de hoeveelheid beschikbare informatie elementen bij een gebeurtenis en de relevantie daarvan, is van belang voor dit onderzoek. Indien bepaalde informatie van of over een transactie gewoonweg niet wordt vastgelegd op het moment van de gebeurtenis, zal deze dus later ook niet beschikbaar zijn in de audit trail voor een analyse. Onderzoek naar de minimaal benodigde informatie in de audit trail is gedaan door van Dongen en van der Aalst (van der Aalst, de Beer, & van Dongen, 2005) als onderdeel van de databehoeften voor proces mining 1. Zij definieerden de volgende informatiebehoeften om een analyse te kunnen doen: Tijdstip en/of datum van een gebeurtenis Elke gebeurtenis in een proces moet vastgelegd worden in een chronologische volgorde. Een periode is geen geldige indicatie voor een gebeurtenis. Voor een periode geldt dat deze geïdentificeerd kan worden door zowel het beginpunt als het eindpunt van de periode. Dit zijn twee aparte gebeurtenissen die apart vastgelegd kunnen worden. Elke vastlegging dient over een unieke activiteit te gaan Voor elke vastlegging moet gelden dat deze over slechts een enkele activiteit gaat. De activiteit in kwestie moet daarnaast ook uniek identificeerbaar zijn. 1 Proces mining is een techniek waarbij uit logging data het gevolgde proces en alle stappen daarin zichtbaar worden gemaakt dan wel worden getest of conformiteit met een standaard model. 17

Elke vastlegging dient te beschrijven wat er plaats vond ten aanzien van de bijbehorende activiteit Bijvoorbeeld, de activiteit begon of was juist afgerond. Elke vastlegging in de audit trail dient te refereren naar een unieke instantie van het proces: een casus. Bijvoorbeeld de casus van precies één hele aankoop. Elke procesinstantie behoort toe tot precies een specifiek proces. Een casus mag dus niet zowel een inkoop- als een verkoopproces zijn. In de volgende subparagraaf worden deze behoeften vertaald naar concrete niveaus en velden van de benodigde data. 2.4.3 Benodigde informatie voor testen functiescheiding in het inkoopproces Om de functiescheiding geautomatiseerd gegevensgericht te kunnen testen is vastlegging van de procesinformatie in de ERP-applicatie nodig. Hierbij gaat enerzijds om vastlegging van de kwantitatieve en kwalitatieve kenmerken van de basisdocumenten in het proces, de bestelling, de magazijnontvangstbon en de factuur. Anderzijds gaat het om de vastlegging van de gebruikers die inhoudelijke wijzigingen hebben doorgevoerd, controlewerkzaamheden hebben uitgevoerd of goedkeuring hebben gegeven. Dit is nodig om vast te stellen of de gebruikers die gemoeid zijn bij deze activiteiten verschillend zijn. Om de functiescheiding in het inkoopproces geautomatiseerd gegevensgericht te kunnen testen hebben we om te beginnen gegevens nodig van de basisdocumenten/objecten die betrokken zijn in het inkoopproces. Deze documenten betreffen de bestelling, de magazijnontvangstbon en de factuur, zoals ook terug te vinden in de weergave van het inkoopproces in figuur 1. Per document zijn op het niveau van de bestelling/magazijnontvangstbon/factuur de volgende basisgegevens nodig om de gegevensgerichte controle volledig te kunnen uitvoeren: Bestelling o Ordernummer (unieke identificatie) o Besteldatum o Bestelbedrag o Bestelregels (inhoud van de bestelling) o Leveranciersnummer Magazijnontvangstbon o Ordernummer (unieke identificatie) o Ontvangstdatum o Bedrag waarvoor goederen of diensten zijn ontvangen o Goederenregels (kenmerken van de ontvangen goederen) 18

o Leveranciersnummer Factuur o Factuurnummer/Ordernummer (unieke identificatie) o Factuurbedrag o Factuurregels (omschrijving van hetgeen wordt gefactureerd) o Crediteurnummer Met betrekking tot deze basisdocumenten is het vervolgens noodzakelijk een aantal handelingen te registreren. Essentieel hierbij is dat wordt geregistreerd wat de handeling in heeft gehouden, wie de handeling heeft verricht en op welke datum en tijd de handeling is verricht. Bestelling o Medewerker (incl. datum en tijd waarop) die de bestelling heeft geplaatst o Medewerker (incl. datum en tijd waarop) die de bestelling heeft gecontroleerd Magazijnontvangstbon o Medewerker (incl. datum en tijd waarop) die de goederen in ontvangst heeft genomen Factuur o Medewerker (incl. datum en tijd waarop) die de factuur heeft geregistreerd o Medewerker (incl. datum en tijd waarop) die de factuur heeft gecontroleerd o Medewerker (incl. datum en tijd waarop) die de crediteurboeking heeft uitgevoerd o Medewerker (incl. datum en tijd waarop) die de factuur heeft geboekt Naast deze transacties die verricht worden in het inkoopproces, is er nog de informatie die nodig is om functiescheiding tussen mutaties in crediteurenstamgegevens en transacties in het inkoopproces te kunnen vaststellen. Hiervoor is aanvullende de volgende informatie nodig: o Medewerker (incl. datum en tijd waarop) die crediteurenstamgegevens heeft gewijzigd o Waarde voorafgaand aan de wijziging o Waarde na de wijziging Mutaties in stamgegevens worden typisch vastgelegd in de logbestanden in de audit trail. De handelingen op bestelling, magazijnontvangstbon en factuur worden in de meeste gevallen vastgelegd in transactie tabellen en daarnaast mogelijk nog in logbestanden. 19

2.5 Conclusie In dit hoofdstuk hebben we een model neer gezet van een standaard inkoopproces (zie paragraaf 2.2) dat we verder zullen aanhouden in de rest van deze scriptie. Het model van het inkoopproces met de te onderscheiden stappen zal dienen als basis voor de analyse van functiescheiding bij de praktijkcasussen. Daarnaast is het begrip functiescheiding geïntroduceerd. We hebben functiescheiding beschreven als: Functiescheiding is een middel om het risico dat waarde uit de organisatie wordt onttrokken door een enkele functionaris wordt voorkomen door de verschillende taken die dit mogelijk maken te spreiden over meerdere personen. Het restrisico dat overblijft, is dat er samenspanning optreedt tussen functionarissen in de organisatie. Dit risico is niet te voorkomen door middel van functiescheidingen en zal verder niet in deze scriptie worden onderzocht. Vervolgens hebben we de volgende algemene functiescheidingen onderkend in het standaard inkoopproces: Mutaties op stamgegevens crediteuren scheiden van transacties in het inkoopproces Goederen bestellen scheiden van de goedkeuring op die bestelling Goederen bestellen scheiden van de goederenontvangst De factuurregistratie scheiden van de controle op de factuur De factuurregistratie en controle op de factuur scheiden van de betaling van de factuur Op basis van deze vijf functiescheidingen hebben we onderzocht welke informatie benodigd is om geautomatiseerd gegevensgericht functiescheiding te testen in de audit trail en hoe informatie wordt opgeslagen in ERP-applicaties. De minimale vastleggingen, in het algemeen, moeten zijn: Tijdstip en/of datum van een gebeurtenis Elke vastlegging dient over een unieke activiteit te gaan Elke vastlegging dient te beschrijven wat er plaats vond ten aanzien van de bijbehorende activiteit Elke vastlegging in de audit trail dient te refereren naar een unieke instantie van het proces: een casus. Elke procesinstantie behoort toe tot precies een specifiek proces. De rijkdom van de beschikbare informatie zal bepalen of alle of slechts een deel van de functiescheidingen geautomatiseerd getest kunnen worden. Alle benodigde elementen voor de vijf standaard functiescheidingen zijn opgesomd in paragraaf 2.4.3. Op basis van deze lijst kan later bepaald worden welke functiescheidingen getest kunnen worden gegeven de data aanwezig in de ERP-applicatie. 20

3 Theoretische studie: randvoorwaarden voor geautomatiseerde gegevensgerichte analyse 3.1 Inleiding Voor elke audit zijn randvoorwaarden nodig zonder welke een audit niet uitgevoerd kan worden. Centraal in dit hoofdstuk staat dan ook de vraag: Welke randvoorwaarden moeten vervuld zijn in de organisatie en in de applicaties om op opgetreden functievermenging te testen? In paragraaf 2.4.3 hebben we gezien welke informatie elementen nodig zijn voor de analyse van functiescheidingen. Een belangrijke vraag is of de ERP-applicatie de bron was van deze informatie of slechts een registratie middel. Daarnaast moet de integriteit van de geregistreerde data gewaarborgd zijn. Dit zijn onderwerpen die in dit hoofdstuk aan het bod komen in de volgende onderzoeksvragen: Wat is primaire vastlegging en waar is dit belangrijk in het analyse proces? Welke organisatorische maatregelen zijn er noodzakelijk om de integriteit van de analyse data te waarborgen en hoe worden deze nu geïmplementeerd? In paragraaf 3.2 bespreken we het onderwerk van primaire vastleggingen en secundaire vastleggingen. In paragraaf 3.3 gaan we in op de organisatorische maatregelen aan welke voldaan moeten worden om een geautomatiseerde gegevensgerichte analyse met volledige betrouwbaarheid te kunnen uitvoeren. Ook komen hier de logische toegangsbeveiliging maatregelen die geautomatiseerde gegevensgerichte analyse ondersteunen aan bod. Tot slot, in paragraaf 3.4, eindigen we dit hoofdstuk met een conclusie over de onderzoeksvragen. 3.2 Primaire vastleggingen in de ERP-applicatie Zoals aangegeven in hoofdstuk 2.4.3 zal bepaalde informatie digitaal aanwezig moeten zijn om geautomatiseerd gegevensgericht functiescheiding te kunnen testen. Deze informatie zal vastgelegd moeten zijn in de audit trail van de te controleren ERP-applicatie. We maken onderscheid tussen de primaire en de secundaire vastlegging van data. Bij de primaire vastlegging hebben we het over de vastlegging die als eerste bekend is bij het bedrijf. Bij een secundaire vastlegging gaat het om een vastlegging die is afgeleid van de primaire vastlegging of van een vastlegging die pas veel later plaats vind. Dit illustreren we hieronder met een voorbeeld. Transactie data, zoals ordernummers en prijzen en bestelde hoeveelheden, zijn vaak wel aanwezig in de ERP-applicatie van een bedrijf. Het gaat hier echter vaak om de secundaire vastlegging van data. Als voorbeeld kunnen we de factuur nemen. Het komt nog vaak voor 21

dat een factuur op papier wordt ontvangen en vervolgens de relevante informatie hiervan wordt overgenomen in de ERP-applicatie. In dit geval is de primaire vastlegging de factuur (hier staat de daadwerkelijke informatie op die als eerst het bedrijf binnenkomt) en is het invoeren in de ERP-applicatie de secundaire vastlegging (er is namelijk nog een primaire bron beschikbaar waar deze informatie van afgeleid is). De trend in de markt is dat de primaire vastlegging steeds vaker digitaal wordt gedaan en dat het verschil tussen de primaire en secundaire vastlegging verdwijnt. Denk hierbij aan elektronische facturen (ANP, 2009) die gelijk digitaal worden opgeslagen in de ERPapplicatie en waarvan de informatie gelijk geautomatiseerd wordt opgeslagen. Daarnaast kunnen veel magazijnen goederen ontvangen en de vastlegging doen door middel van een barcode scan bij ontvangst van de goederen. Het kan zijn dat delen van het proces in andere applicaties worden vastgelegd of zelfs buiten de digitale omgeving om. Een veelvoorkomend voorbeeld hiervan is de goedkeuring van orders. Regelmatig wordt hiervoor een aparte work flow ingeregeld in een externe applicatie of buiten de applicatie om op papier. In dit geval is het niet voldoende om alleen de data uit de ERP-applicatie te gebruiken. Er zal dan additionele data uit, in dit voorbeeld het work flow systeem, aan de data van de ERP-applicatie toegevoegd moeten worden. Alleen op die manier kan de databehoefte zoals beschreven in 2.4.3 volledig worden vervuld. In de volgende paragraaf zullen we aandacht besteden aan de organisatorische randvoorwaarden die vervuld dienen te zijn voor het geautomatiseerd gegevensgericht controleren van functiescheidingen. 3.3 Organisatorische inrichting Bij het inrichten van een organisatie dient, in het geval van geautomatiseerd gegevensgericht testen, naast de gebruikelijke inrichting zoals beschreven in (Starreveld, van Leeuwen, & van Nimwegen, 2002) en (Arens & Loebbecke, 1980), rekening te worden gehouden met het bewaren en beschikken over de informatie in de audit trail van de ERPapplicatie. Dit is een verbijzondering van het standaardgeval waarbij de audit trail niet altijd in scope is. Omdat de audit trail het uitgangspunt is bij het geautomatiseerd gegevensgericht testen van functiescheidingen moet deze niet manipuleerbaar zijn voor de te controleren gebruikers. Daarom dienen de volgende zaken organisatorisch gewaarborgd te zijn: 1. Het bewaren van de audit trail gegevens mag niet in handen zijn van een functionaris wiens acties geregistreerd zijn in het audit trail. 2. Het configureren van de audit trail instellingen die bepalen wat in het audit trail wordt vastgelegd, mag niet toegankelijk zijn voor functionarissen wiens acties in de audit trail worden opgeslagen. 22

3. De geautomatiseerde gegevensgerichte testwerkzaamheden en de configuratie daarvan mogen niet worden uitgevoerd door een functionaris wiens acties geregistreerd zijn in het audit trail. In een kleinere organisatie zal het typisch voorkomen dat meerdere functies in de handen liggen van één persoon. Dit geeft geen probleem qua functiescheiding zolang de bovenstaande scheidingen maar gewaarborgd blijven. Er zijn verschillende soorten (IT-)beheersingsmaatregelen die invloed hebben op het afdwingen van de bovenstaande functiescheidingen. Tevens zijn er maatregelen die de kwaliteit en de betrouwbaarheid van de geautomatiseerde gegevensgerichte analyse kunnen waarborgen. Beide categorieën van maatregelen komen hieronder aan de orde. 3.3.1 Implementatie van functiescheidingen in logische toegangsbeveiliging Naast de organisatorische opzet van functiescheidingen is ook de implementatie hiervan in informatiesystemen van belang. We zullen ons nu eerst richten op de maatregelen op het gebied van logische toegangsbeveiliging die de implementatie van de organisatiestructuur met functiescheidingen mogelijk maakt. Typisch zullen bedrijven de toegang tot informatiesystemen beperken om op deze manier functiescheiding en digitale autorisaties te realiseren. Logische toegangsbeveiligingstechnieken en tools worden ingezet om deze beperkingen te definiëren. Er zijn een aantal factoren belangrijk bij de implementatie van logische toegangsbeveiliging. Deze zetten we hieronder uiteen. Accountability Het meest belangrijke aspect voor geautomatiseerd gegevensgericht testen is accountability. Accountability (ISACA, 2005) betekent dat voor elk gebruikersaccount op een applicatie geldt dat er te allen tijde bekend is wie er gebruikt maakt van het account. Op deze manier kan deze persoon verantwoordelijk worden gesteld voor de activiteiten die zijn verricht met gebruikmaking van het account. Deze voorwaarde is nodig omdat het geautomatiseerd gegevensgericht testen van functiescheidingen alleen mogelijk is als men op basis van de gebruikersaccount kan zien welke persoon welke actie gedaan heeft. Het gebruikersaccount geeft de sleutel naar de identiteit van de uitvoerende functionaris maar alleen als het account niet gedeeld wordt door meerdere mensen. Gebruikersidentificatie op basis van gebruikersaccount Het is noodzakelijk om alle accounts van gebruikers in kaart te brengen en te koppelen aan de personen die er gebruik van maken. Het kan namelijk zo zijn dat een gebruiker meerdere accounts heeft op een ERP-applicatie. Je zou dan twee accounts ten onrechte als twee aparte personen in het proces kunnen aanmerken en daardoor een functiescheidingsconflict missen. Het kan ook voorkomen dat gebruikers meerdere accounts hebben die ook verdeeld zijn over meerdere systemen die gebruikt worden voor delen van het proces. Ook hierdoor kan een functievermenging wellicht onopgemerkt blijven. Voor elke applicatie in scope van de 23

geautomatiseerde gegevensgerichte analyse geldt dus dat deze koppeling bekend moet zijn om de resultaten te kunnen interpreteren. De kennis van deze koppeling moet dus ook in de organisatie beschikbaar zijn. Nu we weten wat er qua organisatie ingericht moet zijn, kunnen we kijken hoe de logische toegangsbeveiliging op de audit trail te realiseren is. 3.3.2 Logische beveiliging van de audit trail In deze paragraaf zullen we verder ingaan op welke gegevens beschermd dienen te worden met logische toegangsbeveiliging om geautomatiseerde gegevensgerichte analyse hiervan mogelijk te maken. Zoals in hoofdstuk 2.4.1 beschreven is, bestaat een audit trail uit 2 soorten data: transactiedata en logbestanden. Voor beide soorten gegevens geldt dat deze adequaat beschermd dienen te worden met behulp van logische toegangsbeveiliging. Ten eerste dient de audit trail beschermd te worden tegen aanpassingen en verwijderingen door onbevoegden personen en door te controleren personen (zie 3.3.1). Hiervoor kunnen technieken als access control lists, database management systemen en applicatiebeveiliging gebruikt worden. Hierbij geldt dat het beheer niet mag worden uitgevoerd door een persoon die zelf in de logging gecontroleerd wordt. Ten tweede is het belangrijk om te kijken naar de beschikbaarheid van de registratiemedia voor het audit trail. Indien een kwaadwillend persoon er in slaagt om de opslag van de gegevens te verhinderen, bereikt deze in feite hetzelfde als wanneer de data verwijderd zou worden. Tot slot nog een kanttekening bij de beveiliging van de gegevens in de audit trail. Omdat de audit trail grote hoeveelheden data kan bevatten, wordt deze soms niet (lang) op het bronsysteem bewaard vanwege opslaggebrek en/of prestatievermindering van de systemen. Vaak worden er aparte catalogi opgezet met een kopie van de data. Indien er sprake is van transport van de data, hetzij via een netwerk of via een vast medium, dienen er controles te zijn over de juistheid, de volledigheid en de tijdigheid van de overdracht (zie (Senft & Gallegos, 2008)). 3.4 Conclusie De onderzoeksvraag voor dit hoofdstuk was welke randvoorwaarden belangrijk zijn voor een geautomatiseerde gegevensgerichte functiescheidingsanalyse. We onderkennen de volgende randvoorwaarden: Primaire vastleggingen Het is belangrijk dat alle vastleggingen in de ERP-applicatie gebeuren. Ofwel primair, de ERP-applicatie is de bron van de vastlegging, ofwel secundair wanneer de ERPapplicatie slechts dient ter registratie van een primaire vastlegging. 24