De (on)zin van database beveiliging bij beoordeling betrouwbaarheid lijstwerk

Een herkenbare opmerking uit de kwaliteitsonderzoeken van de AFM: de externe accountant heeft geen of onvoldoende werkzaamheden uitgevoerd om de general IT controls en application controls te beoordelen terwijl hij wel volledig steunt op de informatie en het lijstwerk. De opmerking is in feite een waarschuwing. En de duiveltjes zitten hier in de details.

De AFM voert kwaliteitsonderzoeken uit op wettelijke controles bij accountantskantoren. Het kwaliteitsonderzoek richt zich ook op de mate waarin de accountant aandacht heeft besteed aan de General IT Controls. General IT controls zijn interne beheersingsmaatregelen met betrekking tot de geautomatiseerde gegevensverwerking en dienen de betrouwbare werking van deze geautomatiseerde gegevensverwerking te waarborgen. Een herkenbare opmerking uit de kwaliteitsonderzoeken van de AFM betreft dat de externe accountant geen of onvoldoende werkzaamheden heeft uitgevoerd om de general IT controls en application controls te beoordelen terwijl hij wel volledig steunt op de informatie en het lijstwerk. Lijstwerk betreft hierbij de voor de accountantscontrole relevante output uit applicaties. Denk hierbij aan een ouderdomsanalyse debiteuren ten behoeve van het bepalen van de voorziening debiteuren of een overzicht met prijzen per artikel ter controle van de juistheid van de prijzen.

Een van de general IT controls betreft de database beveiliging van applicaties De database beveiliging van een applicatie kan effect hebben voor de betrouwbaarheid van het lijstwerk. Mijn inziens wordt database beveiliging op een onjuiste wijze betrokken bij de accountantscontrole waardoor verkeerde conclusies omtrent de betrouwbaarheid van lijstwerk worden getrokken.

Om de (on)zin van database beveiliging bij beoordeling van de betrouwbaarheid van het lijstwerk bij een accountantscontrole te kunnen bepalen zal een accountant moeten starten met een adequate inventarisatie van de IT en de database beveiliging. Inventarisatie is noodzakelijk om minimaal vast te stellen welke risico’s voor de betrouwbaarheid van het lijstwerk aanwezig zijn. Vervolgens dient men rekening te houden met de waarschijnlijkheid van manipulatie van de database: bijvoorbeeld in hoeverre kan iemand ongeautoriseerde prijzen in verkoopfacturen wijzigen? Feit is dat bij wijzigingen rechtstreeks in de database de interne beheersingsmaatregelen in de applicatie (application controls) mogelijkerwijs worden omzeild. Denk bij application controls aan geïmplementeerde functiescheidingen aan de hand van autorisatietabellen in de applicatie.

Uiteraard zijn er risico’s te bedenken maar deze dienen wel in het juiste kader te worden geplaatst. Ondeskundige manipulatie van een database heeft gevolgen voor de database-integriteit: mismatch tussen diverse verbanden. Deskundige manipulatie kan behoorlijk wat deskundige arbeid vergen, het is daarom niet altijd waarschijnlijk.

Op basis van de inventarisatie en de risico-analyse kan de accountant uiteindelijk komen tot het uitvoeren van de juiste werkzaamheden om de database beveiliging te beoordelen waardoor hij een juiste conclusie kan trekken of hij kan steunen op het lijstwerk.

Introductie database

De huidige applicaties maken tegenwoordig meestal gebruik van een database waarin alle data centraal wordt opgeslagen. Als een gebruiker van een applicatie zoals SAP B1 de prijs van een product wijzigt, dan zal deze wijziging worden doorgevoerd in de onderliggende database in de tabel ’prijzen’.

 

 

Niet iedere gebruiker zal prijswijzigingen mogen doorvoeren. In de applicatie worden gebruikers aangemaakt. Deze gebruikers krijgen, eventueel via rollen/groepen, autorisaties. Zo wordt bepaald welke gebruikers prijzen mogen wijzigen.

In sommige gevallen beschikt een applicatie over een adequate audit trail waardoor achteraf inzichtelijk is welke wijzigingen in de autorisaties hebben plaatsgevonden. Op die audit trail moet dan gedocumenteerde interne beheersing zijn toegepast om vast te stellen dat autorisaties conform de vereisten werken.

Na te zijn opgeslagen in de tabel ‘prijzen’ in de database worden er transacties uitgevoerd door medewerkers die daar dan weer de autorisatie voor hebben. Die transacties worden weggeschreven in de database in de tabel ‘factuurdetails’.

Toegang tot de tabellen ‘factuurdetails’ en ‘prijzen’ in de MS SQL database worden op een ander niveau dan de applicatie geregeld, namelijk op de database server. Een gebruiker kan toegang krijgen via specifieke tools.

 

Eens per week, maand of verslagperiode is het vervolgens voor een gebruiker belangrijk om te weten wat de inhoud is van een dergelijke database. Dan wordt een rapport gedraaid, in reviewverslagen ook wel ‘lijstwerk’ genoemd. Dat ‘lijstwerk’ is meestal een algoritme, een commando dat informatie uit de database pakt en die op een voorgeprogrammeerde plaats op een overzicht zet. Een voorbeeld is een overzicht met prijzen per artikel ter controle van de juistheid van de prijzen.

Mogelijke consequenties voor de controle

In reviewverslagen van accountantsdossier door bijvoorbeeld toezichthouders of compliance officers zie ik terugkomen dat er opmerkingen worden gemaakt over de ‘betrouwbaarheid van het lijstwerk’. Deze formulering is van een geaggregeerd niveau en valt uiteen in een aantal deelrisico’s:

