Embedded testing binnen IT General Controls

Transcriptie

1 Embedded testing binnen IT General Controls Goed alternatief of waardeloze optie? Amsterdam, 15 april 2008 Auteurs: Hans Bootsma ( ) Martijn Knuiman ( ) EDP Audit Opleiding Vrije Universiteit Amsterdam Begeleider Universiteit: Tjakko de Boer Begeleider Deloitte: Jacques Herman

2 Inhoudsopgave 1. Inleiding Aanleiding Onderzoeksvraag Plan van aanpak Afbakening van het onderzoek Indeling van de scriptie 5 2. Embedded testing versus de traditionele manier van testen Traditionele wijze van testen van interne beheersmaatregelen Interne beheersmaatregelen oftewel Internal Controls Het testen van beheersmaatregelen Traditionele wijze van het testen van beheersmaatregelen Embedded testing Het embedded testing concept; wat is het? Embedded testing in relatie tot monitoring controls Voor- en nadelen van embedded testing Toepassing van embedded testing Business as usual Resume Het testen van IT General Controls Wat zijn IT General Controls? ITGC onderdelen ITGC en embedded testing Embedded testing binnen ITGC in de praktijk Embedded testing per ITGC Embedded testing ondanks noodzaak voor specialistische kennis? Conclusie en reflectie Conclusie Beantwoording van de onderzoeksvraag Reflectie Literatuur 29 Pagina 2 van 29

3 1. Inleiding 1.1. Aanleiding Interne beheersmaatregelen: het is een begrip dat de afgelopen jaren een prominente plaats heeft ingenomen in de dagelijkse bezigheden van veel bedrijven, maar dan vooral bij beursgenoteerde bedrijven. Regelgevingen en richtlijnen als de code Tabaksblat 1 en Sarbanes Oxley 2 (SOX) hebben er voor gezorgd dat organisaties uitgebreide controleraamwerken hebben geïmplementeerd of de bestaande raamwerken hebben bijgewerkt. En dan gaat het niet alleen om het ontwerpen van een dergelijk raamwerk maar ook om het implementeren ervan, embedding van de interne beheersmaatregelen in de organisatie, het uitvoeren van de beheersmaatregelen en tenslotte het testen van de uitgevoerde beheersmaatregelen. Dit testwerk is veelal een uitgebreid proces waarbij de benodigde activiteiten vaak door mensen van buiten de bedrijfsprocessen worden uitgevoerd. Voorbeelden hiervan zijn bijvoorbeeld Internal Control (IC) en Internal Audit (IAD) afdelingen. Tenslotte is er dan nog de externe accountant die, vaak in het kader van de jaarrekeningcontrole en in het geval van de SOX-plichtigen de 404 verklaring, een onafhankelijk oordeel over het ontwerp, bestaan en werking van de beheersmaatregelen dient te krijgen. Kortom, de beheersmaatregelen die worden uitgevoerd worden daarna veelvuldig getest. De uitvoering van de beheersmaatregelen en het testen daarvan kost uiteraard veel energie, tijd en daarmee geld, veel geld. Uit onderzoek uitgevoerd in 2005 bleek bijvoorbeeld dat de kosten die gemaakt werden in het kader van SOX 50% hoger waren dan initieel verwacht 3. Het mag daarom geen verrassing zijn dat vrijwel ieder bedrijf zoekt naar mogelijkheden om het aantal beheersmaatregelen te verminderen (het zogenaamde rationaliseren van beheersmaatregelen), raamwerken in elkaar te schuiven om te kijken naar overlap of te kijken naar de mogelijkheden voor efficiëntieverhoging door de inzet van geautomatiseerde tools. Aan deze zaken zal in deze scriptie echter geen aandacht worden besteed. Er is namelijk nog een manier om een efficiëntieslag te maken in de totale inzet die benodigd is voor het uitvoeren en testen van beheersmaatregelen, namelijk embedded testing. In het kort komt het er op neer dat de controle uitvoering wordt gecombineerd met het testen van de beheersmaatregelen. Het uiteindelijke doel van de implementatie van het embedded testing concept is ten eerste het omlaag brengen van de compliancekosten; compliancekosten zijn alle kosten (intern en extern) die gemaakt worden voor het ontwerpen, implementeren, testen en in stand houden van de controleraamwerken die de compliance met relevante wet- en regelgevingen moeten garanderen. Embedded testing zou 1 Formele naam is de Nederlandse corporate governance code, beginselen van deugdelijk ondernemingsbestuur en best practice bepalingen, uitgebracht door de commissie corporate governance, 9 december 2003 maar staat vooral bekend als de Code Tabaksblat, genoemd naar de voorzitter van de commissie. 2 De Sarbanes-Oxley (SOX) act is in de Verenigde Staten ingevoerd na de faillissementen van Enron en WorldCom. Secties 302 en 404 stellen specifiek dat bedrijven die aan de beurs in de VS genoteerd staan een stelsel van interne beheersmaatregelen op te stellen, te implementeren en te evalueren in het kader van de financiële verslaglegging en operationele integriteit. 3 Gegevens komen uit de FEI Survey on Sarbanes-Oxley Section 404 Implementation ; October 2005 Pagina 3 van 29

4 deze compliancekosten met 50% kunnen verminderen 4. In de tweede plaats moet embedded testing ook de control awareness binnen de organisatie vergroten doordat degenen die normaliter binnen het proces werkzaam zijn, nu ook formele beheersmaatregelen binnen deze processen uitvoeren. In de praktijk is het concept met succes toegepast binnen verschillende bedrijfsprocessen van een grote retailorganisatie. Echter de vraag is of embedded testing ook binnen de IT General Controls (ITGC) toegepast kan worden Onderzoeksvraag Op basis van het bovenstaande komen we dan ook tot de volgende onderzoeksvraag: Wat is de potentie van embedded testing binnen de IT General Controls van een organisatie? Om hier een antwoord op te kunnen geven, zullen we de volgende deelvragen beantwoorden: Wat is embedded testing en waarin verschilt het van de traditionele manier van het testen van beheersmaatregelen? Wat zijn de randvoorwaarden waaraan moet worden voldaan om embedded testing toe te kunnen passen? Binnen welke gebieden van ITGC kan embedded testing in de praktijk worden toegepast? Dit onderzoek spitst zich toe op het beantwoorden van de drie deelvragen teneinde de onderzoeksvraag te kunnen beantwoorden. We gaan niet in op de vraag wat de gevolgen zijn van het implementeren van embedded testing voor de compliancekosten, dit is een onderzoeksvraag op zich. Uiteraard zal in het stuk een aantal van de gevolgen worden genoemd maar is het niet de intentie om een compleet beeld te schetsen van alle gevolgen voor deze compliancekosten Plan van aanpak De scriptie is opgesteld op basis van ervaringen die we in de afgelopen jaren hebben opgebouwd op het gebied van het testen van beheersmaatregelen. Het onderwerp is gekozen aangezien wij in de praktijk specifiek te maken hebben gehad met de implementatie van het embedded testing principe bij een multinational in Nederland. Over het onderwerp is een artikel gepubliceerd door degene die embedded testing heeft geïmplementeerd. Dit artikel is uiteraard als input gebruikt voor onze scriptie. Wij hebben getracht de praktische toepassing van embedded testing binnen ITGC te beschrijven op basis van de opgedane ervaringen rondom de implementatie van embedded testing en daaraan gekoppeld de ervaring opgedaan rondom het testen van ITGC in het algemeen. Het is niet onze intentie om embedded testing theoretisch te onderbouwen. Dit laatste voegt naar onze mening namelijk weinig waarde toe, het gaat vooral om de praktische implementatie van het concept. 4 Gegevens over mogelijke besparingen door gebruikt te maken van embedded testing komen uit: Embedded testing: a cure for Sox Blues, C. Klumper & S. Geuzenbroek, februari 2007 Pagina 4 van 29

