Grip op application controls

Risicomitigerende beheersingsmaatregelen waar je dagelijks handmatig geen omkijken naar hebt. Vaak aangeduid met de Angelsaksische term application controls. Ze maken een proces efficiënt en robuust. Nagenoeg elke organisatie heeft ermee te maken. In dit artikel een praktische beschouwing van het fenomeen. En hoe je ze maximaal kunt benutten voor de interne beheersing.

Het behoeft geen betoog dat de inzet van IT in het kader van een beheerste en integere bedrijfsvoering onmisbaar is. Dit geldt praktisch voor alle sectoren en typen organisaties. De bedrijfsvoering anno nu is het samenspel tussen drie componenten: menselijk gedrag, processen en IT-systemen (zie figuur 1). Voor een beheerste en integere bedrijfsvoering, ook wel interne beheersing genoemd, moet de leiding van een organisatie grip krijgen en houden over deze drie componenten. Dat is een ‘conditio qua non’ om in control te zijn.

De component menselijk gedrag is een groot onderwerp ‘an sich’. Alle wetenschappelijke literatuur over management control, ofwel gedragssturing, gaat hierover. Dit is een groot, belangrijk en boeiend domein waar ook de beroepsgroep internal auditors de laatste decennia aandacht voor heeft. Dit onderwerp valt voor dit artikel buiten scope. De tweede component is processen, het hart van elke bedrijfsvoering. Immers, de waardecreatie van de organisatie is ondenkbaar zonder (primaire en secundaire) bedrijfsprocessen. Niet voor niets is dit een belangrijk onderwerp in de curricula van diverse management- en bedrijfskundige opleidingen. Ook dit onderwerp zal in deze bijdrage buiten beschouwing blijven. Dit artikel gaat over de derde component: IT-systemen. En om nog preciezer te zijn: de application controls of geautomatiseerde beheersingsmaatregelen.

De voordelen

De voordelen of, zo je wilt, de businesscase van veel IT-systemen wordt interessant vanwege dit type controls: de risicomitigerende maatregelen die ingebouwd zijn in de applicatie (of configureerbaar zijn). Dit type controls maakt de uitvoering van een bedrijfsproces efficiënter en minder foutgevoelig. Het wordt mogelijk om een proces te standaardiseren en bepaalde business rules af te dwingen. Je kunt zeggen: het klassieke motief om de automatisering toe te passen in de bedrijfsvoering. Nog een groot voordeel van dit soort controls is: zij verhogen de datakwaliteit. Ook dit is een onderwerp van eminent belang om tal van redenen. Om maar een te noemen: betrouwbare stuurinformatie.

Deze bijdrage gaat over de wijze waarop de werking van dit type controls in het kader van interne beheersing getest kunnen worden. Eerst komt de definitie van application controls aan de orde, met de gangbare synoniemen. Daarna komt de wijze van testen aan bod.

Typen geautomatiseerde controls

Geautomatiseerde controls zijn alle beheersingsmaatregelen die door systemen of software worden uitgevoerd om de beveiliging, integriteit en vertrouwelijkheid van gegevens te waarborgen (zie figuur 2). Dit kan zowel binnen applicaties als binnen IT-infrastructuur en andere IT-omgevingen plaatsvinden. Application controls zijn ontworpen om fouten in bedrijfsprocessen te verminderen en de integriteit van gegevens te beschermen door verschillende soorten controles uit te voeren, zoals:

• input controls – zorgen voor de juiste, volledige en valide invoer van gegevens;
• throughput/processing controls – de correcte verwerking van gegevens verifiëren;
• output controls – de juiste, volledige en valide uitvoer van gegevens waarborgen.

Application controls zijn een specifieke categorie van geautomatiseerde beheersingsmaatregelen, die ingebouwd zijn in een applicatie. Dit type controls richt zich op het waarborgen van de juistheid, volledigheid en validiteit van transacties en gegevensverwerking binnen die applicatie (Bron: IT Control Objectives for Sarbanes-Oxley, ISACA, 2002).

Figuur 2 geeft het onderscheid weer tussen geautomatiseerde beheesingsmaatregelen. Onder geautomatiseerde controls vallen scripts, zoals visual basic application (VBA) of python. Of, simpel gezegd, de ‘vrije code’ in een programmeertaal die doorgaans voor een specifiek (vaak ad hoc) doel is gemaakt en buiten een applicatie functioneert. Het feit dat een VBA in Excel kan worden opgeslagen en uitgevoerd, maakt dit niet direct een application control. Het script wordt in dit geval wel in de applicatie uitgevoerd maar is niet ‘ingebakken’ in de code van de applicatie zelf. Daarom is het wel een geautomatiseerde control, maar geen application control.