1. Iemand met een onjuiste autorisatie voert een prijswijziging door of voert een transactie uit. Dit betekent dat er een transactie tot stand komt buiten de gewenste bandbreedtes. Die transactie wordt vervolgens weggeschreven naar de database in de tabel ‘factuurdetails’.
2. Na opname in de tabel ‘factuurdetails’ benadert iemand direct de database en muteert die gegevens. Daarbij dient men rekening te houden met het steeds verdergaand “openzetten” van databases ten behoeve van diverse doeleinden zoals management information tools waarbij medewerkers op een andere wijze dan via de applicatie zelf toegang hebben tot de database.
3. Bij het ophalen uit de database is het algoritme waarmee de gegevens worden gepresenteerd onjuist.

Ad 1) Onjuiste autorisaties

Ten aanzien van het risico op onjuiste autorisaties geldt, dat onjuiste functiescheiding vaak geen relatie heeft met de traceerbaarheid van een transactie. De functiescheiding in de applicatie regelt alleen de transactie zelf, niet de registratie ervan. Ontbreken van adequate functiescheiding in de applicatie gaat dan niet noodzakelijkerwijs ten koste van de controleerbaarheid achteraf.

Ad 2) Mutaties in database
Ten aanzien van het risico op ongeautoriseerde mutaties in de database geldt dat dit vaak wel kan, maar technisch bijzonder complex is. Manipulatie van een database vergt:

• kennis van het datamodel;
• kennis van commando’s om mutaties te kunnen uitvoeren;
• de juiste toegang tot de databases.

Bovendien is een database dusdanig complex dat het muteren van een bestaand record vaak de relatie verstoort met een controlegetal in een andere tabel (van de soms duizenden tabellen).  Zo zal een geboekte factuur waarvan de prijs is gemanipuleerd een mismatch vertonen met:

• openstaand bedrag in de tabel debiteurenposten;
• verkoopbedrag in de tabel goederentransactie;
• BTW-bedrag in tabel BTW-posten

Daarnaast bestaat de mogelijkheid om gegevens te verwijderen uit een database, bijvoorbeeld een log regel (registratie van een wijziging in autorisaties) of een transactie regel, bijvoorbeeld factuurdetail. Voor wat betreft het verwijderen van een transactie: hierbij moet specifieke kennis aanwezig zijn om te weten in welke andere tabellen dan ook regels verwijderd moeten worden (zie voorbeeld eerder).

Manipulatie van transacties in een database met onvoldoende kennis van het datamodel zal resulteren in gevolgen voor de integriteit van de database zoals het niet sluiten van bijvoorbeeld een openstaande debiteurenpost met het saldo op grootboekkaart Debiteuren. In het ergste geval kan ondeskundige manipulatie resulteren in het niet meer in balans zijn van het grootboek. Daarnaast hanteert een beetje volwassen database een oplopend nummering (recordID). Let op, een recordID is iets anders dan een factuurnummer! Het verwijderen van een regel zal opvallen aangezien er een “gap” ontstaat in de oplopende nummeringen. Een beetje slimme beheerder zal dit weten, maar zal zich ook realiseren dat het omnummeren (handmatig) een behoorlijke klus kan zijn.

Ad 3) Manipulatie query lijstwerk

Ten aanzien van het risico op manipulatie van de query van lijstwerk geldt dat het bij standaard lijstwerken in generieke pakketten vrijwel alleen mis kan gaan bij instelling van het lijstwerk. Bij een instelling kun je denken aan een datumafbakening. De code waarmee de informatie wordt opgehaald is veelal simpel en de broncode om het lijstwerk te manipuleren is vaak niet bij de cliënt beschikbaar. Risicovol wordt deze laatste stap eigenlijk voornamelijk bij datawarehouses die naast de productieapplicaties draaien en waaruit vervolgens met eigen queries overzichten worden gemaakt of bij maatwerk omgevingen met “op maat gemaakte” lijswerken.

Werkprogramma accountant

Autorisaties. Vaak constateert een IT auditor dat de audit trail van wijzigingen niet betrouwbaar is, of de accountant constateert dat de wijzigingen in autorisaties niet door interne beheersing zijn gedekt. In dat geval moet de accountant dus nadenken over wat medewerkers met onjuiste autorisaties zouden gaan doen. Welke prikkel hebben ze en welke gelegenheid bieden de te ruimte autorisatie. Op basis van die afweging kan een accountant vervolgens gericht op zoek gaan naar transacties waar dat van toepassing lijkt te zijn in de database met gegevens.

Databasemutaties. Gebruikers van een systeem hebben vrijwel nooit direct toegang tot de database of zijn niet voldoende ge-equipeert om rechtstreeks in een database te muteren. Degene die dat vaak wel is, is vaak dezelfde persoon die de logging van directe mutaties in de database weet uit te zetten. Uiteraard dient het toekennen van toegang tot de database op een dusdanige wijze te gebeuren dat deze medewerkers alleen die autorisaties hebben die strikt noodzakelijk zijn.

 

Mutaties van gegevens is echter niet gelijk aan verwijderen. De gegevens zijn nog wel opgenomen in de database. Manipulatie zou dan kunnen worden onderkend door gegevensgerichte werkzaamheden op de gegevens opgenomen in lijstwerken.

Het verwijderen van gegevens is niet altijd te onderkennen door gegevensgerichte werkzaamheden, niet ieder systeem houdt onder water Record ID’s bij.