5 Op basis van onze analyse van de mogelijkheden voor embedded testing binnen de ITGC, hebben we een interview gehouden met de IT director die verantwoordelijk is voor embedded testing binnen de genoemde multinational. De feedback van dit gesprek is verwerkt in het document Afbakening van het onderzoek Aangezien het domein van ITGC breed is, wordt de scriptie als volgt afgebakend: De scope van de scriptie bestaat uit de toepassing van embedded testing binnen de ITGC en zal zich alleen richten op deze generieke beheersmaatregelen. De application controls zullen buiten beschouwing gelaten worden. Embedded testing wordt behandeld met als uitgangspunt dat het concept wordt geïmplementeerd binnen een organisatie die dient te voldoen aan de SOX-wetgeving. Hiervoor is gekozen aangezien het onderwerp zich uitermate goed leent voor een situatie waarbij de betreffende organisatie zelf een verklaring dient af te leggen over de effectiviteit van de interne controlemaatregelen, in het geval van SOX de beheersmaatregelen in het kader van de financiële verslaglegging van de organisatie, binnen de organisatie Indeling van de scriptie In de volgende hoofdstukken zullen de deelvragen apart worden uitgewerkt. In hoofdstuk twee worden de verschillen tussen de traditionele manier van testen en embedded testing behandeld. Dit zal resulteren in een set van randvoorwaarden waaraan voldaan moet worden wil embedded testing met succes worden toegepast. In hoofdstuk drie zal specifiek worden ingegaan de ITGC en de relatie tussen de ITGC en embedded testing. Dit hoofdstuk zal de basis opleveren van de haalbaarheidsanalyse van hoofdstuk vier. De toepassing van embedded testing in de praktijk wordt vervolgens in hoofdstuk vier behandeld. Op basis van de karakteristieken van embedded testing en de randvoorwaarden wordt gekeken welke maatregelen het meest geschikt zijn voor het gebruik van embedded testing. Uiteindelijk zal in hoofdstuk vijf een antwoord worden gegeven op de gestelde onderzoeksvraag en zullen we reflecteren op de uitgevoerde werkzaamheden van dit onderzoek. Pagina 5 van 29

6 2. Embedded testing versus de traditionele manier van testen De titel van dit hoofdstuk impliceert dat er een verschil is tussen de traditionele manier van het testen van beheersmaatregelen en de manier die embedded testing wordt genoemd. In dit hoofdstuk wordt ingegaan op de definities van beide concepten, wat wij eronder verstaan. Tenslotte wordt in de derde paragraaf het verschil tussen beide concepten samengevat Traditionele wijze van testen van interne beheersmaatregelen Interne beheersmaatregelen oftewel Internal Controls Interne beheersmaatregelen zijn niet een nieuwigheid van de laatste jaren, maar staan sinds de invoering van SOX erg in de belangstelling. Wetgeving als deze heeft er voor gezorgd dat bedrijven meer aandacht zijn gaan besteden aan het raamwerk van interne beheersmaatregelen (ook internal controls of interne controles genoemd). Nu is het uiteraard niet zo dat de invoering van de interne beheersmaatregelen pas iets van de laatste jaren is. Al sinds jaar en dag implementeren organisaties controle punten binnen de bedrijfsprocessen. Deze beheersmaatregelen werden vervolgens door bijvoorbeeld de IAD of de externe accountant getest, maar management testte deze beheersmaatregelen zelden zelf en legde hier ook zelden formele verantwoordelijkheid over af. De komst van SOX heeft dit veranderd. Management moest opeens een formele verklaring afgeven over het ontwerp en de werking van de interne beheersmaatregelen binnen de organisatie. Om dit te kunnen doen, werd veelal het bestaande controleraamwerk bijgewerkt of een compleet nieuw raamwerk gebouwd die meestal gebaseerd was op het Enterprise Risk Management Integrated Framework van de Committee of Sponsoring Organizations uit de Verenigde Staten, ook wel het COSO model genoemd 5. De beheersmaatregelen die in een dergelijk raamwerk zijn opgenomen worden over het algemeen key controls genoemd, een term die niet direct gedestilleerd is uit een bepaalde regel of wet aangezien dit nergens specifiek wordt genoemd. Zo kennen bijvoorbeeld de regelgevingen van de SEC 6 en de PCAOB 7 deze term niet. Voor dit onderzoek vormen de key controls van organisaties het uitgangspunt. Indien over beheersmaatregelen, controles, controls of interne controles gesproken wordt, dan wordt hier impliciet key control mee bedoeld. De termen worden door elkaar gebruikt. Aangezien dit onderzoek zich beperkt tot embedded testing in relatie tot de SOXcertificering, zijn de beheersmaatregelen primair gericht op de internal controls over financial reporting, kortom de beheersmaatregelen gericht op adequate financiële verslaglegging van de organisatie. Aangezien de financiële verslaglegging tegenwoordig per definitie steunt op het gebruik van financiële applicaties en ondersteunende applicaties, vallen ook de ITGC binnen de meeste SOX gerelateerde controleraamwerken. In ieder geval gaan we in deze scriptie er van uit dat de ITGC onderdeel uitmaakt van het raamwerk van een organisatie die moet voldoen aan de SOX-wetgeving. 5 Enterprise Risk Management Integrated Framework, Executive summary framework, published by the committee of sponsoring organizations of the Treadway Commission, September SEC staat voor U.S. Security and Exchange Commission. De SEC heeft op 23 mei 2007 de aangepaste richtlijnen goedgekeurd op het gebied van sectie 404 van de Sarbanes Oxley act. 7 PCAOB staat voor Public Accounting Oversight Board en is verantwoordelijk voor de Auditing Standards nr. 2 en diens opvolger nr. 5. Beide auditing standards hebben betrekking op an audit of Internal Control Over Financial Reporting Performed in Conjunction or integrated with An Audit of Financial Statements Pagina 6 van 29

