Embedded testing binnen IT General Controls

Embedded testing binnen IT General Controls Goed alternatief of waardeloze optie?

Amsterdam, 15 april 2008 Auteurs: Hans Bootsma (9981220) Martijn Knuiman (9981213) EDP Audit Opleiding Vrije Universiteit Amsterdam Begeleider Universiteit: Tjakko de Boer Begeleider Deloitte: Jacques Herman

Inhoudsopgave 1. Inleiding

3

1.1. Aanleiding 1.2. Onderzoeksvraag 1.3. Plan van aanpak 1.4. Afbakening van het onderzoek 1.5. Indeling van de scriptie

2. Embedded testing versus de traditionele manier van testen 2.1. Traditionele wijze van testen van interne beheersmaatregelen 2.1.1. Interne beheersmaatregelen oftewel Internal Controls 2.1.2. Het testen van beheersmaatregelen 2.1.3. ‘Traditionele’ wijze van het testen van beheersmaatregelen 2.2. Embedded testing 2.2.1. Het embedded testing concept; wat is het? 2.2.2. Embedded testing in relatie tot monitoring controls 2.3. Voor- en nadelen van embedded testing 2.4. Toepassing van embedded testing 2.5. Business as usual 2.6. Resume

3. Het testen van IT General Controls 3.1. Wat zijn IT General Controls? 3.2. ITGC onderdelen 3.3. ITGC en embedded testing

3 4 4 5 5

6 6 6 7 8 9 9 11 11 14 14 15

16 16 16 18

4. Embedded testing binnen ITGC in de praktijk 4.1. Embedded testing per ITGC 4.2. Embedded testing ondanks noodzaak voor specialistische kennis?

5. Conclusie en reflectie

19 19 24

26

5.1. Conclusie 5.2. Beantwoording van de onderzoeksvraag 5.3. Reflectie

6. Literatuur

26 27 27

29