Als een team van oordeel is dat verwijderen van records door de Databasebeheerder (in opdracht van de leiding van de huishouding) waarschijnlijk is, dan zijn gegevensgerichte werkzaamheden moeilijk. Het moet dan al mogelijk zijn om vanuit een andere gegevensbron (bijvoorbeeld de bank) een integrale afstemming te maken om te zoeken naar de verwijderde transacties. En anders is het niet te detecteren. Sommige versies van databases ondersteunen het loggen van database wijzigingen. Deze logging zal veelal niet ingericht zijn, naast het feit dat de inrichting van een logging de nodige expertise vereist.

De lijst zelf

Ten aanzien van de lijst zelf zouden de werkzaamheden van de accountant ten minste aandacht moeten besteden aan de opbouw en de oorsprong van een lijst. Is het een standaard lijstwerk uit een gekochte applicatie of is het een management information toepassing die put uit een datawarehouse dat naast de operationele database wordt gebruikt voor sneller rapporteren. In het geval dat het een standaard lijst betreft zouden werkzaamheden beperkt kunnen blijven tot het vaststellen dat de juiste peildatum of periode is gekozen in combinatie met het vaststellen dat sprake is van release beheer rondom wijzigingen. In het geval dat het een management information toepassing betreft dienen de werkzaamheden uitgebreid te worden met het maken van een totaalaansluiting tussen het datawarehouse en het operationele systeem in combinatie met het lezen van de code van de query.

Afsluitend

Met dit artikel wil ik een richting aangeven hoe de accountant databasebeveiliging dient te betrekken bij de accountantscontrole en hoe de accountant het effect van de bevindingen op de betrouwbaarheid van het lijstwerk kan bepalen.

Robert Johan is register EDP-auditor en directeur bij Soll-IT. Hij ondersteunt accountantskantoren in het op de juiste wijze betrekken van de automatisering van organisaties in het controleren van de jaarrekening. Met dank aan Tom Koning die het onderwerp bij Robert Johan heeft aangedragen hetgeen uiteindelijk heeft geresulteerd in dit artikel. 

Voldoe aan de standaarden bij een MKB controle: integreer IT audit in de controleaanpak!

De tijd dat de klassieke accountant en IT auditor langs elkaar werkten is al enkele jaren voorbij. De vergaande automatisering in het MKB heeft ertoe geleid dat een groot gedeelte van de interne controle is geautomatiseerd en dat controles buiten het systeem om gewoon niet meer kunnen. Als een accountant een controle volgens de standaarden wil uitvoeren en de aanwijzingen van de AFM, moet de IT bij de controle op de eerste plaats worden gezet gedurende de hele controle: IT First dus.

Maar IT First is meer dan alleen voldoen aan standaarden. IT First helpt een accountant ook tot het geven van meer toegevoegde waarde en begrip voor de controlewerkzaamheden (en de kosten hiervan). 

Onder begeleiding van SOLL-IT heeft Horlings Accountants in Amsterdam een aantal jaren geleden IT First ingevoerd. Mede door IT FIRST, is Horlings Accountants beloond in de review door het SRA (namens AFM  met) in het najaar van 2014 met een 1 (goed).  In deze editie beschrijven we de hoofdlijnen van IT FIRST. In de komende edities wordt steeds een onderdeel van de IT First controleaanpak uitgediept.  

Traditionele controle
Anno 2015 mag men aannemen dat de tijd voorbij is dat het controleteam voor een interim controle naar de klant gaat, zonder een goed controleplan. Echter als een IT auditor wordt ingezet, dreigt het gevaar dat er geen of onvoldoende aansluiting is tussen het audit team en de IT auditor. Naast het controleplan moet nog even “de sectie automatisering” in het dossier worden afgewerkt. Gevolg: een onjuiste controle, inefficiënte controle of onjuiste controleverklaring.

Klassiek voorbeeld hoe dit (verkeerd) uitwerkt is de passage in het accountantsverslag over de betrouwbaarheid en continuïteit van de geautomatiseerde gegevensverwerking. De IT auditor levert hier een tekst voor aan en stelt dat het password beleid inadequaat is. Deze constatering heeft verder geen gevolgen gehad voor de controle of controleverklaring (zie kader).

 

KADER
Het straffeloos “om het systeem heen controleren” bij een ERP/IT systeem waarbij het password beleid (authenticatie) niet goed is geregeld zal in veel gevallen dienen te leiden tot een aanpassing van de controleverklaring. Authenticatie is namelijk een onvervangbare maatregel van interne controle. Achteraf is veelal niet meer vast te stellen of de functiescheiding heeft gewerkt. Hoe kunt u vaststellen dat, indien ook papieren sporen ontbreken, dat bijvoorbeeld de magazijnmeester een ontvangst heeft ingevoerd, indien de administrateur ook zijn password kent.

Minder erg is als de autorisaties niet goed zijn ingesteld, maar er wel sprake is van een goede authenticatie. Met IT audit software kan er dan achteraf veelal worden vastgesteld wie wat heeft gedaan in het systeem en welke gevolgen dit zou moeten hebben voor de controle cq controleverklaring.

 

IT in de controle is nog steeds een ondergeschoven kindje en wordt teveel gezien als een separaat onderdeel, het afwerken van een checklist. Het huidige aanbod aan controle software probeert accountantskantoren in het MKB ondersteuning te geven door het aanbieden van diverse checklisten en integratie in de controle. Onvoldoende kennis van IT, de klant en het niet adequaat toepassen van de controle software resulteert veelal in onvoldoende en/of onjuiste vastleggingen en integratie van IT in de controleaanpak en -werkzaamheden.

Dit kan resulteren in het steunen op data van IT terwijl er onvoldoende IT werkzaamheden zijn uitgevoerd om vast te stellen of de betrouwbaarheid van deze data voldoende is gewaarborgd. Daarnaast worden IT audit risico’s over het hoofd gezien. 