7 Het testen van beheersmaatregelen Voordat we ingaan op het verschil tussen het testen van interne beheersmaatregelen op de traditionele manier en die waarbij gebruik wordt gemaakt van embedded testing, is het van belang om kort stil te staan bij de vraag wat we nu onder testen verstaan en waaraan de documentatie van een test dient te voldoen. Het testen zoals bedoeld in deze scriptie is niets meer dan het beoordelen van een situatie in de praktijk door deze te toetsen aan de gehanteerde norm. Voor een organisatie is deze norm normaal gesproken het ontwikkelde controleraamwerk. Het raamwerk van de auditor is normaal gesproken afgeleid van de betreffende regelgeving in combinatie met best practices als COSO, Cobit etc. Documentatie van testresultaten Om vast te kunnen stellen dat een test juist en volledig is uitgevoerd, dient deze goed gedocumenteerd te worden. Dit maakt het mogelijk dat lijnmanagers uitgevoerde testen kunnen beoordelen en tevens kunnen andere partijen hetzelfde doen (bijvoorbeeld IAD of de externe accountant), iets wat specifiek van belang is indien er door een derde partij wordt gesteund op het werk van de testende partij. De elementen waaraan de documentatie van een test moet voldoen zullen we kort beschrijven, zonder te trachten een volledig raamwerk hiervoor neer te zetten. Als raamwerk voor het beoordelen van de testresultaten hebben wij het raamwerk gekozen dat door Deloitte wordt gebruikt wanneer zij steunt op het werk van derde partijen. Iedere organisatie zal zijn eigen versie hebben van een dergelijk raamwerk. Het raamwerk bevat de volgende elementen die door een reviewer of derde partij kunnen worden beoordeeld teneinde vast te stellen dat het testwerk juist en volledig is uitgevoerd: Algemene informatie: naam van de tester, datum van de test, naam uitvoerder van de beheersmaatregel die getest is Gekozen testmethode (reperformance, corroborative inquiry, observation, examination of documentation, inspection) Beschrijving van de beheersmaatregel die getest wordt Omvang van de steekproef Vaststelling steekproef (juiste spreiding) Documentatie van de steekproef Norm waartegen de steekproef getoetst wordt Documentatie van eventuele uitzonderingen/bijzonderheden/fouten Documentatie van het bewijs onderliggend aan de test Documentatie van de conclusie over de werking van de beheersmaatregel Aftekening door de tester en (indien van toepassing) de reviewer van de testwerkzaamheden In de volgende paragrafen worden de traditionele wijze van het testen van beheersmaatregelen en vervolgens de methode van embedded testing behandeld. Indien wordt gesproken over de elementen waaraan een test moet voldoen, dan wordt aan de bovenstaande opsomming gerefereerd. Pagina 7 van 29

8 Traditionele wijze van het testen van beheersmaatregelen Nadat de controleraamwerken waren bijgewerkt of nieuw opgesteld waren, werden deze binnen de organisaties geïmplementeerd. Via bijvoorbeeld awareness- en trainingssessies werden de medewerkers op de hoogte gebracht van de importantie en werking van de beheersmaatregelen. Hiernaast werd veelal een systeem ingericht waarmee de beheersmaatregelen getest werden. Dit systeem was vooral in het begin meestal specifiek afgestemd op de wensen en eisen van de externe auditor aangezien deze de verklaring van management over de effectiviteit van de interne beheersmaatregelen met betrekking tot financiële verslaglegging moest certificeren. Door de strikte formulering van AS2 8 en de voorzichtige houding van de accountantsorganisaties leidde dit over het algemeen tot uitgebreide testmethoden en testorganisaties. Management testte de beheersmaatregelen op een gelijke wijze als de externe auditor deed zodat er slechts een geringe kans was dat de accountant management s verklaring niet zou certificeren. Alle beheersmaatregelen werden hetzelfde behandeld, er werd zelden onderscheid gemaakt tussen beheersmaatregelen met een die een laag risico voor het bedrijf afdekken en diegene die een en hoog risico afdekken. Alles werd gedaan om maar compliant te zijn. Het testen van de beheersmaatregelen werd veelal gedaan door gespecialiseerde partijen. Dit was bijvoorbeeld de IAD of een IC afdeling. Tevens huurden veel bedrijven een accountantsorganisatie in om voor hen het management testing uit te voeren. Het gebruik van de gespecialiseerde partijen had een aantal voordelen: de organisatie kreeg resources die er intern vaak niet waren, het testprogramma werd uitgevoerd door in deze materie geschoolde mensen waardoor management met een gerust hart de verklaring kon afgeven en tenslotte kon de externe accountant in sommige gevallen op het werk steunen dat door deze partijen was uitgevoerd. Hoewel iedere accountantsfirma zijn eigen regels hieromtrent heeft, is het over het algemeen zo dat een externe accountant meer kan steunen op het werk van een andere partij als deze beschikt over een hoge mate van objectiviteit en een hoge mate van competentie. Het hierboven beschreven principe waarbij de beheersmaatregelen worden getest door een partij die zelf geen deel uit maakt van de bedrijfsprocessen waarbinnen de betreffende control wordt uitgevoerd, wordt ook wel add-on testing genoemd. Deze term zullen we in het vervolg van deze scriptie dan ook gebruiken. Na de eerste jaren van SOX werd duidelijk dat de regels aan verfijning toe waren. De regels werden als te strikt ervaren, iets dat door de SEC en de PCAOB werd erkend 9 waarna AS2 is vervangen door AS5 10. Deze aangepaste standaard gaat van een aanpak uit die meer risk based is; de nadruk moet gelegd worden op die gebieden die een hoog risico vormen voor de organisatie, of in het geval van de externe accountant, voor de uit te voeren audit. Hiernaast moet meer gebruik worden gemaakt van de zogenaamde monitoring controls en 8 Auditing Standard No. 2 An Audit of Internal Control Over Financial Reporting Performed in Conjunction with An Audit of Financial Statements, PCAOB Release No , May 24, De PCAOB en SEC hebben naar aanleiding van de ervaring van de eerste afgeronde SOX verklaringen zogenaamde round tables georganiseerd teneinde verbeteringen in de regelgeving aan te kunnen brengen. Dit heeft geleid tot de invoering van AS5, waar een aantal van de geconstateerde beperkingen en problemen die AS2 met zich meebracht zijn weggenomen. 10 Auditing Standard no. 5 An Audit of Internal Control Over Financial Reporting that is Integrated with an Audit of Financial Statements and Related Independence Rule and Conforming Amendments, PCAOB release no , may 24, 2007 Pagina 8 van 29

