Inleiding

Kwalitatief goede IT general controls worden al jaren gezien als fundament om in de jaarrekening te kunnen steunen op geautomatiseerde informatiesystemen. Recent heeft de PCAOB Auditing Standard 2 in het kader van de Sarbanes Oxley Act nadrukkelijk aangegeven dat IT general controls een belangrijke randvoorwaarde zijn om te kunnen steunen op application controls. Het Amerikaanse IT Governance Institute heeft er zelfs een speciale Cobit-SOx guidance voor geschreven. Maar het geldt natuurlijk niet alleen voor organisaties die onder de SOx-regelgeving vallen; de regel is algemeen toepasbaar voor alle organisaties. Inmiddels weet iedere accountant dat hij alleen mag steunen op application controls (voortaan aangeduid als AC) wanneer de onderliggende IT general controls (voortaan aangeduid als ITGC) van voldoende niveau zijn.

In de PCAOB Auditing Standard 5 wordt wellicht minder expliciet gerefereerd aan de ITGC, maar in paragraaf 36 wordt vermeld ‘The auditor also should understand how IT affects the company’s flow of transactions’ en verder wordt verwezen naar de AU sec. 319, ‘Consideration of Internal Control in a Financial Statement Audit’ voor guidance voor testwerkzaamheden. Deze Amerikaanse auditing standard section 319 is al operationeel sinds 1 januari 1990! Met name de twee paragrafen 77 en 78 zijn duidelijk. Paragraaf 77: ‘In designing tests of automated controls, the auditor should consider the need to obtain evidence supporting the effective operation of controls directly related to the assertions as well as other indirect controls on which these controls depend. For example, the auditor may identify a ‘user review of an exception report of credit sales over a customer’s authorized credit limit’ as a direct control related to an assertion. In such cases, the auditor should consider the effectiveness of the user review of the report and also the controls related to the accuracy of the information in the report (for example, the general controls).’ En paragraaf 78: ‘Because of the inherent consistency of IT processing, the auditor may be able to reduce the extent of testing of an automated control. For example, a programmed application control should function consistently unless the program (including the tables, files, or other permanent data used by the program) is changed. Once the auditor determines that an automated control is functioning as intended (which could be done at the time the control is initially implemented or at some other date), the auditor should consider performing tests to determine that the control continues to function effectively. Such tests might include determining that changes to the program are not made without being subject to the appropriate program change controls, that the authorized version of the program is used for processing transactions, and that other relevant general controls are effective.’

Hieruit blijkt dat al in 1990 de relatie tussen AC en ITGC duidelijk was. Ook dichter bij huis was de relatie wel bekend. Zie bijvoorbeeld het NIVRA Studierapport 34 Normatieve maatregelen voor de geautomatiseerde gegevensverwerking in het kader van de jaarrekeningcontrole (1995), waarin ter motivatie van het testen van general controls staat: ‘Zo kan door onvoldoende scheiding tussen ontwikkel, test/acceptatie en productieomgeving onvoldoende aanwijzing bestaan voor de goede werking van de geprogrammeerde controles’, hetgeen werd geïllustreerd volgens figuur 1.

Figuur 1. Verhouding AO/IC-maatregelen buiten en binnen de geautomatiseerde gegevensverwerking ([NIVR95]).

De soorten IT controls even nader toegelicht

Het is in dit artikel niet de bedoeling sluitende definities van AC en ITGC te geven, maar voor het vervolg is het wel belangrijk enkele kenmerken van verschillende soorten IT controls te vermelden. Overigens, het hoogste niveau van IT controls wordt in dit kader ook wel aangeduid met de Entity (of Company) Level Controls (ELC). Deze ELC vormen onderdeel van de ‘controleomgeving’ en worden vaak ondersteund door het COSO-raamwerk.

Figuur 2. Relatie IT controls. [Klik hier voor grotere afbeelding]

Entity Level Controls

Entity Level Controls zijn interne beheersingsmaatregelen met name op het organisatieniveau en niet zozeer op het transactie/procesniveau, en bevatten daarom in het algemeen alle beheersingmaatregelen van het COSO-framework met uitzondering van de ‘control activities’, omdat die met name te vinden zijn op het transactie/procesniveau. Deze ELC geven een beeld van de mate waarin maatregelen zijn getroffen die een goede cultuur voor beheersing ondersteunen. Bij positieve bevindingen zal de accountant het inherente risico op het falen van het internecontrolemechanisme lager inschatten dan bij minder positieve bevindingen.