Hoewel voor dergelijke scripts (in Excel/Access) ook een versiebeheer mogelijk is, wordt dit doorgaans niet toegepast. Ditzelfde geldt voor andere scripts of automatiseringen zoals python, waar versiebeheer lastig is. Om het probleem van de ongeautoriseerde wijzigingen van dergelijke scripts (code buiten een applicatie) op te lossen, is versiebeheer belangrijk. Denk hierbij aan het ondertekenen van scripts of deze in repositories met versiebeheer te plaatsen. Het zogeheten end user computing (EUC) regime moet ook gelden voor dit type code. EUC is het vermogen van eindgebruikers om hun eigen informatiesysteem te ontwerpen en implementeren met behulp van computersoftwareproducten. Denk aan Excel-sheets met kritieke formules en/of data.

Waarom is dit onderscheid relevant? Om een redelijke mate van zekerheid te kunnen geven dat een geautomatiseerde control of application control werkt, moet zeker gesteld worden dat deze niet ongeautoriseerd gewijzigd kan worden.

Application controls zijn niet zomaar betrouwbaar. Ze moeten goed getest worden, zowel technisch als functioneel

Goed testen: eerste randvoorwaarde

De application controls zijn niet zomaar betrouwbaar. Ten eerste moeten deze goed getest worden, zowel technisch als functioneel. De technische test gaat over de vraag: bevat de code geen fouten? Dergelijke testen maken doorgaans deel uit van het ontwikkelen (of wijzigen) van software. De functionele test gaat over de vraag: doet de software waar de organisatie (of business) om gevraagd heeft? Dit is de zogenaamde gebruikersacceptatietest (GAT). Als de business na een geslaagde GAT groen licht geeft, mag de software live gaan. Anders gezegd, dan mag het in productie worden genomen. Beide testen gelden generiek voor elke ontwikkelde of gewijzigde software.

Goed functioneren GITC’s: tweede randvoorwaarde

De tweede randvoorwaarde om te kunnen vertrouwen op application controls is het adequaat functioneren van de general IT controls (GITC’s). Dit zijn algemene applicatie-overstijgende/organisatorische maatregelen die waarborgen dat geautomatiseerde gegevensverwerking in applicaties betrouwbaar plaatsvindt. Denk hierbij bijvoorbeeld aan logische en fysieke toegangsbeveiliging, configuratie- en changemanagement. De lijst van GITC’s verschilt per organisatie en hangt nauw samen met de karakteristieke van het IT-landschap.

Onder deze twee randvoorwaarden is het voldoende om de werking van application controls een keer per jaar te testen. Dit wordt ook wel test of operational effectiveness genoemd. Als niet voldaan wordt aan deze twee randvoorwaarden, dan worden de application controls spreekwoordelijke drijfzand; en kan er bijna geen zekerheid gegeven worden over de beheersing van de risico’s die gemitigeerd hadden moeten worden.

Wijze van testen

Hierna volgt een toelichting op de gangbare testmethoden. Dit is dus geen volledige opsomming.

A. Uitvoeren inspectie van systeemconfiguraties
Bij deze methode worden systeeminstellingen bekeken om na te gaan of de application control goed is ingericht. Denk bijvoorbeeld aan drempelwaarden, verplichte velden of autorisatie-instellingen. Als blijkt dat de configuraties, de systeeminstellingen, correct zijn, kan gesteld worden dat een application control bestaat. Daarmee is dus de opzet en het bestaan vastgesteld. Deze testmethode zegt niets over de werking.

B. Uitvoeren walkthrough en functioneel ontwerp
Een walkthrough houdt in dat samen met de functioneel beheerder of proceseigenaren stap voor stap het proces aan de hand van een voorbeeldtransactie wordt doorgenomen. Het doel is vaststellen of het proces juist is ontworpen en waar de application control in het proces functioneert en ingrijpt. Deze testmethode is een combinatie van de testtechnieken interview en observatie ter plaatse. Deze testmethode helpt bij het doorgronden van het proces en geeft inzicht in de opzet en het bestaan van de application control. Ook deze testmethode zegt niets over de werking.

C. Inspectie van logbestanden en systeemrapportages
Deze testmethode houdt in het trekken van een sample over de controleperiode waarover het oordeel over de werking gevormd moet worden, de logs en rapportages uit het systeem. Geautomatiseerde reconciliaties en interfaces produceren vrijwel altijd enige vorm van output of logging. Bijvoorbeeld een dagelijks reconciliatierapport dat inzicht geeft in verschillen. Of een interface die per run een logregel ‘1000 records verzonden, 0 fouten’ wegschrijft. Het bestaan van zulke output toont de opzet, het bestaan en de werking van de application control aan.

D. Steunen op de gebruikersacceptatietests (GAT)
Soms kan er gesteund worden op bestaand bewijs over de werking. Zo kan het zinvol zijn om bij nieuw ingevoerde of aangepaste application controls te kijken naar of, en zo ja hoe, gebruikers de werking van de geautomatiseerde beheersmaatregel getest hebben. Een succesvol doorlopen GAT kan inzicht geven of de control in de geteste versie aanwezig was. Hierbij is het overigens wel essentieel om vast te stellen dat de in productie genomen versie niet afwijkt van de geteste versie. Mits goed uitgevoerd en vastgelegd, leveren de resultaten van een GAT met minimale aanvullende inspanning bewijs voor de opzet en het bestaan van de control. Deze methode zegt nog niets over de werking van de application control.