9 hoeft de externe accountant geen verklaring meer af te geven over management s beoordeling van de interne beheersmaatregelen. De verklaring van de externe accountant heeft slechts betrekking op de door de accountant uitgevoerde werkzaamheden op het stelsel van interne beheersmaatregelen van de betreffende organisatie. Dit laatste is een erg belangrijke verandering. Het leidt er namelijk toe dat management s werkzaamheden kunnen verschillen van die van de externe accountant. Beide partijen kunnen een verschillende scope hanteren en bijvoorbeeld verschillende testmethodes hanteren. Hiernaast krijgt de externe accountant binnen AS5 meer ruimte om te steunen op het werk dat uitgevoerd is door andere partijen Embedded testing Het embedded testing concept; wat is het? De term embedded testing is nu een aantal keer gebruikt. Wat houdt de term nu in? In feite betekent embedded testing, het embedden van de testwerkzaamheden in de uitvoering van de controle stappen binnen de bedrijfsprocessen. Het concept is het best uit te leggen aan de hand van het volgende voorbeeld. Binnen een bedrijfsproces, laten we zeggen het proces van inkoop van goederen tot de betaling daarvan, worden in een standaardsituatie de volgende twee beheersmaatregelen uitgevoerd: 1. Reconciliatie van de ontvangen facturen met de ontvangen goederen. Na de uitvoering van de control, stuurt de administrateur de reconciliatie met bijbehorende documenten naar zijn/haar lijnmanager. 2. Review door de lijnmanager op de uitgevoerde reconciliatie(s). Het doel van de review door de lijnmanager is over het algemeen om vast te stellen dat de reconciliatie is uitgevoerd, eventuele aandachtspunten worden opgevolgd en dat de reconciliatie juist en volledig is gedocumenteerd. De lijnmanager voegt daarmee in feite geen nieuwe informatie toe aan het geheel, in feite test deze persoon de control. Let wel, het is niet iets nieuws, het is onderdeel van de standaard plan-do-act-check management cyclus 11. Beide beheersmaatregelen zijn aangemerkt als key control en worden daarom zowel door management als de externe auditor getest, tenminste op de manier zoals bedoeld is onder de traditionele manier van testen. Immers, iedere key control wordt getest door management en indien de externe accountant een verklaring over de effectiviteit van de interne beheersmaatregelen van de organisatie afgeeft of op de beheersmaatregelen steunt in het kader van de jaarrekeningcontrole, ook door de externe auditor. 11 Management cycles staat ook wel bekend als de kwaliteitscyclus van Deming, Pagina 9 van 29

10 Schematisch ziet het er dan als volgt uit: Figuur 1: Traditionele wijze van het testen van beheersmaatregelen Wanneer het embedded testing concept wordt toegepast, verandert de testmethode als volgt. Beide beheersmaatregelen worden nog steeds uitgevoerd, dus de reconciliatie wordt uitgevoerd en de resultaten ervan worden naar de lijnmanager gestuurd voor de controle die op het hogere niveau wordt uitgevoerd. Het grote verschil is nu dat de controle door de lijnmanager zodanig wordt ingevuld dat dit in feite een test is van de onderliggende control. Dit betekent dat de lijnmanager werkzaamheden uitvoert die normaal gesproken in het werkprogramma zouden staan voor het uitvoeren van de test. Hiermee vervalt niet alleen de test van de reconciliatie door de administrateur maar tevens vervalt hiermee de test van de controle uitgevoerd door de lijnmanager. We gaan er in deze scriptie voor de duidelijkheid in de beschrijvingen vanuit dat de lijnmanager de embedded tests uitvoert. Een schematische weergave van het bovenstaande is dan ook: Figuur 2: Testen van beheersmaatregelen bij embedded testing Kortom, de reconciliatie wordt getest binnen hetzelfde bedrijfsproces als waarbinnen de control wordt uitgevoerd. Add-on testwerk (test 1 en test 2), het testwerk uitgevoerd door personen die geen deel uitmaken van de reguliere bedrijfsprocessen waarbinnen de control wordt uitgevoerd, is niet meer nodig en dit scheelt dus veel tijd en daarmee dus geld. Immers, de lijnmanager voert in ieder geval al de controle op de reconciliaties uit, het is onderdeel van het bestaande bedrijfsproces. Dit bovenstaande geldt dan echter alleen voor de organisatie zelf. De externe accountant zal test 1 uit blijven voeren voor haar eigen verklaring. Uiteraard zou deze ook kunnen steunen op het werk van de lijnmanager maar zoals in paragraaf 2.3 zal worden beschreven, is dit veelal niet mogelijk waardoor de add-on test blijft bestaan. Pagina 10 van 29

11 Aangezien nu een beheersmaatregel is verdwenen uit het controleraamwerk van de organisatie en is vervangen door een test, is het van belang dat de organisatie bekijkt in hoeverre alle risico s nog steeds worden afgedekt nu deze maatregel is weggehaald. De praktijk leert dat in dit geval de organisatie ervoor zorgt dat de beheersmaatregel die overblijft alle betreffende potentiële fouten afdekt, desnoods door de maatregel iets uit te breiden zodat alle potentiële fouten voldoende worden afgedekt. Indien dit niet het geval is, dan zal de organisatie met een gat in het controleraamwerk komen te zitten, die weer opgevuld moet worden met een nieuwe control. Het bovenstaande betekent wel dat de werkzaamheden zoals die worden uitgevoerd door de lijnmanager, geanalyseerd moeten worden. Dit is noodzakelijk om ervoor te zorgen dat de werkzaamheden die eerst als control werden aangemerkt, nu als test gaan gelden. Dit betekent concreet ook dat de embedded test zodanig vormgegeven moet worden dat de elementen die in paragraaf zijn genoemd worden meegenomen in de vastlegging van de werkzaamheden. Dit betekent in veel gevallen dat, in het geval van het voorbeeld, de lijnmanager zijn of haar werkzaamheden iets anders in moet richten of moet documenteren zodat aan de eisen die gelden voor het uitvoeren en documenteren van een test wordt voldaan Embedded testing in relatie tot monitoring controls Bij embedded testing blijft de uit te voeren beheersmaatregel op een laag niveau binnen het bedrijfsproces waarbij de review die erop wordt uitgevoerd als test geldt. Op zichzelf is dit uiteraard prima, maar het is in tegenspraak met de bedoelingen van de implementatie van AS5 en de aangepaste SEC regels. Zoals eerder aangegeven, hebben de PCAOB en de SEC hun regels versoepeld teneinde de bedrijven en de externe auditors de mogelijkheid te geven meer hun eigen inzicht te gebruiken en minder gebonden te zijn aan specifieke voorschriften. Eén van de zaken die hierbij ook genoemd wordt, is het gebruik van de zogenaamde monitoring controls. Dit zijn de beheersmaatregelen die relatief hoog in het bedrijfsproces worden uitgevoerd. Deze beheersmaatregel is dan de key control en de onderliggende maatregelen worden daarmee afgedekt. In feite is de review door de lijnmanager uit het voorbeeld een voorbeeld van een monitoring control want door deze goed in te richten en met de juiste precisie te laten werken, kan de onderliggende maatregel als non-key worden beschouwd. Ook deze insteek zou kunnen leiden tot het verlagen van de compliancekosten. Echter, aangezien we in deze scriptie ons beperken tot de potentie van embedded testing binnen het IT proces, laten we dit verder buiten beschouwing, 2.3. Voor- en nadelen van embedded testing Wat zijn nu de specifieke voordelen die embedded testing met zich meebrengt? In het artikel van Klumper en Geuzenbroek 12 wordt een aantal voordelen genoemd. De belangrijkste hiervan zijn in deze paragraaf opgenomen: In de eerste plaats is embedded testing natuurlijker dan add-on testing. De werkzaamheden worden binnen de bestaande bedrijfsprocessen uitgevoerd zonder bemoeienis van andere partijen. Add-on testing wordt gedaan door personen die geen rol hebben binnen het betreffende bedrijfsproces 12 Embedded testing: a cure for Sox Blues, C. Klumper & S. Geuzenbroek, februari 2007 Pagina 11 van 29