Kader 1 geeft een overzicht van de diverse IT-aandachtsgebieden in het kader van de ELC. Later in dit artikel zullen enkele voorbeelden van IT-aandachtsgebieden volgen die mogelijk geschikter zijn als onderdeel van de ELC dan van de ITGC.

Sinds de SEC-proposal ‘Management’s report on internal control over financial reporting’ van december 2006 en PCAOB’s Auditing Standard 5 – zie voor de relevante passages kader 2 – is een nieuwe discussie op gang gekomen over (indirecte) ELC en directe ELC. Deze discussie maakt duidelijk dat hoe verder een ELC af staat van een financial reporting element, hoe minder effectief de control is. En dat omgekeerd wanneer een ELC met hetzelfde niveau van precisie wordt uitgevoerd als een beheersingsmaatregel die men in processen verwacht om fouten in de financiële verantwoording te voorkomen of te detecteren, de accountant zal kunnen volstaan met het testen van de ELC in plaats van de controls in de processen. Daarmee wordt dan meer recht gedaan aan de top-downbenadering en worden naar verwachting minder detailcontroles uitgevoerd. In figuur 3 wordt dat inzichtelijk gemaakt. Volgens de PCAOB doet op dit moment de Committee of Sponsoring Organizations of the Treadway Commission (COSO) onderzoek naar deze uiteenrafeling van de ELC.

Figuur 3. Testen van directe ELC kan tot vermindering van proces level tests resulteren.

Deze splitsing van directe en indirecte ELC doet zich ook voor bij IT controls. Ook hierbij kan onderscheid worden gemaakt tussen controls die als ‘indirect’ kunnen worden aangemerkt en controls die een direct karakter hebben. Dit is al min of meer vormgegeven in indirecte controls volgens IT-aandachtsgebieden in de ELC (zie kader 1) en de ITGC waarin de directe IT controls zijn opgenomen. Echter, deze splitsing lijkt nog niet opgezet te zijn vanuit de top-downgedachte zoals die eerder is aangegeven. In het vervolg van dit artikel zal hierop worden teruggekomen.

Application controls

Voor een application control (AC) geldt dat de beheersingsmaatregel in de applicatieprogrammatuur is vastgelegd zodat de control consequent wordt uitgevoerd. In essentie betreft het vaak het berekenen en/of vergelijken van gegevens. Een berekening is strikt genomen geen beheersingsmaatregel, maar de accountant wil toch wel graag vastgesteld zien dat bijvoorbeeld de maandelijkse interestberekening goed door het systeem wordt uitgevoerd.

Veel AC blijken feitelijk IT dependent manual controls te zijn, omdat er tevens een handmatig deel in de beheersingsmaatregel is opgenomen. Denk aan een geprogrammeerde controle die een foutenlijst genereert. Natuurlijk moet de auditor zich afvragen of de lijst wel alle fouten detecteert en op de lijst afdrukt; dat is het AC-deel of het ‘IT dependent’ deel. Maar vervolgens werkt de control pas echt als ook iemand de lijst doorloopt en correctieve acties neemt; dat is het handmatige deel.

Ook werken bepaalde AC parametergestuurd. Een bekende AC als de ‘3-way match’ (geautomatiseerde maatregel die controleert of de ontvangen factuur overeenstemt met de order en ook met de ontvangen goederen of diensten) kan technisch wel werken, maar als de limieten voor kleine verschillen zeer ruim zijn gedefinieerd (parameters), dan werkt de control inhoudelijk niet. In dit artikel ga ik niet verder in op het handmatige deel van AC.

Naar hun aard kunnen AC in enkele kenmerkende categorieën worden ingedeeld (zie tabel 1).

Wanneer we kritischer naar de IT-aspecten kijken zien we vooral twee elementen terugkomen:

• geprogrammeerde instructies, dus harde coding in de applicatieprogrammatuur;
• tabellen waarop de geprogrammeerde instructies de beslissingen en/of berekeningen mede baseren (wel of geen toestemming geven, wel of niet als uitzondering classificeren, etc.).

Daarbij kunnen de geprogrammeerde instructies en tabellen direct in de applicatieprogrammatuur of applicatietabellen zijn opgenomen, maar eventueel ook in infrastructurele componenten, zoals specifieke toegangsbeveiligings- en databasesystemen. Het zal duidelijk zijn dat het onderscheid in AC noodzakelijk is om zowel de aspecten van de AC te kunnen testen (denk aan de 3-way match), alsook de scoping te kunnen doen voor de ITGC. Hierop wordt in de volgende paragraaf nader ingegaan.