Pagina 2 van 29

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 Tabaksblat1 en Sarbanes Oxley2 (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 verwacht3. 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

deze compliancekosten met 50% kunnen verminderen4. 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.

1.2.

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.

1.3.

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, www.complianceweek.com, februari 2007

Pagina 4 van 29

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.

1.4.

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.

1.5.

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

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.

2.1.

Traditionele wijze van testen van interne beheersmaatregelen

2.1.1. 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 genoemd5. 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 SEC6 en de PCAOB7 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 2004.

6

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

2.1.2. 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

2.1.3. ‘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 AS28 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 erkend9 waarna AS2 is vervangen door AS510. 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. 2007-005, May 24, 2007 9

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. 2007-005, may 24, 2007

Pagina 8 van 29

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.

2.2.

Embedded testing

2.2.1. 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 cyclus11. 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, http://en.wikipedia.org/wiki/PDCA

Pagina 9 van 29

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

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 2.1.2 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.

2.2.2. 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 Geuzenbroek12 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, www.complianceweek.com, februari 2007

Pagina 11 van 29

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 2.1.3 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 erkend13. 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, www.complianceweek.com, februari 2007

Pagina 12 van 29

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

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.

2.5.

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

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

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.

3.1.

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 Technology14’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.

3.2.

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

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 Information Resource Strategy and Planning

Information Systems Operations Relationships with outsourced vendors Information Security

Business Continuity Planning

Application Systems Implementation and Maintenance

Database Implementation and Support

Network Support

Korte omschrijving 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. 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

Pagina 17 van 29

Audit of Value added Value added

Audit onderdeel

Value added Audit onderdeel

Value added

Audit onderdeel

Audit onderdeel

Audit onderdeel

Deloitte ITGC gebied

Systems Software Support

Hardware Support

Korte omschrijving 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. 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 of Value added

Audit onderdeel

Value added

Tabel 1: Deloitte ITGC raamwerk

In paragraaf 4.1 zal worden ingegaan op de audit gebieden en de redenering of embedded testing mogelijk is per beheersmaatregel.

3.3.

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

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.

4.1.

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

ITGC Gebied

Beheersmaatregel

Geschikt voor ET

Redenering

Information Systems Operations

IR099 Processing is monitored by management to ensure successful and timely completion, including a review and resolution of any exceptions.

Ja

IR203 Automated scheduling tools have been implemented to ensure the authorization and completeness of the flow of processing.

Nee

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.

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

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.

Ja

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.

Information Security

Ja

Pagina 20 van 29

ITGC Gebied

Application Systems Implementation and Maintenance

Database

Beheersmaatregel and authority to change physical access control mechanisms is limited to appropriate personnel. IR154 A risk assessment, which involves valuation of business information resources and identification and assessment of the levels of risks present, has been performed to identify an appropriate and costjustifiable information security architecture. The risk assessment is updated periodically and management has implemented a suitable information security architecture to ensure that there is appropriate physical and logical security. IR050 New application systems and modifications to application systems are tested in accordance with test plans that include, as appropriate, system and unit testing, interface testing, parallel testing, capacity testing and user acceptance testing.

IR052 Management approves the results of the conversion of data (e.g., balancing and reconciliation activities) from the old application system or data structure to the new application system or data structure and monitors that the conversion is performed in accordance with established conversion policies and procedures. IR170 User and other requests for modifications to application systems including upgrades and fixes released by vendors are approved by management and implemented if consistent with information systems’ plans and management’s intentions. IR051 New data structures and modifications to data

Geschikt voor ET

Redenering

Ja

Het testen van deze beheersmaatregel of een risk assessment is uitgevoerd is te toetsen zonder bijzondere technische kennis en daarmee geschikt voor embedded testing.

Ja

Het toetsen of testplannen juist zijn opgesteld en alle specifieke test elementen bevatten is te toetsen zonder specifieke kennis van de applicatie. Echter zodra de inhoud van deze testplannen getoetst moet worden, zal dit specifieke kennis kunnen vereisen. Normaal gesproken is dit niet direct vereist in deze beheersmaatregel en hierdoor is deze beheersmaatregel geschikt voor embedded testing. Voor het testen van deze control is specialistische kennis vereist waardoor de maatregel minder geschikt is voor het gebruik van embedded testing.

Nee

Nee

Om te beoordelen of aanvragen voor wijzigingen juist zijn behandeld en geëvalueerd, kan specialistische kennis benodigd zijn. Daarom lijkt deze maatregelen minder geschikt voor het gebruik van embedded testing.

Ja

Het toetsen of testplannen juist zijn opgesteld en alle specifieke

Pagina 21 van 29

ITGC Gebied

Beheersmaatregel

Implementation and Support

structures are tested in accordance with test plans that include, as appropriate, interface testing, parallel testing, capacity testing, and user acceptance testing.

Network Support

Systems Software Support

Geschikt voor ET

Redenering test elementen bevatten is te toetsen zonder specifieke kennis van de applicatie. Echter zodra de inhoud van deze testplannen getoetst moet worden, zal dit specifieke kennis kunnen vereisen. Normaal gesproken is dit niet direct vereist in deze beheersmaatregel en hierdoor is deze beheersmaatregel geschikt voor embedded testing. Om te beoordelen of aanvragen voor wijzigingen juist zijn behandeld en geëvalueerd, kan specialistische kennis benodigd zijn. Daarom lijkt deze maatregelen minder geschikt voor het gebruik van embedded testing.

IR171 User and other requests for modifications to data structures including upgrades and fixes released by vendors are approved by management and implemented if consistent with information systems’ plans and management’s intentions. IR239 Requests for changes to data structures in the production environment are documented and approved by management. Management monitors implementation of all such changes.

Nee

Ja

Deze beheersmaatregel vereist dat alle aanvragen voor wijzigingen in de datastructuren worden gedocumenteerd. Dit is relatief eenvoudig te toetsen door een lijnmanager. Ook de review van het management is eenvoudig te toetsen waardoor de maatregel prima geschikt is voor gebruik binnen embedded testing.

IR061 New network and communication software and modifications to network and communication software are tested in accordance with test plans that include, as appropriate, system and unit testing, interface testing, parallel testing, capacity testing, and user acceptance testing.

Ja

IR172 User and other requests for modifications to network infrastructure and communications software including upgrades and fixes released by vendors are approved by management and implemented if consistent with information systems’ plans and management’s intentions. IR062 New systems software and modifications to systems software are tested in accordance with test plans that include, as

Nee

Het toetsen of testplannen juist zijn opgesteld en alle specifieke test elementen bevatten is te toetsen zonder specifieke kennis van de applicatie. Echter zodra de inhoud van deze testplannen getoetst moet worden, zal dit specifieke kennis kunnen vereisen. Normaal gesproken is dit niet direct vereist in deze beheersmaatregel en hierdoor is deze beheersmaatregel geschikt voor embedded testing. Om te beoordelen of aanvragen voor wijzigingen juist zijn behandeld en geëvalueerd, kan specialistische kennis benodigd zijn. Daarom lijkt deze maatregelen minder geschikt voor het gebruik van embedded testing.

Ja

Pagina 22 van 29

Het toetsen of testplannen juist zijn opgesteld en alle specifieke test elementen bevatten is te toetsen zonder specifieke kennis van de applicatie. Echter zodra de

ITGC Gebied

Beheersmaatregel

Geschikt voor ET

appropriate, system and unit testing, interface testing, parallel testing, capacity testing, and user acceptance testing.

IR173 User and other requests for modifications to systems software including upgrades and fixes released by vendors are approved by management and implemented if consistent with information systems’ plans and management’s intentions.

Nee

Redenering inhoud van deze testplannen getoetst moet worden, zal dit specifieke kennis kunnen vereisen. Normaal gesproken is dit niet direct vereist in deze beheersmaatregel en hierdoor is deze beheersmaatregel geschikt voor embedded testing. Voor het testen van deze maatregel kan specialistische kennis vereist zijn waardoor deze maatregel minder geschikt os voor het gebruik van embedded testing.

Tabel 2: Overzicht potentie van embedded testing per ITGC

Uit bovenstaande tabel blijkt dat embedded testing vooral kan worden toegepast binnen die beheersmaatregelen die procesgericht zijn. Een voorbeeld hiervan is het change management proces waarbij de maatregelen vooral gericht zijn op het volgen van de juiste stappen en de autorisatie hiervan (bijvoorbeeld maatregelen IR062 en IR173). Alhoewel de tester enige kennis moet hebben over de applicaties c.q. systemen die binnen het change management proces vallen, is echt specialistische kennis van de systemen niet noodzakelijk. Er wordt vooral naar vorm gekeken, of bijvoorbeeld het ‘user acceptance’ testplan uit de juiste onderdelen bestaat, maar de technische test zelf wordt binnen de ITGC normaal gesproken niet beoordeeld. Dit ligt anders bij bepaalde beheersmaatregelen rondom de informatiebeveiliging. In dit proces zijn enerzijds procesmatige beheersmaatregelen aanwezig die zich prima lenen voor het embedded testing principe. Een voorbeeld hiervan is maatregel IR073 waarbij het proces van autoriseren van gebruikers wordt gecontroleerd. Voor deze maatregelen is geen specialistische kennis benodigd. Echter, er is een aantal maatregelen (maatregelen IR157, IR203) waarvoor een tester in feite de specialistische kennis moet hebben om een goede beoordeling te kunnen doen. Hierbij gaat het dan bijvoorbeeld om het beoordelen van systeemconfiguraties waarbij beveiligingsinstellingen beoordeeld moeten worden, functiescheidingen tussen ontwikkelaars en beheerders moeten worden beoordeeld of de instellingen van routers en firewalls moeten worden beoordeeld. In deze gevallen lijkt embedded testing een minder goede oplossing. Indien een persoon de embedded tests uit zou voeren op de zojuist genoemde technische maatregelen dan zou deze dus over de benodigde specialistische kennis moeten beschikken. We hebben in een eerde stadium gezegd dat we ervan uitgaan dat de embedded tests uitgevoerd worden door een lijnmanager. Een lijnmanager heeft over het algemeen minder specialistische kennis dan de medewerkers die hij aanstuurt, welke zeker in het geval van ITGC vaak als technisch specialist te boek staan. Uiteraard is het mogelijk dat deze persoon wel de benodigde kennis bezit en ook de tijd heeft om deze kennis te onderhouden. Echter, de praktijk leert dat lijnmanager na verloop van tijd vooral procesmatig opereren en de specialistische kennis niet meer op kunnen bouwen omdat hier simpelweg te weinig tijd voor is in een wereld waarbinnen ontwikkelingen elkaar snel opvolgen. Dit is door de

Pagina 23 van 29

geïnterviewde director van IT bevestigd als een probleem voor het invoeren van embedded testing op deze gebieden. Kortom, op basis van de analyse kan embedded testing op een groot deel van de ITGC worden toegepast. Slechts voor een paar maatregelen zou het minder geschikt zijn om het testproces via het embedded testing concept te laten lopen. Maar is dit ook zo? Wat zou een organisatie kunnen doen om toch ook voor deze maatregelen embedded testing te kunnen implementeren?

4.2.

Embedded testing ondanks noodzaak voor specialistische kennis?

In een eerder stadium is genoemd dat embedded testing wellicht niet toegepast kan worden bij situaties waar specialistische kennis is vereist. Echter, in theorie zou het mogelijk moeten zijn dit probleem te omzeilen of teniet te laten doen. Wat ons betreft zijn er drie factoren die embedded testing binnen beheersmaatregelen waarbij specialistische kennis vereist is, mogelijk maken. Het is alleen de vraag of gebruik maken van deze factoren zin heeft gezien de andere voorwaarde voor het invoeren van embedded testing, namelijk het feit dat het uiteindelijk wel efficiënt moet zijn om embedded testing uit te voeren in vergelijking met de traditionele wijze van het testen van beheersmaatregelen. In de komende paragrafen zullen we deze factoren behandelen. Ten eerste is er uiteraard de mogelijkheid om de betreffende persoon te trainen in de benodigde kennis. Hiernaast is het mogelijk om de beheersmaatregelen dermate concreet te formuleren dat de tester alle relevante informatie uit de beschrijving kan halen. In de derde plaats bestaat de mogelijkheid om de input die gebruikt wordt bij het uitvoeren van de beheersmaatregel en daardoor ook onderwerp is van de embedded test, te laten automatiseren. In de komende paragrafen worden deze drie opties verder uitgewerkt. Bijspijkeren van de specialistische kennis van de lijnmanager De eerste mogelijkheid is zoals gezegd dat de specialistische kennis van de lijnmanager wordt bijgespijkerd. Hierdoor is de lijnmanager in staat om met zijn expertise een oordeel te vellen over het ontwerp, de implementatie en de werking van de beheersmaatregel. Het grootste nadeel van deze mogelijkheid is dat de technologie constant verandert. De lijnmanager zal de laatste ontwikkelingen op verschillende gebieden moeten volgen. Aangezien deze meestal verantwoordelijk is voor een aantal applicaties, zal deze persoon dan ook voor alle betreffende applicaties moeten zorgen dat de kennis op het juiste niveau is. Dit maakt het continu bijhouden van technische of specialistische kennis behoorlijk tijdintensief waardoor het de vraag is of embedded testing in deze gevallen een optie is. Een gedetailleerd beschrijving van de test Een tweede mogelijkheid die er voor kan zorgen dat embedded testing toch toegepast kan worden binnen die maatregelen waarvoor specialistische kennis vereist is, is het in detail uitschrijven van de desbetreffende test. Over het algemeen zijn beheersmaatregelen redelijk algemeen omschreven waardoor een specifiek testplan nodig is om de maatregel vervolgens te testen, Door de test uit te voeren volgens de gedetailleerde stappen, is een lijnmanager in staat om een oordeel te vellen over het ontwerp, de implementatie en de werking van de beheersmaatregel. Hierbij zal dus in de beschrijving aandacht moeten zijn voor de waarden (settings) waarop moet worden gelet en specifiek ook welke waardes deze moeten hebben. Het grote nadeel van deze mogelijkheid is dat het zodanig gedetailleerd uitwerken van het controleraamwerk tijdsintensief is en door de continue ontwikkelingen ook

Pagina 24 van 29

steeds weer aangepast moet worden. Met behulp van het gedetailleerde raamwerk is een lijnmanager in staat de test uit te voeren, maar echt begrip en verstand van de technische kant van de beheersmaatregel zal de lijnmanager niet hebben. Mocht de test van de beheersmaatregel buiten het gebaande pad gaan, zal de lijnmanager niet weten wat gedaan moet worden. Ook hierbij moet een organisatie zich afvragen of het gebruik van embedded testing in dit scenario opportuun is. Het automatiseren van het testen van de beheersmaatregel De derde mogelijkheid is het automatiseren van de input die gebruikt wordt voor de beheersmaatregel en daarbij ook voor de test. Voor deze mogelijkheid is geen specifieke kennis vereist van de lijnmanager. Een voorbeeld van een geautomatiseerde beheersmaatregel is de ‘Policy Compliance’ producten die tegenwoordig op de markt zijn (bv Qualys Policy Compliance15). Indien een beheersmaatregel vereist dat de systemen zijn geïnstalleerd volgens de ‘security baseline’, is het mogelijk gebruik te maken van deze producten waarbij het programma zal testen of de systemen voldoen aan deze standaard. Op basis van de resultaten kunnen rapporten worden gedraaid, die de manager kan gebruiken om een zekerheid te krijgen over het functioneren van de beheersmaatregel. De nadelen van deze mogelijkheid zijn vooral de beperkte toepasbaarheid van dergelijke producten en het feit dat deze eerst weer geïnstalleerd en geconfigureerd moeten worden, wat uiteraard weer tijd en geld kost. Het is de vraag of embedded testing dan ook toegepast moet worden in gevallen waar deze aanvullende voorwaarden nodig zijn. Uiteraard is geen organisatie gelijk en is vooral ook het kennisniveau van de lijnmanagers binnen een IT proces niet overal gelijk. Echter, op basis van onze inschatting is het niet waarschijnlijk dat embedded testing op het gebied van de beheersmaatregelen waarvoor specialistische kennis benodigd is, een goede optie zal zijn. Het zal simpelweg niet leiden tot een efficiëntere inzet van mensen en middelen. Zoals eerder beschreven is de efficiëntere inzet van mensen en middelen juist een van de belangrijke redenen voor het gebruik maken van embedded testing.

15

Voor meer informatie: http://www.qualys.com/solutions/policy_compliance/ Pagina 25 van 29

5. Conclusie en reflectie 5.1.

Conclusie

De centrale vraag van deze scriptie luidt: wat is de potentie van embedded testing binnen de IT General Controls binnen een organisatie? Kortom, kan embedded testing worden toegepast binnen de ITGC van een organisatie? En zo ja, op welke onderdelen en met in achtneming van welke randvoorwaarden? Voordat we de centrale vraag beantwoorden, zullen we eerst de onderbouwing geven van de subvragen:




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?

Embedded testing is in feite het testen van beheersmaatregelen binnen de bedrijfsprocessen zelf. Dit verschilt van de traditionele wijze van het testen van beheersmaatregelen waarbij een externe, veelal onafhankelijke, partij de beheersmaatregelen test. Embedded testing kan worden toegepast indien het ten eerste efficiënt is om toe te passen en daarnaast indien het kennisniveau van de tester toereikend is. Om de embedded tests controleerbaar te maken voor derde partijen dienen de tests op een juiste wijze gedocumenteerd te worden. Grote voordelen voor het gebruik van embedded testing zijn de natuurlijke wijze waarop de beheersmaatregelen worden getest, het omlaag brengen van de compliancekosten, het tijdig identificeren van eventuele zwakheden in de beheersmaatregelen en het verhogen van de ‘control awareness’ van de betrokkenen. Aan het embedded testing concept kleeft echter ook een aantal nadelen waaronder het moeten herzien van de controleraamwerken, het feit dat de tests over het algemeen worden uitgevoerd oor mensen die hiervoor niet zijn opgeleid en dus de vereiste competentie op dit gebied missen en het risico dat zwakheden in de beheersmaatregelen worden genegeerd of in de doofpot worden gestopt. Ook op het gebied van de objectiviteit van de tester kunnen vraagtekens gezet worden waardoor de inzet van een onafhankelijke derde partij noodzakelijk is. Zoals we in hoofdstuk vier hebben besproken, kan embedded testing prima worden toegepast binnen de ITGC. De ITGC zijn niets meer dan vergelijkbare beheersmaatregelen uit de standaard bedrijfsprocessen maar dan nu specifiek gericht op het IT proces. Het maakt in principe geen verschil of het concept wordt toegepast binnen de bedrijfsprocessen of binnen de ITGC. Er is een aantal randvoorwaarden waaraan voldaan moet worden maar indien daar aan voldaan wordt, is er geen belemmering om het embedded testing concept toe te passen. Embedded testing kan in theorie dan ook binnen alle onderdelen van de ITGC worden toegepast, er zijn geen gebieden die zich bij voorbaat uitsluiten voor het concept. Uit onze analyse blijkt dat in de praktijk vooral de procesmatige beheersmaatregelen geschikt zijn voor het gebruik van embedded testing. De meer technische beheersmaatregelen zijn dit in mindere mate.

Pagina 26 van 29

De randvoorwaarden waar aan voldaan moet worden om embedded testing te kunnen implementeren, zijn de juiste mate van objectiviteit en de juiste competentie om de testing uit te voeren. Door de inzet van een derde partij kunnen beide randvoorwaarden gewaarborgd worden door het uitvoeren van kwaliteitsbewakingactiviteiten. De competentie van de tester kan in sommige gevallen in beginsel niet voldoende zijn, waardoor aanvullende maatregelen nodig zijn zoals het detailleren van de bestaande controleraamwerken, het automatiseren van bepaalde (technische) tests en het bijspijkeren van de technische kennis van de betreffende tester. Te allen tijde is het van belang dat de efficiëntie van de uit te voeren werkzaamheden niet uit het oog verloren wordt. Embedded testing is geen doel op zich, indien het simpelweg niet efficiënt is om het in bepaalde situaties niet te gebruiken, dan is het verstandig het testwerk op de traditionele wijze in te richten. De zojuist genoemde aanvullende maatregelen om de competentie van de tester te vergroten, kunnen er toe leiden dat het voor de daarvoor geldende beheersmaatregelen het niet efficiënt meer is om embedded testing te gaan implementeren.

5.2.

Beantwoording van de onderzoeksvraag

Het bovenstaande betekent dat wij concluderen dat embedded testing zeker potentie heeft om geïmplementeerd te worden binnen de ITGC van een organisatie. Met inachtneming van de gestelde randvoorwaarden, komen we tot de conclusie dat het concept vooral kan worden toegepast binnen die ITGC maatregelen die zich focussen op een bepaald proces, waarbij specialistische kennis niet of in mindere mate benodigd is. De gebieden waarbij deze kennis wel benodigd is, lijken voor de implementatie van embedded testing minder geschikt. Echter, het is te allen tijde van belang dat de efficiëntie van de uit te voeren werkzaamheden niet uit het oog verloren wordt. Embedded testing is hiermee ook voor ITGC een goed alternatief en zeker geen waardeloze optie!

5.3.

Reflectie

Voordat we aan het onderzoek begonnen, hadden we de verwachting dat embedded testing slechts in beperkte mate kon worden toegepast binnen de ITGC van een organisatie. Deze verwachting werd vooral veroorzaakt door de assumptie dat bepaalde ITGC te complex van aard waren om goed beoordeeld te kunnen worden in een embedded test. Tijdens ons onderzoek zijn we tot de conclusie gekomen dat embedded testing een goed concept is voor organisaties om toe te passen, ook binnen de ITGC, mits aan een aantal randvoorwaarden wordt voldaan. We hebben getracht aan te geven voor welke ITGC embedded testing het beste kan worden gebruikt, en daarmee ook welke hiervoor in mindere mate geschikt zijn. De vraag wat de toepassing van embedded testing betekent in het totale pakket aan compliance werkzaamheden is met deze thesis niet beantwoord. Hierbij valt bijvoorbeeld te denken aan de gevolgen van het gebruik van embedded testing voor het werk van de externe auditor. Kan deze hier op steunen voor haar eigen verklaring? Dit onderwerp zou in een aparte scriptie uitgewerkt kunnen worden.

Pagina 27 van 29

De zienswijze die we opgestoken hebben door het opstellen van deze scriptie zullen we in onze dagelijkse werkzaamheden uiteraard gebruiken. Het embedded testing concept wordt door verschillende klanten overwogen maar vaak hebben zij geen zicht op de implicaties van een beslissing om het concept te gaan gebruiken. Op het gebied van ITGC kunnen we hen in ieder geval van advies dienen.

Pagina 28 van 29

6. Literatuur

Boeken/publicaties Auditing Standard No. 2 – An Audit of Internal Control Over Financial Reporting Performed in Conjunction with An Audit of Financial Statements, PCAOB Release No. 2007-005, May 24, 2007 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. 2007-005, may 24, 2007 Control Objectives for Information and related Technology (COBIT), IT Governance Institute, versie 4.1, 2007 Deloitte General Computer Controls raamwerk, Deloitte, 2008 FEI Survey on Sarbanes-Oxley Section 404 Implementation; October 2005

Artikelen

Embedded testing: a cure for Sox Blues, C. Klumper & S. Geuzenbroek, www.complianceweek.com, februari 2007

Online informatiebronnen

http://www.pcaob.org http://www.sec.gov http://www.itgi.org http://www.coso.org http://www.complianceweek.com http://en.wikipedia.org/wiki/PDCA

Pagina 29 van 29