12 Ten tweede kunnen de compliancekosten significant worden verlaagd met 50% doordat geen add-on testing meer uitgevoerd hoeft te worden. In de derde plaats worden zwakheden in beheersmaatregelen geïdentificeerd door iemand die daartoe het best in staat is, namelijk degene die vanuit het bedrijfsproces zelf verantwoordelijk is voor het (deel)proces. Tevens worden deze zwakheden sneller geïdentificeerd, namelijk tijdens het proces zelf en niet tijdens een periodieke testcyclus. Tenslotte leidt embedded testing tot verhoging van de control awareness van de betrokkenen, iets wat de algehele control environment alleen maar ten goede komt. Dit betekent dat in dit geval de lijnmanagers zich beter bewust zijn van het uitvoeren van beheersmaatregelen, de noodzaak hiervoor inzien en ook de toegevoegde waarde van de beheersmaatregelen begrijpen. Dit besef zal ongetwijfeld zijn uitwerking niet missen op de andere betrokkenen in het bedrijfsproces. Deze zullen worden aangesproken op eventuele fouten, slordigheden en hun houding ten opzichte van het uitvoeren van beheersmaatregelen. Embedded testing lijkt iets wat iedere organisatie moet willen implementeren. Maar is dit ook zo? Het embedded testing concept heeft naast de genoemde voordelen, ook een drietal nadelen: 1. Het eerste nadeel is dat het controleraamwerk moet worden herzien. Er moet een analyse gedaan worden van de huidige beheersmaatregelen en welke hiervan in aanmerking komen voor het embedded testing concept. Dit kan tot veel irritatie en weerstand binnen organisaties leiden aangezien de meeste bedrijven juist net klaar zijn met de (vaak moeizame) implementatie van hun controleraamwerk. 2. Hiernaast wordt het testwerk bij embedded testing uitgevoerd door mensen die hier niet specifiek voor opgeleid zijn. Medewerkers van een IC afdeling of IAD zijn over het algemeen ervaren en getraind in het testen van beheersmaatregelen, lijnmedewerkers zijn dit over het algemeen niet. 3. Tenslotte bestaat het gevaar dat zwakheden in de beheersmaatregelen worden genegeerd of in de doofpot worden gestopt. Frauderen is tenslotte makkelijker geworden aangezien er geen add-on testing plaatsvindt. Ook vermenging van functies is een risico wat hier speelt. Hiernaast kan het voorkomen dat iemand die dagelijks in het bedrijfsproces actief is bedrijfsblind wordt voor bepaalde fouten die eigenlijk geconstateerd hadden moeten worden. Kortom, door iemand binnen een bedrijfsproces het testwerk uit te laten voeren, loopt een organisatie het risico dat tests niet juist, volledig en objectief uitgevoerd worden. Zoals in paragraaf is beschreven, hebben de externe accountants onder AS5 meer ruimte gekregen om voor hun eigen werk te steunen op het werk van andere partijen. Echter, ook hierbij blijft het van belang dat deze partijen voldoende competent en objectief zijn. Zoals hierboven beschreven kan embedded testing leiden tot een verminderd niveau van competentie en objectiviteit waardoor de externe accountant wellicht niet op de embedded tests wil steunen. Kort gezegd kan het invoeren van embedded testing dus leiden tot een verminderde kwaliteit en objectiviteit van de uitgevoerde testen. Dit wordt door Klumper en Geuzenbroek erkend 13. Om hier iets aan te doen dient er naast het embedded testing gedeelte een deel add-on 13 Embedded testing: a cure for Sox Blues, C. Klumper & S. Geuzenbroek, februari 2007 Pagina 12 van 29

13 werkzaamheden uitgevoerd te worden. Deze werkzaamheden hebben het karakter van kwaliteitsbewaking (quality assurance) werkzaamheden. Deze werkzaamheden zouden door de IAD uitgevoerd kunnen worden en zouden moeten bestaan uit het reviewen van het de embedded tests en het op steekproef basis reperformen van de tests. Over het algemeen wordt een IAD namelijk als competent (getrainde auditors in dienst van de IAD) en objectief (directe rapportage aan de Audit Committee) gezien. Dit betekent dus dat er binnen het embedded testing concept nog wel behoefte is aan werkzaamheden uitgevoerd door een partij die niet binnen de bedrijfsprocessen zelf werkzaam is, zij het op veel geringere schaal dan wanneer op de traditionele wijze wordt getest. In het algemeen zou de IAD meer werkzaamheden moeten verrichten indien een beheersmaatregel en daarmee de test subjectiever van aard is of wanneer de beheersmaatregel een hoog risicogebied afdekt. Wat ons betreft is er echter nog een aantal zaken die kunnen leiden tot het verminderen van de objectiviteit van de tester welke niet door Klumper en Geuzenbroek worden opgenomen. Het betreft hier namelijk zaken zoals bonusafspraken rondom het halen van bepaalde indicatoren of andersom geredeneerd, het instellen van consequenties indien indicatoren niet gehaald worden. Tevens kan er door management druk op medewerkers worden gelegd om bepaalde resultaten te boeken waardoor betrokkenen wellicht sneller hun ogen sluiten voor het niet helemaal volgen van bepaalde procedures of beheersmaatregelen. De inzet van de IAD kan hier slechts ten dele bij helpen om eventuele malversaties tegen te gaan. Juist de tone at the top is in dit licht essentieel maar tevens zou het in dergelijke gevallen wellicht verstandiger zijn om deze controls door een derde, onafhankelijke, partij te laten testen. De objectiviteit van een tester in het embedded testing principe is tevens van belang wanneer de uitvoering van de daadwerkelijke test wordt bekeken. Immers, de tester bepaalt zelf de steekproef en kan daarmee de test beïnvloeden. Wat gebeurt er nu als iemand voor een bepaalde test een steekproef trekt waarbij de eerste meteen een fout oplevert? Zal diegene dan de fout documenteren of een andere steekproef nemen? Ook hier kan een onafhankelijke derde partij uitkomst bieden, zoals de IAD. Naast de eerder genoemde zaken als het uitvoeren van QA procedures op bijvoorbeeld de testplannen en het uitgevoerde werk, zou de IAD ook de steekproef kunnen bepalen. Op deze wijze is de tester gebonden aan de opgelegde steekproef en kan de IAD later verifiëren of de tester de aangewezen steekproef heeft gebruikt. Een bijkomend probleem voor het gebruik van embedded testing is de regel van de PCAOB die stelt dat the external auditor cannot make use of tests performed by managers with supervisory responsibility over the area for which the control tested is part. Dit betekent dat een externe auditor niet op embedded testing mag steunen aangezien de externe auditor gebonden is aan deze PCAOB regels. Het feit dat een organisatie die in de Verenigde Staten aan de beurs is genoteerd wel het embedded testing concept mag gebruiken, komt doordat zij niet gebonden is aan de PCAOB regels maar juist aan die van de SEC. De PCAOB schrijft namelijk de standaarden (in dit geval AS5) voor die de externe auditor dient te hanteren bij het auditen van een organisatie die aan de Amerikaanse beurs genoteerd is. Aangezien het gebruik van embedded testing onder meer tot de verlaging van de compliancekosten moet leiden, is dit zeker een aderlating. Indien de externe auditor wel op het werk van management zou mogen (en willen) steunen dan zou dit namelijk voor een organisatie een extra efficiëntieslag betekenen. Pagina 13 van 29