Tabel 1. Application controls, voorbeelden en IT-aspecten. [Klik hier voor grotere afbeelding]

IT general controls

ITGC zijn algemene beheersingsmaatregelen met betrekking tot de IT-verwerking. Er zijn vele publicaties die de ITGC opsommen, waarvan Cobit de meest bekende is. Door PCAOB’s AS2 zijn de IT controls voor de jaarrekeningcontrole toegespitst op de vier rubrieken ‘access to programs and data’, ‘change management’, ‘program development’ en ‘operations management’. Voor een nadere aanduiding van deze rubrieken zie kader 3. Deze indeling is voor Cobit aanleiding geweest een selectie van ITGC te maken uit het volledige raamwerk en deze selectie te koppelen aan de vier rubrieken. Menig accountantskantoor heeft de ITGC-checklists aangepast aan deze vier rubrieken. Bijzonder is nu dat in de proposed SEC-standaard deze vier rubrieken onveranderd zijn opgenomen maar dat in de AS5 deze rubricering achterwege is gebleven. In AS5 wordt verwezen naar AICPA’s standaard ‘AU sec. 319, Consideration of Internal Control in a Financial Statement Audit (Paragraphs .16 through .20, .30 through .32, and .77 through .79)’, inzake het effect van IT op interne controle op de financiële verantwoording en het risico waaraan de accountant aandacht dient te besteden. Bijzonder is dat in AU319 andere rubrieken zijn opgenomen: program changes, access controls and system software controls. Ook bijzonder is dat in AS5, appendix B over benchmarking toch de rubrieken worden vermeld, maar nu als program changes, access to programs, and computer operations. Het is even afwachten hoe de internationale IT-auditstandaarden, zoals SOx-Cobit, hierop zullen reageren.

Het aanduiden van de rubrieken lijkt een woordenspel te zijn, in de praktijk echter lijkt het voldoen aan de onderliggende normenstelsels, zoals (Cobit) IT Control Objectives for SOX van het IT Governance Institute en de checklists van de accountantskantoren, bijna een doel op zich te zijn geworden. De relatie naar de verschillende AC lijkt dan uit het zicht verdwenen.

Scoping van de ITGC

Zoals eerder is aangegeven, hoort de scoping van ITGC plaats te vinden op basis van application controls waarop de auditor wil steunen. Veelal worden daarvoor IT-identificatiematrices gehanteerd zoals weergegeven in de tabellen 2 en 3.

Tabel 2. IT-identificatiematrix aan de gebruikerskant (processen).

Tabel 3. IT-identificatiematrix aan de IT-kant (infrastructuur) voor scoping ITGC.

De relatie tussen de specifieke AC en de beheersingsmaatregelen is in tabel 3 voor de IT verdwenen en dus worden alle ITGC voor de van toepassing zijnde infrastructuur en locatie geselecteerd en getest (zie kader 3).

Daarmee is een risico voor een belangrijke inefficiency geschapen wanneer we vaststellen wat veelal getest wordt in het kader van de ITGC. Door eenvoudig te stellen dat het beoordelen van de ITGC noodzakelijk is voor bieden van redelijke zekerheid voor de werking van de AC doet de auditor waarschijnlijk tests die geen bijdrage leveren aan de onderbouwing van het goed functioneren van de laatstgenoemde controls.

ITGC-deficiencies relateren aan AC

Stel nu het volgende voorbeeld:

De accountant wenst te steunen op de AC 3-way match, mede in het kader van de beoordeling van de rekening Debiteuren. Het systeem controleert daarbij of de factuur aansluit op de in het systeem vastgelegde bestelling en ontvangstmelding van goederen of geleverde diensten. Daarop test de accountant of de AC goed is geïmplementeerd. Daartoe wordt bijvoorbeeld een interview gedaan met de systeemeigenaar, is aan de hand van enkele facturen vastgesteld dat het systeem de controle heeft uitgevoerd en zijn de tolerantiegrenzen in de tabel in het systeem beoordeeld. Op basis daarvan heeft de accountant vastgesteld dat de AC effectief is. Om vervolgens voldoende zekerheid te krijgen dat deze control ook in de tijd effectief is vraagt hij de IT-auditor de ITGC te beoordelen. Stel dat de IT-auditor vaststelt dat de 25 medewerkers van de afdeling Systeemontwikkeling allemaal de mogelijkheid hebben programma’s in de productiebibliotheek te zetten. De IT-auditor concludeert daarom dat change management niet effectief is (zie kader 3: change management, tweede bullet) ofwel dat er onvoldoende bewijs is om aan te nemen dat de geprogrammeerde controles ongewijzigd zijn gebleven.