Als er een IT Auditor wordt ingezet, zijn de uitkomsten hiervan, zonder goede communicatie met het controleteam, te weinig gericht op audit risks, maar te veel op business risks. De vertaling naar de jaarrekening controle is hierdoor moeilijk te maken. De klassieke edp auditor en accountant spreken niet dezelfde taal en de accountant kan de bevindingen niet vertalen naar de controle.

Om een efficiente en slimme controle uit te kunnen voeren zal de moderne IT auditor de klant beter moeten begrijpen en denken vanuit de audit risks. De klassieke accountant dient de overstap te maken naar een IT first audit, waarbij op de risico’s in de interne controle van het IT systeem van de cliënt de eerste focus wordt gelegd, en de daaraan gerelateerde audit risks worden vertaald naar de controle aanpak. De IT first accountant neemt de stap om te kunnen steunen op IT en durft dan ook traditionele werkzaamheden los te laten, gewoon niet meer uit te voeren dus.

Een IT first controle aanpak
In wezen is een IT first controle aanpak eenvoudig. Voor het mitigeren van audit risico’s maakt de accountant gebruik van de interne controles die de cliënt zelf uitvoert. Een belangrijk verschil met klassieke controles is echter dat iedere controle met IT zal starten, omdat de meeste interne controles bij de client in het MKB zijn geautomatiseerd en de meeste risico’s voortkomen uit de interne controles.

De controle start dus met een IT auditor die de IT inventariseert en de mate waarin de IT een rol heeft in de interne beheersing. Dit doet de IT auditor met de bril van de accountant op. Vanuit de deskundigheid van de IT auditor worden de risico’s in kaart gebracht samenhangend met het feit dat er geautomatiseerd is.

In dit stadium dient er tevens aandacht te worden besteed aan de opzet van general IT controls. Voor veel accountants is dit “een ver van mijn bed show”. Helaas, want de cliënt loopt namelijk veel meer risico (business risk) indien het systeem toegankelijk is via het Internet. De accountant kan hier niet omheen, omdat hierdoor ook de risico’s voor de jaarrekening (audit risk) steeds groter worden.

KADER
Waar voorheen een muur werd opgetrokken tussen de interne systemen en het Internet zien we dat deze muur steeds verder in het MKB wordt afgebrokkeld. Immers: systemen tussen onder andere afnemers, leveranciers en andere relaties worden steeds meer met elkaar gekoppeld. Daarnaast geven organisaties derden meer toegang tot hun systemen via het Internet om bijvoorbeeld de status van een order te kunnen volgen.

Consequentie: er ontstaan meer mogelijkheden voor kwaadwillenden om toegang te krijgen tot de systemen van een MKB organisatie. Je kunt je afvragen in hoeverre dit een business risk is, laat staan een audit risk. Veelal wordt dit door de ondernemer zelf afgedaan met de opmerking: “bij ons valt toch niets te halen” of “ik vind het niet erg als mijn prijzen bekend zijn bij de concurrenten”.

Echter, er is wel degelijk heel veel te halen bij slecht beveiligde systemen, zeker voor wat het criminele internet circuit betreft. Immers, voor spammers is een slecht beveiligde (web)mailserver prachtig, voor het aanvallen van andere systemen is het ideaal om slecht beveiligde systemen te misbruiken zodat alle sporen daarheen leiden. Er wordt naarstig gezocht naar slecht beveiligde systemen voor het plaatsen en distribueren van illegale foto’s, video’s en software of voor het misbruiken van IT systemen of data van organisaties. Net als inbrekers op zoek zijn naar slecht beveiligde huizen.

Consequentie voor de organisatie kunnen dan al snel zijn:

• het afsluiten van de Internet verbinding door de provider: vervelend als een groot deel van de omzet van de cliënt afkomstig is van de website.
• imagoschade door het publiceren van misbruik van de eigen systemen
• claims als gevolg van het beschadigen van systemen van derden via de eigen systemen
• misbruik van privacy gevoelige gegevens
• schade als gevolg van een slecht beveiligde webapplicatie.

De cliënt zou zich hierbij wel eens wat onzekerder gaan schuiven op zijn stoel (business risk) en de accountant kan zich afvragen of dit materiële gevolgen (claims, afbreukrisico) of zelfs continuïteitsrisico’s kan hebben voor de organisatie (audit risks).

 

Bovenstaande zaken zijn uiteindelijk initieel heel eenvoudig vast te stellen door inzet van geautomatiseerde tools waarbij snel inzicht wordt verkregen in de beveiliging van de Internetkoppeling.

Een praktische inventarisatie in het MKB moet bestaan uit een overzicht van:

• De IT systemen en de samenhang met de voor de audit relevante processen.
• De geautomatiseerde interne beheersingsmaatregelen in de processen.
• De risico’s voortkomend uit de automatisering.

Het doel van de IT inventarisatie is om inzicht te krijgen in:

• de IT om te kunnen bepalen of er in opzet sprake is van voldoende interne beheersing om te kunnen steunen op de IT;
• IT risico’s die eventueel audit risico’s kunnen zijn;
• de mogelijkheden voor het uitvoeren van gegevensgerichte werkzaamheden door inzet van data-analyse of andere tools.

 

Na de inventarisatie van de IT auditor vindt er overleg plaats met de accountant: overleg over audit (inclusief IT) risico’s en de aanwezige geautomatiseerde interne controles. Samen bepalen zij verder het controleplan. Heel belangrijk is het om vast te stellen wat er met IT wordt gedaan en wat er dus niet (meer) handmatig wordt gedaan. Hier zit met name de angst bij de traditionele accountant: niet meer gegevensgericht controleren en vertrouwen op de application controls (fysiek iets vinken of vastpakken kan immers niet meer).