14 2.4. Toepassing van embedded testing Uit de voorgaande paragraaf blijkt dat er naast een aantal voordelen voor het gebruik van het embedded testing concept, ook een aantal randvoorwaarden en nadelen bestaan waar rekening mee gehouden moet worden bij een eventuele implementatie. Het is daarom van belang om te kijken of en zo ja waar embedded testing toegepast kan worden. Klumper en Geuzenbroek beschrijven een aantal randvoorwaarden voor het gebruik van embedded testing. In de eerste plaats dient, zoals ook eerder is gezegd, een onafhankelijke partij (zoals de IAD) te verifiëren dat al het embedded testwerk adequaat is uitgevoerd. Ten tweede dienen de uitvoerders van de embedded tests continu ondersteuning te krijgen bij het opstellen van testactiviteiten en het beoordelen en interpreteren van de test resultaten, bijvoorbeeld de IC. Tenslotte noemen zij nog het eenvoudig documenteren van de embedded testresultaten als randvoorwaarde waarvoor een geautomatiseerde tool gebruikt kan worden. Deze tool verschaft dan niet alleen een eenvoudige verwerking van de resultaten maar geeft management tevens inzicht in de voortgang van het testwerk in het algemeen. Deze punten zijn echter niet specifiek van toepassing voor embedded testing maar gelden uiteraard ook voor de traditionele wijze van testen Business as usual Zoals eerder gezegd is embedded testing eigenlijk niets nieuws. In de dagelijkse praktijk zijn lijnmanagers verantwoordelijk voor de processen binnen hun afdeling waarop zij ook worden aangesproken door hun eigen leidinggevenden. De lijnmanagers zijn iedere dag onderdeel van het bedrijfsproces, lopen rond, praten met hun medewerkers en hebben waarschijnlijk regelmatig overleg. Dus wat is het verschil? In feite is het proces zoals net beschreven te omschrijven als een relatief informeel proces, waarbij er waarschijnlijk wel formele controle punten zijn, maar waar geen sprake is van een serie van key controls die door de lijnmanager beoordeeld worden. In feite kun je stellen dat de lijnmanager negatieve zekerheid verschaft richting derde partijen zoals de IAD maar bijvoorbeeld ook de CFO. Onder negatieve zekerheid verstaan we de zekerheid die een partij krijgt op basis van het uitgevoerde (test) werk. Van negatieve zekerheid is bijvoorbeeld sprake indien de steekproef te klein was voor een bepaalde test of indien niet alle van toepassing zijnde tests zijn uitgevoerd doordat bijvoorbeeld het normenkader onvoldoende is gedocumenteerd of geïmplementeerd. Positieve zekerheid kan in dit geval alleen verkregen worden door gebruik te maken van add-on testing. Bij embedded testing ligt dit anders. De lijnmanagers voeren zelf testwerkzaamheden uit die een formeel karakter hebben. Immers de basisregels van het testen van een control moeten gevolgd worden zowel qua inhoud als documentatie en daarmee worden de tests dus bijvoorbeeld ook controleerbaar. De derde partijen kunnen hierdoor wel positieve zekerheid krijgen aangezien voor de tests een toereikende steekproef wordt gebruikt en alle van toepassing zijnde controls worden getest. Pagina 14 van 29

15 2.6. Resume Op basis van de bovenstaande paragraaf valt op te maken dat embedded testing in feite niets nieuws is, maar slechts een integratie van de bestaande bedrijfsprocessen en beheersmaatregelen daarbinnen met de verplichting om de uitgevoerde beheersmaatregelen te testen. Het uiteindelijke doel van embedded testing is het verlagen van de compliancekosten doordat het aantal uren dat besteed moet worden door gespecialiseerde partijen om de beheersmaatregelen te testen wordt verlaagd. Hiernaast heeft embedded testing nog een aantal voordelen, waarvan één van de grootste toch wel het control aware maken van de lijnmanager c.q. managers is. Naast de voordelen kleeft er wel een aantal nadelen aan het concept, welke vooral hun weerslag hebben op de objectiviteit van de testers en de door hen uitgevoerde tests. Embedded testing kan in principe overal worden toegepast, echter per control moet bekeken worden in hoeverre embedded testing bijdraagt aan een efficiëntere uitvoering van het testwerk. Embedded testing leidt tot de mogelijkheid voor het verkrijgen van positieve zekerheid door derde partijen, iets wat bij een informeel proces alleen door add-on testing mogelijk is. Tenslotte heeft het gebruik van embedded testing tot gevolg dat de externe accountant veelal niet op de embedded tests kan steunen. Pagina 15 van 29