De relatie tussen ontoereikende change management en de werking van de 3-way match is door de IT-auditor aan de accountant goed uit te leggen en gezamenlijk kunnen zij naar alternatieve controles zoeken om de tekortkomingen in change management te compenseren. Te denken valt aan bijvoorbeeld beoordeling van de logging van de productiebibliotheek waaruit zou kunnen blijken dat geen changes zijn aangebracht in de onderzochte periode. In dat geval kan de accountant toch steunen op de AC. Mocht er geen additionele zekerheid vanuit de IT-auditor komen, dan zal de accountant alternatieven zoeken om de controledoelstelling te halen. Bijvoorbeeld door via auditsoftware alsnog de 3-way match uit te voeren of via een uitgebreide steekproef de correcte boeking van de factuur te beoordelen.

Het bepalen welke alternatieve controles het meest efficiënt en effectief zijn gebeurt natuurlijk op basis van een risicoafweging vanuit de invalshoek van de accountant.

Maar hoe zal het overleg met de accountant gaan wanneer de IT-auditor bij de beoordeling van de ITGC vaststelt dat de fysieke beveiliging van het rekencentrum niet toereikend is (zie kader 3: access to programs and data, tweede bullet). Welk risico is er dat onbevoegde bezoekers in het rekencentrum precies weten welke databases op welke schijven staan en hoe vervolgens de 3-way match voor een bepaalde factuur kan worden gemanipuleerd? Overigens er dan nog van uitgaande dat dat niet wordt gesignaleerd via een control op de logging. Kortom, de relatie tussen fysieke beveiliging en een specifieke AC is meestal niet zodanig dat de werking van de AC zal worden beïnvloed, of de fysieke beveiliging nu effectief is of niet. En als dat zo is dan doet zich de vraag voor waarom de auditor dan de fysieke beveiliging heeft getest. En deze vraag speelt niet alleen bij fysieke beveiliging maar bij bijna alle onderwerpen van program development en operations (zie kader 3, rubrieken 3 en 4). En zelfs per AC zijn meestal niet alle controls binnen access to programs and data en change management (zie kader 3, rubrieken 1 en 2) relevant.

Voor bovenstaande voorbeelden kan de vraag worden gesteld of de IT-auditor vaker de invalshoek van de accountant moet volgen: het gaat er niet zozeer om of ergens in de IT-processen ingegrepen zou kunnen worden, maar wat de impact daarvan zou zijn op de jaarrekening. Door direct ook de materialiteit in ogenschouw te nemen, hoe moeilijk ook bij ITGC, zal een flink aantal mogelijke tekortkomingen kunnen worden afgedaan met een constatering dat de impact te laag is om verder te worden gecompenseerd via bijvoorbeeld alternatieve controles.

Door de IT-auditor dient per AC te worden nagegaan welke ITGC een directe relatie hebben tot die AC. ITGC die geen directe relatie hebben met de bewuste AC dienen dan dus niet op goede werking te worden beoordeeld. Alleen op basis van een deugdelijke selectie kan zinvol invulling worden gegeven aan de discussie wat te doen als er deficiencies worden gevonden. En natuurlijk wordt voorkomen dat ITGC worden beoordeeld die voor de AC niet relevant zijn.

Om dit te ondersteunen dient de IT-identificatiematrix (tabellen 2 en 3) dan ook te worden gecombineerd en aangepast volgens tabel 4. In deze matrix kan concreet worden aangegeven welke ITGC daadwerkelijk relevant zijn en dus ook welke niet.

Tabel 4. Verbeterde IT-identificatiematrix voor scoping ITGC. [Klik hier voor grotere afbeelding]

Dat wil natuurlijk niet zeggen dat de andere ITGC in het geheel niet meer relevant zijn, maar niet in detail voor deze control. Sommige ITGC zullen relevant zijn voor andere AC en sommige zullen nooit geraakt worden. Met name voor de categorieën Program development en Operations zal dat laatste van toepassing zijn. De auditor zal dat via een inventarisatie moeten vaststellen. Indien bijvoorbeeld nog veel batchverwerking plaatsvindt en door de IT-operators nog batchtotalen worden vergeleken om vast te stellen of alle bestanden in de verwerking zijn meegenomen, kan het zinvol zijn de uitvoering van de IT-operators te beoordelen, zeker als het risico groot is dat bepaalde invoerbestanden mogelijk anders niet verwerkt worden.