Deze (IT first) aanpak is overigens in lijn met de voorschriften van de standaarden. Standaard 315.12 schrijft voor dat de relevante interne beheersingsmaatregelen onderzocht dienen te worden. Ook schrijven de standaarden (st. 330.8) dat de accountant toetsingen van de interne beheersingsmaatregelen dient op te zetten en uit te voeren als de accountant voornemens is gebruik te maken van deze maatregelen (omdat dat efficiënter is) of omdat de accountant dit niet op een andere manier kan controleren. Als onderneming hoog is geautomatiseerd en de er weinig sporen van interne beheersing buiten het systeem zijn, hoe kan de accountant dan nog een controle doen buiten het systeem om en zich houden aan de standaarden?

De AFM meldt in het kader van de controle van de volledigheid van de opbrengsten bovendien nog eens dat de accountant van goede huize moet komen om te kunnen onderbouwen dat dit niet systeemgericht is vastgesteld. Als een onderneming dus hoog is geautomatiseerd, kunt u dus alleen de opbrengsten op volledigheid controleren als u aandacht besteed aan de applicationcontrols in het systeem. En applicationcontrols kunnen niet goed werken, zonder adequate general IT controls.

Het verdient de voorkeur om het controleplan te bespreken met de cliënt. Indien IT geen grote rol heeft in de beheersing, blijkt meteen de grote toegevoegde waarde van de aanpak, want 95% van de ondernemingen zou gebaat zijn bij de inzet van IT bij interne controles. Een goed advies moment dus. Maar ook meteen begrip voor de werkzaamheden van de accountant en de kosten van de controle. Immers, indien er niet adequaat is geautomatiseerd dient er een klassieke controle plaats te vinden en zal er om het systeem heen gecontroleerd moeten worden (indien mogelijk). Indien de onderneming wel goed is geautomatiseerd, zal de controle efficiënt uitgevoerd kunnen worden: een beloning voor de inspanningen van de onderneming.

Op basis van het controleplan worden systeemgerichte werkzaamheden uitgevoerd. De IT auditor voert samen met de IT first accountant de lijncontroles uit door samen met de cliënt te zitten aan het scherm: een waarneming ter plaatse dus. Dit is wellicht het meest krachtige maar ook het minst gebruikte controlemiddel. Accountants zijn helaas nog steeds geneigd andere controlemiddelen in te zetten. Met name de herhaling van werkzaamheden, narekenen van uitkomsten of verificatie zijn populair. Nog te veel wordt er niet een toetsing gedaan van de application controls (test of control), maar wordt er vastgesteld dat een transactie goed is verwerkt (detailcontrole of substantive test). Volgens de AFM heeft u dan een onjuiste controle uitgevoerd. Met een waarneming ter plaatse stelt u zowel het bestaan van de beheersingsmaatregel vast (test of control) maar doet u ook meteen een substantive test. En dit is echt niet moeilijk. Aan de hand van loggingbestanden stelt de IT auditor de werking vast van de relevante IB maatregelen. Niet van slechts 25 items, maar van de hele database gedurende het hele jaar. De IT auditor kan bij het uitvoeren van van deze werkzaamheden data-analyse als controle tool gebruiken waarbij de vastleggingen vanuit de lijncontrole prima aanknopingspunten bieden om tot een juiste en volledige analyse te komen.

Na de uitvoering van de testen evalueren de IT auditor en de accountant in hoeverre het controleplan veranderd moet worden: zijn de relevante controlemaatregelen op werking getoetst. is er nog meer met IT te controleren of moeten/kunnen er test of controls worden uitgevoerd buiten het systeem om?

In samenwerking met de IT auditor, test de accountant de werking van de relevante IT interne controles met behulp van bestandsanalyses. Hierbij wordt de gehele administratie ingelezen (steekproefomvang dus de hele populatie) en vindt er rapportage op uitzonderingen plaats. De IT first accountant maakt een analyse van de uitzonderingsrapportages (effect op controle aanpak bepalen etc) en voert tenslotte de handmatige controles uit.

Indien de controle aanpak wordt gewijzigd, kan er wederom overleg met de directie van de onderneming plaatsvinden. Immers, de interne beheersing in de IT blijkt toch anders te zijn dan de directie dacht. Ook weer een mooi advies moment.

Bij de afronding van de interim controle bepalen de accountant en IT auditor samen wat nog moet worden uitgevoerd met de balanscontrole. Want, veel balanscontroles zijn goed uit te voeren met IT tools, zoals IDEA. Denk bijvoorbeeld aan afloop controle debiteuren of voorzieningen, beoordelen memoriale boekingen, slimme cijferanalyses (omlooploopsnelheden), voortgezette controles in het nieuwe boekjaar. Er is veel meer mogelijk dan de traditionele accountant denkt en er hoeft veel minder gedaan te worden dan de traditionele accountant doet.

Bij de start van de balans controle worden eerst nog de interimwerkzaamheden over het hele jaar uitgebreid. De standaarden schrijven voor dat indien er zich ná afronding van het interim-werk belangrijke wijzigingen in de IB hebben voorgedaan er aanvullende werkzaamheden uitgevoerd dienen te worden. Maar hoeveel traditionele accountants maken deze overweging of voeren daadwerkelijk nog interim werkzaamheden uit tijdens de balanscontrole?  Hoewel de controle standaarden dit voorschrijven gebeurt dit weinig, want met handmatige interim controle kost dit veel werk. Maar met IT is dit snel te doen.