16 3. Het testen van IT General Controls In het vorige hoofdstuk is beschreven wat embedded testing is. In dit hoofdstuk zal worden ingegaan op de vraag of embedded testing ook kan worden toegepast bij het testen van de ITGC. Om hier een antwoord op te geven is het van belang te weten wat wordt verstaan onder de term de ITGC Wat zijn IT General Controls? Interne beheersmaatregelen zijn opgesteld om processen te beheersen en te sturen. Deze maatregelen kunnen daarmee ook worden opgesteld voor de processen binnen de IT omgeving. Een raamwerk dat veelal als startpunt wordt gebruikt voor het opstellen van deze maatregelen is het Control Objectives for Information and related Technology 14 raamwerk, oftewel Cobit. Cobit is in feite een best practices raamwerk dat is gecreëerd in 1996 door Information Systems Audit and Control Association (ISACA) en het IT Governance Institute (ITGI). Vanuit verschillende gebieden die binnen Cobit worden onderkend, wordt uiteindelijk afgedaald naar de verschillende controledoelstellingen die voor een IT proces kunnen worden geïmplementeerd. Deze doelstellingen dienen uiteindelijk door de verschillende interne beheersmaatregelen afgedekt te worden. Deze beheersmaatregelen, de ITGC, zijn daarmee de beheersmaatregelen die in IT processen en services zijn opgenomen om het proces beheersbaar en controleerbaar te maken. In paragraaf 4.1 worden voorbeelden genoemd van de ITGC. In de praktijk worden de ITGC nog wel eens verward met de application controls. Deze application controls zijn de beheersmaatregelen die zijn vastgelegd, vaak gecodeerd, binnen de applicaties die het business proces ondersteunen. De verantwoordelijkheid voor deze beheersmaatregelen ligt normaal gesproken niet bij de IT organisatie maar bij de eigenaars van de betreffende bedrijfsprocessen en worden voor het doel van deze scriptie buiten beschouwing gelaten. De relatie tussen de ITGC wordt als bekend verondersteld: de ITGC waarborgen de integriteit van de applicaties en de daarbinnen opgenomen application controls ITGC onderdelen De ITGC vormen het fundament van de IT beheersstructuur. De ITGC dragen bij aan de betrouwbaarheid van de informatie die afkomstig is uit IT systemen. Daarnaast ondersteunen de ITGC de assumptie dat IT systemen en applicaties functioneren zoals bedoeld is. In de praktijk heeft iedere organisatie haar eigen selectie gemaakt van de algemeen bekende ITGC gebieden (gebaseerd op Cobit, ITIL, ISO 27001) en daarbij de relevante beheersmaatregelen geselecteerd. Uiteraard maken accountantskantoren gebruik van vergelijkbare selecties om hun controle op de ITGC van de organisatie uit te voeren. Deloitte heeft de ITGC beheersmaatregelen onderverdeeld in 10 gebieden. In de volgende tabel worden deze gebieden getoond. Per onderdeel is aangegeven of het een value added 14 Control Objectives for Information and related Technology (COBIT), IT Governance Institute, versie 4.1, 2007 Pagina 16 van 29

17 ITGC gebied betreft of dat het om een audit gerelateerd gebied gaat. Hiernaast is een korte beschrijving opgenomen van het betreffende gebied. De gebieden die als audit aangemerkt zijn, worden standaard binnen een IT audit in het kader van de jaarrekeningcontrole of voor een audit in het kader van SOX opgenomen in de scope van de werkzaamheden. De value added gebieden worden niet verplicht binnen de standaard IT audit meegenomen maar vormen vaak het raamwerk voor aparte opdrachten die meestal niet direct gerelateerd zijn aan de audit van de interne beheersmaatregelen in het kader van SOX of van een standaard jaarrekeningcontrole. Wij zullen deze indeling, inclusief de onderliggende beheersmaatregelen, gebruiken om te kijken in hoeverre embedded testing toegepast kan worden binnen de ITGC beheersmaatregelen. Deloitte ITGC gebied Korte omschrijving Audit of Value added Information Resource Strategy and Planning Maatregelen om te zorgen dat IT-strategie, - plannen en budgetten in overeenstemming zijn met het beleid van de organisatie. Tevens vallen zaken als adequate training voor personeel en aannamebeleid voor IT personeel onder dit gebied. Value added Information Systems Operations Relationships with outsourced vendors Information Security Business Continuity Planning Application Systems Implementation and Maintenance Database Implementation and Support Network Support Maatregelen rondom dataretentie en dataopslag en het tijdig en juist uitvoeren van batch processen en het rapporteren hierover. Maatregelen rondom SLA-management en het inhuren van de juiste externe partijen. Maatregelen rondom de implementatie en beheer van logische toegangsbeveiliging tot programma s, data en andere informatiedragers. Hiernaast maatregelen rondom de implementatie en beheer van fysieke toegangsbeveiliging voor toegang tot en gebruik maken van informatie. Maatregelen die genomen dienen te worden in het geval van een calamiteit teneinde essentiële bedrijfsprocessen weer in de lucht te krijgen. Maatregelen om te waarborgen dat nieuwe applicaties volgens de intenties van management worden geïmplementeerd en opereren. Tevens maatregelen rondom de correcte conversie van data in het geval nieuwe implementaties, de tijdige en correcte implementatie van wijzigingen aan bestaande applicaties en systemen zodat deze volgens de intenties van management blijven functioneren. Maatregelen om te waarborgen dat datastructuren correct worden gedefinieerd en geïmplementeerd in lijn met de intenties van management. Hiernaast het tijdig en correct wijzigen van de datastructuren teneinde te zorgen dat deze nog steeds voldoen aan de intenties van management. Maatregelen om te zorgen dat nieuwe netwerk- en communicatiesoftware correct wordt geïmplementeerd in lijn met de Audit onderdeel Value added Audit onderdeel Value added Audit onderdeel Audit onderdeel Audit onderdeel Pagina 17 van 29

18 Deloitte ITGC gebied Korte omschrijving Audit of Value added intenties van management. Hiernaast maatregelen om te zorgen dat wijzigingen aan de bestaande infrastructuur tijdig en correct worden geïmplementeerd zodat deze blijven voldoen aan de intenties van management. Systems Software Support Hardware Support Tabel 1: Deloitte ITGC raamwerk Maatregelen om te zorgen dat nieuwe software correct wordt geïmplementeerd in lijn met de intenties van management. Hiernaast maatregelen om te zorgen dat wijzigingen aan de bestaande software tijdig en correct worden geïmplementeerd zodat deze blijven voldoen aan de intenties van management. Maatregelen om te zorgen dat nieuwe hardware wordt gekocht volgens de intenties van management en vervolgens correct wordt geïmplementeerd. Hiernaast de tijdige en correcte wijzigingen implementeren aan de bestaande configuratie zodat deze functioneert in lijn met de intenties van management. Audit onderdeel Value added In paragraaf 4.1 zal worden ingegaan op de audit gebieden en de redenering of embedded testing mogelijk is per beheersmaatregel ITGC en embedded testing In hoofdstuk twee is het embedded testing principe behandeld naast de traditionele wijze van testen. In de basis is embedded testing een manier voor de lijnmanager om meer grip te krijgen op zijn of haar proces. Maar verschilt de toepassing van embedded testing binnen standaard bedrijfsprocessen nu van de toepassing binnen het IT proces? Zoals eerder beschreven is er een aantal randvoorwaarden waaraan voldaan moet worden indien het embedded testing principe wordt toegepast. Deze bestaan uit de review van de embedded tests door een onafhankelijke partij, de ondersteuning van de embedded testers in het opstellen van de testactiviteiten en het interpreteren van de resultaten daarvan en tenslotte het gebruik van een tool ter ondersteuning van de testers. De genoemde randvoorwaarden zijn allen erg generiek van aard en kunnen prima worden toegepast binnen de IT cyclus. Echter, het is de vraag of in de praktijk embedded testing binnen het IT proces toegepast kan worden. Immers, twee elementen die er voor kunnen zorgen dat het niet opportuun is om embedded testing toe te passen zijn de benodigde specialistische kennis benodigd voor het testen van de control en simpelweg de vraag wat de meest efficiënte wijze is om een control te testen. In het volgende hoofdstuk gaan we in op de vraag of en zo ja in welke mate embedded testing binnen het IT proces toegepast kan worden. Pagina 18 van 29