E. Opnieuw uitvoeren (reperformance)
Bij application controls die bijvoorbeeld data tussen twee applicaties afstemt, kunnen deze data-afstemmingen opnieuw uitgevoerd worden met dezelfde dataset. Zo kan vastgesteld worden of eventuele afwijkingen daadwerkelijk worden gesignaleerd en afgehandeld. Zo kan een onderbouwde conclusie worden getrokken over de werking.

F. Reviewen code
Deze testmethode wordt doorgaans toegepast voor geautomatiseerde control, dus code buiten applicatie. Voor het gemak noemen we dit de vrije code. In het geval van geautomatiseerde controls kan een specialist de code of (configuratie)scripts zelf reviewen. Dit geldt zeker voor complexere controls. Denk aan een aangepaste programmamodule in een ERP-systeem die specifieke controles uitvoert, maar ook bijvoorbeeld pythonscripts. In dergelijke gevallen is de analyse van de code de meest directe manier om de opzet van de geautomatiseerde control te verifiëren. Deze testmethode is erg tijdrovend en vereist technische kennis. Dit is precies de reden dat men terughoudend is met het toepassen van deze testmethode.

G. (Geautomatiseerde) test in een aparte omgeving
Als het mogelijk is, kan een application control ook getest worden buiten de productieomgeving, namelijk in een testomgeving. Door te werken met bijvoorbeeld foutieve invoer of grensgevallen kan vastgesteld worden of de control ook (onder afwijkende omstandigheden) juist blijft functioneren. Dit is een uitstekende manier om inzicht te krijgen in de opzet, het bestaan en de werking van een control.

Hoe complexer de code van een control, hoe meer gesteund moet worden op de in- en output

Welke testmethode?

Niet elke control vereist dezelfde diepgang van testing. Bij kritieke application controls is het bijvoorbeeld zinvol om meerdere testmethoden te combineren voor optimale zekerheid. Zoals eerder genoemd, is de goede werking van GITC’s essentieel. Dan kan vertrouwd worden op jaarlijks eenmalige test van application controls. Is de werking van GITC’s gebrekkig, dan zijn de application controls een stuk minder betrouwbaar. En dus moeten deze uitgebreider en vaker worden getest. Of gegevens moeten gericht worden gecontroleerd. Immers, er is meer onzekerheid over de goede werking van de control. Deze kan ongemerkt aangepast zijn, of in de praktijk omzeild worden.

Daarnaast speelt de complexiteit van de controls een rol bij de keuze van testmethode. De simpele parametrische controls (bijvoorbeeld ‘veld X verplicht’) zijn vaak afdoende te testen via review van de configuraties en een of twee voorbeeldtransacties. Dit type controls kent door hun simpelheid weinig faalmodi. Daarentegen vereisen complexe application controls (bijvoorbeeld een volledig geautomatiseerde acceptatie van een polis bij een verzekeraar) diepgaandere testen (data-analyses, testomgevingscenario’s) omdat er meerdere faalmodi mogelijk zijn. Hierbij is de vuistregel: hoe complexer de code van een control, hoe meer gesteund moet worden op de input en output. Immers, throughput, de code zelf, is te complex voor verificatie.

Niet alles kan

Niet elke methode is altijd mogelijk. Soms kun je geen testomgeving krijgen om de verschillende opties te testen. Of de (transactie)logging is niet bewaard gebleven, waardoor je de audit trail niet kunt nagaan. Een belangrijk uitgangspunt is hier dat er gekozen wordt voor het sterkst beschikbare bewijs, passend bij de complexiteit van de application control en het achterliggend risico dat de application control hoort te mitigeren. Ten slotte is het verstandig eerdere testresultaten mee te nemen in de overweging. Als de control eerder effectief gebleken is en de IT-omgeving stabiel is gebleven, kun je in een cyclus werken: het ene jaar licht testen, het andere jaar uitgebreider. Zo blijft de testinspanning in balans zonder concessies te doen aan de kwaliteit van de test.

Combineren van testtechnieken

Zoals al benoemd is het combineren van methoden vaak het best om een volledig inzicht te krijgen in de opzet, bestaan en werking van een beheersmaatregel. Louter het controleren van de instellingen bijvoorbeeld zegt niets over of de control het hele jaar gewerkt heeft (alleen dat hij kon werken). Combineer daarom bij voorkeur een test waarbij de opzet en bestaan wordt getest met methode om de werking vast te stellen.

Een voorbeeld van een dergelijke combinatie is: inspecteer de configuratie (opzet), doe een walkthroughtransactie (bestaan) en analyseer (een sample van) de output op afwijkingen. Zo krijg je een compleet beeld. In moeilijke situaties kun je compensatoire technieken inzetten. Dit wil zeggen dat als je effectiviteit niet direct kunt testen, je dan extra werk doet op opzet/bestaan plus een check op indirecte resultaten. Dit geeft minder zekerheid, maar dit is soms niet anders.