De boodschap is dus duidelijk. De accountant moet een IT first accountant worden en de IT auditor een moderne IT Auditor, want alleen dan kan de controle worden uitgevoerd in overeenstemming met de standaarden en de aanwijzingen van de AFM.

Lees onze volgende sessie: IT Inventarisatie bij een MKB organisatie.

 

Auteurs

Robert Johan RE CISSP
Directeur / IT-auditor bij Soll-IT. Soll-IT ondersteunt accountantskantoren bij inzet van IT-audit bij de controle. Docent SRA IT Audit.

Charles Rabe RA            
Partner bij Horlings Accountants tevens verantwoordelijk voor audit bij commissie vaktechniek. Docent Post Master Accountancy Nyenrode,  Financial auditing. Horlings is een middelgroot MKB accountants kantoor in Amsterdam met een vergunning voor het uitvoeren van wettelijke controles.

 

 

 

To cloud or not to cloud: that’s the question!

De toekomst volgens Gartner: de komende jaren gaan nog meer ondernemingen overstappen naar de cloud. In 2017 zal de helft van de grote ondernemingen een hybride cloud gebruiken, aldus de gerenommeerde voorspeller. Een hybride cloud is een combinatie van verschillende cloud oplossingen.

Deze ontwikkeling gaat aan de kleinere ondernemingen niet ongemerkt voorbij, waarbij de vraag gesteld kan worden: to cloud or not to cloud: that’s the question….

Roze wolk of onweerswolk?
Vraag aan de leveranciers van cloud diensten wat de voordelen zijn van een overstap naar de cloud en er zullen vele redenen worden genoemd om te overstappen, denk aan:

• Ontzorgen: de cloud leverancier beheert en onderhoudt uw systemen tegen een vast bedrag per maand.
• Lagere kosten voor IT
• Schaalbaarheid in gebruikerslicenties en resources
• De software is altijd up-to-date
• Laagdrempeligheid: start-ups kunnen tegen lage investeringen snel beschikken over IT systemen.

Maar uiteraard kleven er ook nadelen aan cloud toepassingen. Sta maar eens stel bij:

• Vendor lockin: de hardware en software is eigendom van de leverancier waardoor de onderneming in hoge mate afhankelijk is van deze leverancier.
• Faillissement of contractbreuk: hoe snel en in welke hoedanigheid kan een onderneming beschikken over haar data?
• Extra kosten door het opstellen van koppelingen tussen applicaties in verschillende clouds.
• Hoe gaan de medewerkers van de cloud leverancier om met de gegevens van de onderneming, welke toegang hebben de beheerders en hoe is de uitdienst procedure geregeld? 
• Lagere kosten: zeker weten? Bij eigen systemen zijn de eenmalig investeringen hoog. Heeft de onderneming te maken met data hoge beveiligingsvereisten vanuit de privacy wetgeving? Voldoet de cloud leverancier aan deze eisen en waar (in welk land) wordt de data opgeslagen?

Bovenstaand bullets zijn niet uitputtend en hoeft niet voor elke onderneming van toepassing te zijn. Maar ze geven wel een indicatie waarmee een ondernemer rekening dient te houden bij een overweging om over te stappen naar een of meerdere clouddiensten.

Soorten cloud
Cloud is een verzamel woord voor veel verschillende soorten clouds. Clouddiensten kunnen onderverdeeld worden in technische lagen:

• Software as a Service: de onderneming gebruikt een applicatie van een cloud leverancier. Voorbeeld Salesforce.com en Office365.
• Platform as a Service: de onderneming huurt een of meerdere besturingssystemen waarop applicaties geïnstalleerd worden. Voorbeeld: Windows Azure van Microsoft.
• Infrastructure as a Service: de onderneming huurt resources (processor, opslag e.a.) van een cloud leverancier. Voorbeeld Terremark en Amazon Web Services..
• Overigens zijn er nog meer varianten te bedenken dan alleen de boven genoemde clouds. Denk aan Storage as a Service van Googledrive. 

Cloudoplossing kunnen ook onderverdeeld worden in:

• Private cloud: de onderneming huurt ruimte in een rekencentrum en plaatst haar eigen apparatuur in deze ruimte. Het beheer wordt uitgevoerd door de onderneming zelf of door een externe beheerder.
• Public cloud: de infrastructuur is voor de hele wereld beschikbaar. De infrastructuur is eigendom van de leverancier, net als het beheer en de controle. De eerder genoemde voorbeelden Windows Azure, Salesforce.com, Office 365 en Amazon Web Services zijn public clouds.
• Community cloud: een cloud infrastructuur die door een aantal ondernemingen worden gedeeld uit een specifieke gemeenschap of dezelfde belangen. Voorbeeld EuroCloud
• Hybride cloud: een model waarbij een combinatie van twee of meer van bovenstaande clouds worden toegepast.

De keuze van een soort clouddienst is sterk afhankelijk van de wensen en eisen van de onderneming. Hierbij moet inzicht worden verschaft in de voor- en nadelen van de clouddiensten en de mate waarin ze voldoen aan de functionele en technische wensen en eisen.

Conclusie
Antwoord op de vraag “To cloud or not to cloud?” is redelijk eenduidig: de opmars van cloud is niet te stuiten. Elke ondernemer zal vroeger of later geconfronteerd worden met de vraag : moet ik overstappen naar een of meerdere clouddiensten? Het antwoord op deze vraag zal niet altijd even eenvoudig zijn gezien de vele (on)mogelijkheden en valkuilen. Een te snelle keuze kan resulteren in ongewenste situaties waardoor:

• kosten toch hoger zijn dan verwacht
• functionaliteit niet voldoet aan de wensen en eisen
• storingen en calamiteiten niet of onvoldoende worden gecompenseerd
• geen rekening is gehouden met specifieke regelgeving