Hiermee is niet gezegd dat de auditor geen aandacht aan die controls zou hoeven geven. Natuurlijk zal het ontbreken van een ontwikkelingsmethodiek voor applicatieprogrammatuur niet bijdragen aan goed onderhoudbare systemen en zal het ontbreken van een incident-managementprocedure het tijdig herstellen van fouten niet ten goede komen. Hier gaat de vergelijking op met de ELC. Daar is beschreven hoe nu onderscheid gemaakt gaat worden tussen directe en indirecte ELC. Feitelijk staan in de ELC al enkele indirecte IT controls (zie kader 1) en kunnen de ITGC worden gezien als een verbijzondering van de directe ELC. Echter, uit het bovenstaande blijkt dat sommige ITGC toch niet zo’n directe relatie met de AC hebben en dus feitelijk misplaatst zijn in de ITGC. In analogie met de ELC geldt voor de directe ITGC de in figuur 4 weergegeven situatie.

Figuur 4. Testen van directe ITGC kan tot vermindering van proces level tests resulteren.

Daarom zou de auditor dergelijke indirecte ITGC niet meer onder de standaard-ITGC moeten plaatsen, maar onder de ELC of in een aparte ‘indirecte ITGC’-rubriek. De indirecte ITCG geven een beeld van de kwaliteit van de IT-organisatie en zijn in die zin mede input voor te onderkennen risico’s in het kader van de controleaanpak of het vaststellen van de hoogte van de steekproefomvang bij het toetsen op de werking van ITGC. Daarnaast dekken de indirecte ITGC, samen met de directe ITGC, de behoefte van de accountant af om tijdig het management te waarschuwen voor risico’s als gevolg van zwakheden in de IT-omgeving. Denk bijvoorbeeld aan het ontbreken van een beveiligingsbeleid of aan ontoereikende back-up- en recoveryprocedures, die in het algemeen weinig of niet zullen bijdragen aan de voortdurende goede werking van AC. Een praktische uitwerking hiervan is het beoordelen van alle ITGC in opzet en bestaan (net zoals geldt voor de indirecte ELC) en voor de werking uitsluitend die ITGC te selecteren die daadwerkelijk een directe relatie met de AC hebben.

In figuur 5 is dat nog eens weergegeven.

Figuur 5. Aanpak accountantscontrole waarbij de werking van de directe ITGC apart wordt getest.

Conclusie

In het kader van de jaarrekeningcontrole staat de beoordeling van de IT general controls niet op zichzelf. De bevindingen moeten bijdragen tot bevindingen met betrekking tot de financiële verantwoording, in het algemeen verwoord met het bieden van waarborgen van de voortdurend goede werking van de application controls in de financiële processen. Maar die relatie is niet altijd makkelijk, in een aantal gevallen zelfs vrijwel niet te leggen. Deze IT general controls worden sinds ze in vier categorieën door de PCAOB zijn aangeduid, algemeen herkend en ook het IT Governance Institute heeft een op Cobit gebaseerd ITGC-overzicht voor SOx geschreven, rekening houdend met die vier categorieën. In de praktijk worden vaak alle controls in alle vier categorieën beoordeeld zodra een application control is onderkend.

In de praktijk blijkt dat voor sommige IT general controls er geen directe link is te leggen met welke application control dan ook, met name in de onderdelen Program development en Operations. Het is dan ook niet effectief en niet efficiënt deze (indirecte) ITGC nog uitgebreid te testen ten behoeve van de jaarrekeningcontrole, inclusief SOx-integrated audit. Wel kunnen dergelijke controls bijdragen tot een beeld van de ‘control environment’ en daarmee van invloed zijn op de controleaanpak en de omvang van de tests op de werking van de ITGC. Deze zullen in analogie met de Entity Level Controls moeten worden onderscheiden in directe en indirecte ITGC. Voor het beeld dat de indirecte ITGC geven zullen zij alleen in opzet en bestaan worden getest, maar behoeven zij vervolgens niet op werking te worden getoetst. Voor de directe ITGC is die toets op de goede werking natuurlijk wel essentieel.