19 4. Embedded testing binnen ITGC in de praktijk De vraag of embedded testing binnen de ITGC toegepast kan worden is in feite al in het voorgaande hoofdstuk beantwoord, namelijk met ja. Het maakt geen verschil of het concept nu wordt toegepast binnen de standaard bedrijfsprocessen of binnen het IT proces. Het is echter de vraag of dit voor alle ITGC gedaan kan worden. In dit hoofdstuk wordt de praktische invulling van embedded testing binnen ITGC behandeld. In het algemeen kan gesteld worden dat net als bij de toepassing van embedded testing in de standaard bedrijfsproces, een belangrijke voorwaarde binnen het concept de objectiviteit van de tester is. Indien de objectiviteit niet gegarandeerd is, kan het mogelijk zijn dat bevindingen in de doofpot worden gestopt. Problemen en bevindingen moeten worden gemeld en niet worden verborgen voor de organisatie. De IAD zal daarom de uitgevoerde tests van de lijnmanagers moeten controleren en hertesten en kan zoals in paragraaf 2.3 aangegeven aanvullende werkzaamheden uitvoeren. Hiernaast zal management duidelijk stelling moeten nemen tegen het niet of onjuist uitvoeren van de tests. Dit kan gebeuren door sancties op te nemen in de beoordelingstrajecten van de lijnmanagers maar hiernaast is de tone at the top essentieel. Naast dat de lijnmanagers objectief moet zijn, dienen deze ook voldoende kennis te hebben van het testen van beheersmaatregelen. Het is van belang dat een lijnmanager begrijpt hoe het ontwerp, de implementatie en de werking moet worden getest. Per ITGC zal in de komende paragraaf gekeken worden in hoeverre embedded testing toegepast zou kunnen worden. Hiernaast zullen we ingaan op die zaken die naast de eerder genoemde randvoorwaarden van belang zijn om het concept succesvol te kunnen implementeren Embedded testing per ITGC Zoals eerder gemeld is embedded testing een minder goede oplossing als er voor het testen van de control erg veel specialistische kennis, ten opzichte van de kennis die de lijnmanager al heeft, benodigd is. Hiernaast moet het gewoonweg efficiënt zijn om de controls via embedded testing te testen. Om inzicht te krijgen in de potentie van embedded testing binnen de ITGC, hebben we per maatregel gekeken in hoeverre deze geschikt zou zijn om via het embedded testing concept te laten testen. Deze analyse is gedaan door gebruik te maken van het Deloitte ITGC raamwerk dat gebruikt wordt om de ITGC van een organisatie te beoordelen. Aangezien de scope van het onderzoek zich specifiek richt op een organisatie die aan de SOX-regelgeving dient te voldoen, hebben we het raamwerk gebruikt dat specifiek voor deze klanten wordt gebruikt. De onderstaande tabel geeft de maatregelen weer per ITGC gebied waarvoor is geanalyseerd of embedded testing hiervoor toegepast kan worden met inachtneming van de eerder genoemde randvoorwaarden. De lijst is opgesteld op basis van onze eigen ervaringen en op basis van het interview dat is gehouden met de IT director van de multinational die als enige organisatie vooralsnog het embedded testing concept heeft uitgewerkt. Pagina 19 van 29

20 ITGC Gebied Beheersmaatregel Geschikt voor ET Redenering Information Systems Operations Ja Information Security IR099 Processing is monitored by management to ensure successful and timely completion, including a review and resolution of any exceptions. IR203 Automated scheduling tools have been implemented to ensure the authorization and completeness of the flow of processing. IR157 Information security tools and techniques are used to restrict access to information resources (e.g. data files, utilities, transactions, programs). Management reviews and approves the implementation and configuration of information security tools and techniques. Nee Gedeeltelijk Indien binnen het IT proces nog een verantwoordelijk persoon management kan reviewen dan is embedded testing bij deze maatregel mogelijk. Voor deze maatregel is geen specialistische kennis vereist. Specialistische kennis is vereist voor het testen van deze beheersmaatregel. Het betreft hier kennis van de tool die is geïmplementeerd voor het plannen, autoriseren en monitoren van processen vanuit verschillende applicaties. Het eerste gedeelte van deze beheersmaatregel zou specialistische kennis kunnen vereisen. Hierdoor is het eerste gedeelte van deze beheersmaatregel minder geschikt voor embedded testing. Aangezien het in het tweede deel gaat om de review van management is het van belang om te kijken of er binnen het IT proces nog een verantwoordelijk persoon management kan reviewen. Indien dit het geval is, dan is embedded testing bij deze maatregel voor dit deel mogelijk. IR073 Application owners authorize the nature and extent of user access privileges and such privileges are periodically reviewed by application owners to ensure access privileges remain appropriate. User access is controlled through passwords or other mechanisms. Passwords are changed periodically. IR086 Physical access to the building and immediate surroundings of computer equipment is monitored and is restricted to individuals who require such access to perform their job responsibilities. Management approval is required before access is granted. IR218 A physical access control mechanism is used to restrict and record access to protected areas Ja Ja Ja De review van toegangsprivileges is te testen door een lijnmanager. Daarnaast is het niet erg lastig te verifiëren dat toegangscontrole is geïmplementeerd en dat de wachtwoorden periodiek worden veranderd. Fysieke controle van toegang en de processen rondom toegang verkrijgen zijn geschikt voor embedded testing. De management approval moet wederom getoetst worden door een lijn hoger dan het management dat de approval geeft maar zou prima door embedded testing getoetst kunnen worden. Fysieke controle van toegang en de processen rondom toegang verkrijgen zijn geschikt voor embedded testing. Pagina 20 van 29