En als de ondernemer dan kiest om te stoppen met afname van de clouddienst blijkt dit een vreselijke klus te zijn door allerlei juridische en technische knelpunten die van te voren niet voldoende aan het licht waren gekomen!

Dus: van belang is om de juiste keuze te maken op basis van gedegen aanpak en leveranciersselectie. Misschien komt de ondernemer dan zelfs tot de conclusie dat de huidige gebruikte oplossing niet zo slecht is……

Robert Johan RE CISSP, Senior IT-auditor/Directeur

Bent u al wakker accountant?

In 2011 is een aantal lekken in gemeentelijke websites publiekelijk gemaakt, met dank aan Webwereld Lektober. De overheid werd wakker geschud. Het besef drong door, dat de beveiliging van webapplicaties strikter moest worden geregeld. Naar aanleiding van Lektober heeft de toenmalige minister van Binnenlandse Zaken en Koninkrijksrelatie, de heer Donner, op 11 oktober 2011 een brief aan de Kamer gestuurd over “Lekken in aantal gemeentelijk websites”. Speerpunt hierbij is overheidsorganisaties die gebruik maken van DigiD. Burgers kunnen zich met een persoonlijke DigiD identificeren bij websites van de overheid. Deze overheidsorganisaties moeten hun ICT beveiliging op orde hebben. Zo wordt voorkomen dat gegevens mogelijk worden onderschept en oneigenlijk gebruikt hetgeen afbreuk kan doen aan het vertrouwen van burgers in het stelsel van DigiD.

Hier is op 2 februari 2012 een brief aan toegevoegd, waarin de huidige minister mevrouw Spies, aangeeft, dat organisaties die gebruik maken van DigID, jaarlijks hun ICT beveiliging dienen te toetsen door middel van technische audits. De brief ligt in lijn met andere artikelen, zoals laatst in de Automatiseringsgids, waarbij indirect of direct wordt aangegeven dat er steeds meer behoefte is aan technische audits. Het Nationaal Cyber Security Centrum (NCSC) heeft hiervoor ICT- beveiligingsrichtlijnen voor webapplicaties opgesteld. Deze richtlijnen zijn  technisch van aard.De minister verwacht dat deze richtlijnen een behoorlijke impuls geven aan de verdere ICT beveiliging.

De ICT-beveiligingsrichtlijn voor webapplicaties bestaat uit twee delen:

• Deel 1 bevat een beschrijving van de beveiligingsrichtlijnen op hoofdlijnen.
• Deel 2 bevat de verder uitgewerkte en gedetailleerde richtlijnen aangevuld met voorstellen voor inrichting, beheer en ontwikkeling.

Wat direct opvalt zijn de IT risico’s en technische maatregelen om deze risico’s te mitigeren. Termen zoals DNS cache poisoning, HTTP Response Splitting en testmethodieken van OWASP worden genoemd: gezonde dosis technische invulling! Ook een in het oog springende onderdeel van de ICT-beveiligingsassesment is een eventuele hacktest waarmee wordt vastgesteld of de ICT beveiliging van de organisatie te kraken is. Als accountants komen we in de praktijk steeds meer klanten tegen, die webapplicaties gebruiken. Bij sommige organisaties is de webapplicatie zelfs van dusdanig belang, dat de continuïteit van de organisatie in sterke mate afhangt van de continuïteit van de webapplicatie of, en misschien belangrijker, de beveiliging van de gegevens van de webapplicatie.  Het lekken van data kan tot imagoschade leiden en tot verlies van klanten. Denk bijvoorbeeld aan de recent uitgelekte inloggegevens van Kpn-klanten. Daarom is het van belang om tijdens de controle in een vroeg stadium vast te stellen of de webapplicatie van de cliënt een essentieel business risk oplevert en of dit ook een audit risk betekent.

Mocht dit het geval zijn, dan ben ik van mening  dat u zich moeten verdiepen in de techniek van de webapplicatie. Anders kunt u geen gedegen uitspraak doen over de beveiliging van de webapplicaite. En dat is nu precies wat de ICT-beveiligingsrichtlijnen voor webapplicaties aangeeft. Deze richtlijnen zouden voor accountants een impuls moeten zijn om technische IT-audits geïntegreerd op te nemen in de controle. Het tijdig herkennen van risico’s en het integreren van technische audits moet in de DNA van de accountantsorganisatie zijn ingebakken, waarbij wij tijdig bij onze cliënten wijzen op risico’s van hun webapplicaties en mogelijke consequenties voor hun organisatie.

Vaak ontbreekt het bij accountants echter aan bewustwording. Dus accountants wordt wakker en wacht niet op het eerste lek in de webapplicaties van uw cliënt.

De (on)zin van General IT Controls bij een controle van een jaarrekening bij een MKB organisatie.

Inleiding

Tijdens het controleren van de jaarrekening bij een MKB organisatie wordt IT een steeds belangrijker aspect. Het is van belang om al in de voorbereidende fase de IT omgeving te inventariseren om eventuele risico’s vast te stellen en te bepalen of er specifieke IT deskundigheid noodzakelijk is teneinde de opdracht uit te kunnen voeren.

Gedurende het controle proces zullen dan de zogenaamde General IT Controls aan de orde komen. De volgende aspecten zijn dan van essentieel belang:

• Alleen die General IT controls die van belang zijn voor de controle van de jaarrekening dienen in opzet maar ook in bestaan getoetst te worden. De juiste selectie van General IT Controls wordt bepaald vanuit de application controls die van belang zijn voor de controle. Daarnaast kunnen er specifieke audit risico’s aanwezig zijn die niet zijn gekoppeld aan een jaarrekeningpost. Denk aan continuïteitsaspecten bij het niet voldoen aan wet- en regelgeving (Wet Bescherming Persoonsgegevens bij een Webshop met creditcard gegevens).
• Wat zijn de consequenties als een General IT control niet of onvoldoende aantoonbaar aanwezig is? Zijn er consequenties voor de verklaring? Zijn er vervangende maatregelen mogelijk?

Bij de inzet van een IT auditors dienen bovenstaande punten inzichtelijk te zijn zodat de IT auditor adequaat aangestuurd wordt en de accountant de resultaten van de IT audit kan “vertalen” naar consequenties voor de controlewerkzaamheden of misschien zelfs voor de soort verklaring.

Het onvoldoende stilstaan bij welke General IT Controls relevant zijn en wat de diepgang van de IT audit moet zijn leidt tot het uitbesteden van een onduidelijke situatie wat kan  resulteren in een onjuiste focus van de werkzaamheden van de IT auditor. Het risico hiervan is dat in het beste geval meer wordt gedaan dan wat nodig is en in het slechtste geval de verkeerde controls worden getest waardoor de accountant er onterecht vanuit gaat dat hij op de voor hem van belang zijnde controls zou kunnen steunen. Immers de accountant loopt het risico dat door de onjuiste focus van de IT auditor de voor hem van belang zijnde controls juist niet zijn getest.. De accountant zal zelf moeten definiëren welke IT controls kritisch zijn in het kader van de jaarrekeningcontrole en vervolgens, waar nodig, in overleg treden met een IT-auditor, om hem te helpen bij het beoordelen van deze IT controls.

Verband tussen General IT Controls en jaarrekeningposten: voorbeelden

Sommige General IT Controls zijn direct te koppelen aan Application Controls.  Denk hierbij aan de volgende voorbeelden:

• Logische toegangsbeveiliging
  Logische toegangsbeveiliging heeft betrekking op functiescheidingen. Functiescheidingen kunnen op diverse IT-lagen worden doorbroken (applicatie, database, netwerk). Adequate General IT controls dienen de werking van de logische toegangsbeveiliging gedurende een periode (boekjaar) te waarborgen. Denk hierbij aan in- en uitdienst procedures, bewaken van toegangsrechten van medewerkers, opzet van autorisatierollen, authenticatie en identificatie. Als desbetreffende General IT controls goed werken dan kan worden overwogen om de werking van de functiescheidingen verder niet te testen (met behulp van bijvoorbeeld proceduretesten). Echter het kan voorkomen dat de General IT Controls niet aantoonbaar gewerkt hebben of onvoldoende aanwezig zijn. Dan kan, indien de randvoorwaarden aanwezig zijn, gekozen worden voor het gebruik van data-analyse om logging en audit trail te beoordelen om vast te stellen of essentiële functiescheidingen zijn doorbroken. Hierbij is wel een adequate identificatie en authenticatie van belang om zeker te stellen dat de data-analyse betrouwbare resultaten weergeeft. Indien deze benadering niet mogelijk is dienen aanvullende werkzaamheden uitgevoerd te worden om het ontbreken van voldoende functiescheidingen in de IT systemen op te vangen. In sommige situaties kan dit tot een in-efficiënte controle leiden. Daarom is het van belang om in een vroeg stadium met de klant te communiceren welke General IT Controls van belang zijn en wat eventuele consequenties zijn bij het ontbreken hiervan.
• Change management
  Bij application controls is de General IT Control Change Management van belang om te waarborgen dat de application controls gedurende een periode juist hebben gewerkt. Indien een change management procedure in bestaan en werking onvoldoende aanwezig is kan eventueel door inzet van data-analyse de werking van application controls  gedurende een periode alsnog worden getoetst. De (on)mogelijkheden zijn afhankelijk van de soort application control en de complexiteit ervan.

Naast application controls  kunnen andere factoren aanwezig zijn waarbij adequate General IT Controls van belang zijn.  Denk hierbij aan een organisatie die handelt in persoonsdata of webwinkels waarbij gegevens van klanten worden vastgelegd op de website (bijvoorbeeld credit card gegevens). Het niet voldoen aan wet- en regelgeving of het lekken van deze data kan dusdanige consequenties voor de organisatie hebben dat de continuïteit van de organisatie in het geding komt. Dit als gevolg van schadeclaims of  aanzienlijke imagoschade.

Een andere factor kan zijn dat de continuïteit van primaire bedrijfsprocessen in hoge mate afhankelijk is  van IT waarbij IT storingen direct consequenties hebben voor de primaire bedrijfsprocessen en kan leiden tot continuïteitsrisico’s.

Tenslotte  kan een niet adequate werking van de back-up & recovery procedure leiden tot onacceptabel dataverlies.

Resumerend

Bij veel organisaties zullen General IT Controls bij de controlewerkzaamheden steeds meer een realiteit worden. Dit als gevolg van de interne beheersingsmaatregelen die steeds meer geautomatiseerd zijn. Maar alleen de General IT Controls toetsen heeft geen zin als er niet gesteund wordt op de geautomatiseerde interne beheersingsmaatregelen in de vorm van application controls. Echter indien er gesteund wordt op application controls dient er ook gekeken te worden naar de juiste General IT Controls.

Hierbij kan de inzet van een IT auditor handig zijn om af te stemmen welke General IT Controls van belang zijn, hoe deze in opzet en bestaan getoetst kunnen worden en waar specifieke kennis in het controleteam (IT auditor) noodzakelijk is.  De accountant bepaalt hierbij welke IT controls van belang zijn en zal op basis hiervan de IT auditor juist aan sturen.