Vrije Universiteit Amsterdam Postgraduate IT-Audit opleiding

Vrije Universiteit Amsterdam Postgraduate IT-Audit opleiding

Student: Djef Memedov 1770047 Scriptiebegeleider: Dr. Ing. Abbas Shahim MSc RE Castricum 29 april 2009

End User Informatievoorziening

Inhoud 1

2

3

4

5 6 7

8

9

Inleiding .......................................................................................................................................3 1.1 Doelstelling............................................................................................................................5 1.2 Afbakening ............................................................................................................................6 1.3 Onderzoeksvraag ..................................................................................................................8 1.4 Aanpak ..................................................................................................................................8 Risico-analyse en literatuurstudie .................................................................................................9 2.1 Risico-analyse EUI ................................................................................................................9 2.1.1 Risico’s bij invoer ..........................................................................................................10 2.1.2 Risico’s bij verwerking...................................................................................................10 2.1.3 Risico’s bij output en distributie .....................................................................................10 2.2 Literatuurstudie....................................................................................................................12 2.2.1 Algemene beheersmaatregelen voor EUI ......................................................................12 2.2.2 Beheersmaatregelen van organisatorische aard en logische toegangsbeveiliging .........13 2.2.3 Beheersmaatregelen voor betrouwbare invoer ..............................................................14 2.2.4 Beheersmaatregelen voor betrouwbare verwerking .......................................................14 2.2.5 Beheersmaatregelen voor betrouwbare output ..............................................................17 2.2.6 Beheersmaatregelen voor betrouwbare distributie .........................................................18 Casestudies ...............................................................................................................................20 3.1 Casus niet-routinematige processen ....................................................................................20 3.1.1 Reden gebruik EUA ......................................................................................................20 3.1.2 Maatregelen ..................................................................................................................21 3.1.3 Rest-risico’s ..................................................................................................................21 3.2 Casus vliegtuigonderhoud ...................................................................................................22 3.2.1 Reden gebruik EUA ......................................................................................................23 3.2.2 Risico’s .........................................................................................................................23 3.2.3 Maatregelen ..................................................................................................................23 3.3 Casus pensioenverzekeraar ................................................................................................25 3.3.1 Reden gebruik EUA ......................................................................................................25 3.3.2 Maatregelen ..................................................................................................................25 3.3.3 Rest-risico’s ..................................................................................................................25 3.4 Casus ATK ..........................................................................................................................26 3.4.1 Het Controlebestand .....................................................................................................26 3.4.2 Het Probleembestand....................................................................................................27 3.4.3 Applicatie Transparante Klantbehandeling ....................................................................29 3.4.4 Brondata in ATK............................................................................................................30 Analyse van theorie en praktijk...................................................................................................32 4.1 Waarom en op welke wijze maakt men in de praktijk gebruik van EUI? ................................32 4.2 Welke maatregelen worden getroffen om de betrouwbaarheid van EUI te waarborgen?.......32 4.3 Welke verschillen zijn te constateren tussen de theorie en de praktijk?................................33 Samenvatting .............................................................................................................................35 Persoonlijke reflectie ..................................................................................................................37 Bijlage 1: Wet- en regelgeving....................................................................................................38 7.1.1 Fiscale wetgeving .........................................................................................................38 7.1.2 Horizontaal Toezicht .....................................................................................................38 7.1.3 Sarbanes-Oxley Act ......................................................................................................39 Bijlage 2: Algemeen aanvaarde raamwerken ..............................................................................40 8.1.1 Code voor informatiebeveiliging ....................................................................................40 8.1.2 Coso .............................................................................................................................41 8.1.3 Cobit .............................................................................................................................42 8.1.4 ITIL ...............................................................................................................................43 Geraadpleegde Literatuur...........................................................................................................45

2


1

Inleiding

Organisaties maken voor hun informatievoorziening gebruik van geformaliseerde informatiesystemen. Inherent aan geformaliseerde systemen is dat gebruikte applicaties en data onderhevig zijn aan formele procedures en beheersmaatregelen. De applicaties met alle daarin opgenomen controls zijn normaliter onderworpen aan een beheerst proces van specificaties vaststellen, ontwerpen, ontwikkelen, testen, accepteren, in productie nemen en onderhouden. Dit formele traject geldt evenzeer voor het vervaardigen van rapporten. Door middel van voorgedefinieerde queries wordt data uit de bronsystemen verzameld en op basis van de geprogrammeerde business logica en business regels veredeld en als informatie gepresenteerd. De aandacht voor de kwaliteitsaspecten van betrouwbaarheid 1 die bij de inrichting en monitoring van het geformaliseerde informatiesysteem in acht zijn genomen kunnen betrouwbare informatie 2 waarborgen. Het ligt voor de hand om aan te nemen dat uitsluitend deze informatie gebruikt zal worden voor het nemen van beslissingen en het voldoen aan wettelijke verplichtingen zoals verslaggeving en het indienen van fiscale aangiften. Echter, de praktijk is weerbarstiger. Naast deze geformaliseerde informatiesystemen die vaak omgeven zijn met tal van beheersmaatregelen, wordt voor het afleggen van verantwoording en het nemen van beslissingen ook informatie gebruikt die door een gebruiker zelf is gegenereerd. De data die hierbij wordt gebruikt, wordt uit het geformaliseerde systeem gehaald en verwerkt in een door de gebruiker zelf gemaakte toepassing. In de praktijk is gebleken dat dit vooral een spreadsheet of een database toepassing is, veelal vanwege het gebruiksgemak, de flexibiliteit en de lage kosten van het programma. Zo op het eerste gezicht lijkt dit een vreemde situatie; gegevens uit een beheerste omgeving worden overgezet naar een onbeheerste omgeving, en vervolgens verwerkt en gebruikt voor het nemen van beslissingen en het afleggen van verantwoording. Hierdoor kunnen risico’s ontstaan voor de betrouwbaarheid van de informatie. In het vervolg worden de spreadsheet en database toepassingen die een gebruiker zelf heeft gebouwd en beheert ten behoeve van de informatievoorziening, aangeduid met de term End User Applications (EUA’s). Deze terminologie is in de literatuur gangbaar. In de praktijk is gebleken dat met name voor niet-routinematige processen3 informatie voor managementondersteuning en verslaggeving met behulp van EUA’s wordt vervaardigd. Enkele toepassingsvoorbeelden uit de praktijk zijn: • Managementinformatie, met toevoeging van tekst en analyses ten opzichte van de begroting over bijvoorbeeld de omzetontwikkeling per productgroep, per divisie, per regio, per vierkante meter alsmede over personeelsmutaties, ziekteverzuim, etcetera. • Vastlegging van materiële vaste activa en berekening van de periodieke afschrijvingspost. • Berekening van voorzieningen en de daarmee corresponderende kostenpost. • De consolidatie van gegevens ten behoeve van een jaarrekening of aangifte.4

1 2

Kwaliteitsaspecten van betrouwbaarheid zijn: vertrouwelijkheid/exclusiviteit, integriteit en controleerbaarheid. Onder informatie wordt verstaan: het (zich) verschaffen van kennis of inzicht (Van Dale woordenboek). Informatie is

opgebouwd uit data of gegevens (feiten), voor een bepaald doel. De informatiebehoefte binnen organisaties is veelal gericht op informatie die nodig is voor: het nemen van beslissingen, het kunnen uitvoeren van de bedrijfsactiviteiten en het al dan niet (bij)sturen daarvan alsmede voor het afleggen van (externe) verantwoording (verslaggeving). Starreveld heeft deze elementen ondergebracht in zijn definitie van Bestuurlijke informatieverzorging: ‘Alle activiteiten met betrekking tot het systematisch verzamelen, vastleggen en verwerken van gegevens, gericht op het verstrekken van informatie ten behoeve van het besturen in engere zin (kiezen uit alternatieve mogelijkheden), het doen functioneren en het beheersen van een huishouding, en ten behoeve van de verantwoordingen die daarover moeten worden afgelegd’ (Bestuurlijke Informatieverzorging deel 1). 3 Niet-routinematige processen zijn gebeurtenissen of transacties met een relatief lage frequentie of incidenteel karakter. Voor een uitgebreide opsomming van toepassingen voor niet-routinematige processen wordt verwezen naar

4

casestudie 1 in hoofdstuk drie.

3


Naast de EUA’s die gebruikt worden voor de niet-routinematige processen, is er een groep EUA’s waarmee primaire bedrijfsprocessen worden ondersteund. Deze vorm van EUA’s wordt veelal in het midden- en kleinbedrijf toegepast. Dit is voornamelijk ingegeven door kostenoverwegingen en het relatief eenvoudige gebruik van een spreadsheet of database. Een voorbeeld hiervan is de registratie van de voorraden (inkoop en verkoop) en de registratie van inkoopfacturen/verkoopfacturen met bijhorende omzetbelasting. Ook binnen grote organisaties worden EUA’s ontwikkeld ter ondersteuning van de primaire en routinematige processen (casestudies 2, 3 en 4 in hoofdstuk drie). Deze worden vaak binnen een organisatieonderdeel, bijvoorbeeld een team of een unit, ontwikkeld om in een bepaalde informatiebehoefte te voorzien. Uit efficiency overwegingen (budget en tijd) wordt geen formeel -en vaak langdurig- ontwikkeltraject ingezet, met als gevolg dat handige spreadsheet- of databasegebruikers zelf een EUA ontwikkelen ter ondersteuning van het bedrijfsproces. De EUA voldoet dan prima aan de informatiebehoefte van het (team)management en de gebruikers, maar laat vanuit beheersoogpunt vaak veel te wensen over. Uit de praktijk blijken duidelijk de elkaar bijtende principes tussen beheersing en flexibiliteit: vanuit managerial standpunt bestaat de behoefte om informatievoorziening te beheersen en vanuit de business operations de behoefte aan snel opleverbare en op maat toegesneden IT-hulpmiddelen ter ondersteuning van een bedrijfsproces. De hiervoor genoemde EUA’s worden ogenschijnlijk zonder formele beheersmaatregelen door een gebruiker gebouwd en gebruikt.5 De informatie daaruit wordt in de meeste gevallen betrouwbaar geacht voor het nemen van beslissingen en het afleggen van verantwoording. In het kader van deze scriptie wordt dit verschijnsel als ‘End User Informatievoorziening’ geduid. De betrouwbaarheid van de informatievoorziening is zonder nadere waarborgen daardoor in hoge mate afhankelijk van het beheersingsbewustzijn van de bouwer.

End User Informatievoorziening (EUI) is het proces waarbij informatie wordt vervaardigd met behulp van een door, of namens een eindgebruiker gebouwde en in gebruik zijnde toepassing (EUA). EUI omvat de invoer van gegevens in de EUA (manueel of geautomatiseerd), de verwerking in de EUA en de verspreiding van het resultaat van verwerkte gegevens (output). End User Informatie (EUInfo) is de output van de EUI die gebruikt wordt voor besluitvorming, ondersteuning van operationele activiteiten of verslaggeving.

5

Veel boekhoud- en ERP-pakketten bieden tegenwoordig de mogelijkheid om data te selecteren en direct naar Excel

(formaat) te exporteren. Een manager/controller kan dan vrij eenvoudig in Excel handelingen uitvoeren zoals het maken van sorteringen en (filter)selecties. Deze informatie is in de praktijk waardevol voor de operationele sturing, maar omdat er inhoudelijk geen bewerking plaatsvindt op de data, is er geen sprake van het gebruik van een EUA in het kader van deze scriptie.

4


De twee hoofdvormen van geautomatiseerde informatievoorziening zoals hiervoor besproken, namelijk de beheerste formele informatievoorziening en de ogenschijnlijk onbeheerste EUI, zijn weergegeven in figuur 1.

Formele Informatievoorziening: Beheerst proces met vastomlijnde procedures

Geformaliseerde systemen

Bla bla

EUA

do

data (Geautomatiseerde invoer)

cu m

en t

Bla bla bla bla bla bla bla bla bla bla

Managementondersteuning / Ondersteuning operationele activiteiten / Verslaggeving (jaarrekeningen/aangiften)

(Manuele invoer)

(End User Informatie)

EUI: Onbeheerst proces, betrouwbaarheid vooral afhankelijk van het beheersingsbewustzijn van het individu

Figuur 1: Formele Informatievoorziening versus EUI

1.1

Doelstelling

Het doel van deze scriptie is om te komen tot een beschrijving van beheersmaatregelen om de betrouwbaarheid van de informatievoorziening met behulp van EUA’s te waarborgen. De maatregelen moeten de risico’s voor de informatievoorziening met behulp van EUA’s mitigeren. Hierin worden twee hoofdelementen onderkend: risico’s met betrekking tot de betrouwbaarheid van de EUA, dus de toepassing zelf, en risico’s met betrekking tot de betrouwbaarheid van de gegevens. De betrouwbaarheid van de EUI is daardoor afhankelijk van maatregelen die op deze twee deelgebieden betrekking hebben. Ten aanzien van de EUA betekent dit dat er maatregelen moeten zijn getroffen die toezien op de betrouwbare werking van de EUA, zoals het testen of de toepassing werkt zoals die moet werken, en maatregelen die ervoor moeten zorgen dat de werking van de EUA betrouwbaar blijft (general ITcontrols 6). Daarnaast kan de EUA functioneel prima werken, maar als er geen organisatorische, procedurele en 6

Onder de general IT-controls wordt verstaan: de beheersmaatregelen van logische toegangsbeveiliging,

changemanagement, back-up/recovery/uitwijk, fysieke beveiliging, incidentmanagement en ook organisatorische maatregelen zoals functiescheiding tussen gebruikers- en automatiseringsorganisatie, die op haar beurt is gescheiden in een ontwikkelen productieorganisatie.

5


technische maatregelen zijn getroffen die de ingevoerde of uitgevoerde gegevens op juistheid, tijdigheid en volledigheid controleren (integriteitscontrole), hetzij vooraf (preventief) hetzij achteraf (repressief), dan kan de EUInfo ten behoeve van de besluitvorming of verslaggeving alsnog onbetrouwbaar zijn. Immers, een onjuist ingevoerd gegeven wordt met een betrouwbare EUA correct verwerkt, maar leidt tot verkeerde informatie. Geprogrammeerde controles op de invoer (technische maatregelen) en/of user controls (organisatorische/procedurele maatregelen zoals het vier-ogen principe) dienen ervoor te zorgen dat de informatie die met behulp van EUA tot stand komt betrouwbaar is. 7 Het voorgaande is samengevat in figuur 2: Risico’s EUA Maatregelen die een betrouwbare (goed werkende) EUA waarborgen en maatregelen waardoor de EUA betrouwbaar blijft werken. Betrouwbaarheid van EUI Risico’s Gegevens Maatregelen die de betrouwbaarheid waarborgen van de in te voeren, de reeds ingevoerde en gepresenteerde gegevens. Figuur 2: EUI risico- en maatregelgebieden

1.2

Afbakening

In het proces van EUI worden drie fasen onderscheiden: gegevens worden geautomatiseerd geïmporteerd of manueel in de EUA ingevoerd, vervolgens verwerkt in de EUA en ten slotte als EUInfo gepresenteerd of gedistribueerd. 8 Andere varianten vallen buiten de scope van deze scriptie. Met betrekking tot de geautomatiseerde invoer zijn meerdere varianten denkbaar. Een eerste variant is die waarbij de EUA gebruiker de autorisatie heeft om gegevens uit het formele systeem op te vragen, zoals bijvoorbeeld alle verkopen over een bepaalde periode, en deze in de EUA verwerkt ten behoeve van periodieke managementrapportages. Een tweede variant is, en dit zal met name bij grotere organisaties plaatsvinden vanwege performance eisen, dat gegevens door de automatiseringsorganisatie op een netwerklocatie (directory) worden geplaatst waar uitsluitend een geautoriseerde gebruiker van de EUA bij kan, die deze gegevens binnenhaalt en geautomatiseerd in de EUA invoert met behulp van een daarvoor ontwikkeld programma. 9 De procedures en maatregelen om de gegevens uit het formele systeem beschikbaar te stellen voor een EUA verwerking worden niet in deze scriptie behandeld. Er wordt vanuit gegaan dat een geautoriseerde EUA gebruiker de benodigde digitale gegevens krijgt aangeleverd of zelf uit het formele systeem kan opvragen en dat deze gegevens betrouwbaar zijn.

7

Bij het vier-ogen principe worden de ingevoerde gegevens door een andere persoon gecontroleerd en goedgekeurd

voor eventuele verdere bewerking. 8 De presentatie kan plaatsvinden door toegang te verschaffen aan bevoegden tot deze informatie in de EUA (om te raadplegen) maar ook door deze informatie onder bevoegden op papier of digitaal te verspreiden. 9 Hierbij dient gedacht te worden aan een vooraf gedefinieerde en vastgestelde query aan de hand waarvan de automatiseringsorganisatie op vastgestelde tijden de overeengekomen gegevens aan de gebruiker oplevert. De gebruiker heeft vooraf de informatiebehoefte gedefinieerd en de uitkomst van de query grondig getest; bijvoorbeeld alle verkopen van een bepaalde divisie over de verstreken maand en overige voorgedefinieerde velden. Onder het beheer van de automatiseringsorganisatie wordt de query op de vastgestelde tijden uitgevoerd, en worden de gegevens uit een datawarehouse omgeving gehaald en verspreid naar de directory van de geautoriseerde EUA gebruiker. Het beheer van de query en uitvoering daarvan is in een Service Level Agreement opgenomen.

6


Eveneens wordt ervan uitgegaan dat de gegevens die manueel worden ingevoerd uit betrouwbare (geautoriseerde) brondocumenten komen. Er wordt niet ingegaan op organisatorische en procedurele maatregelen, zoals controletechnische functiescheiding, die de betrouwbaarheid van het gebruikte brondocument of de beschikbaar gestelde brondata moeten waarborgen. In de praktijk wordt voor het vervaardigen van een EUA vaak Microsoft Excel (spreadsheet) en in mindere mate Microsoft Access (database) gebruikt. Vanwege het intensieve gebruik van deze producten richt de beschrijving zich tot de hiermee vervaardigde toepassingen. Er wordt van uitgegaan dat de EUA zich bevindt op het bedrijfsnetwerk en de gebruikers de beschikking hebben over de Microsoft Office applicaties (Excel of Access). De manier waarop de gegevens en de EUA worden bewaard en beschikbaar blijven (backup/recovery procedures) maken geen onderwerp uit van deze scriptie. Het gaat in deze scriptie om EUA’s waarvan de informatievoorziening relevant (bedrijfskritisch) is voor de besluitvorming, ondersteuning van het primaire bedrijfsproces of relevant is voor de verslaggeving (jaarrekening/fiscale aangiften). De classificatie van EUA’s valt buiten het kader van deze scriptie. In deze scriptie wordt uitsluitend op de kwaliteitsaspecten van betrouwbaarheid ingegaan die als volgt worden gedefinieerd:10 Vertrouwelijkheid of exclusiviteit: de mate waarin uitsluitend geautoriseerde personen (of apparatuur) via geautoriseerde procedures gebruik kunnen maken van IT-processen, zoals de mogelijkheid tot het lezen of muteren van gegevens. Integriteit: de gegevens of informatie zijn in overeenstemming met de afgebeelde werkelijkheid. In het spraakgebruik hanteert men hiervoor de termen juistheid, tijdigheid (of actualiteit) en volledigheid. Controleerbaarheid van de EUA en de EUInfo: met betrekking tot de EUA gaat het om de mogelijkheid om vast te stellen hoe de EUA is opgebouwd en hoe deze werkt. De kwaliteit van de documentatie speelt hierbij een belangrijke rol. Ten aanzien van de EUInfo gaat het om de mogelijkheid om het controlespoor (audit-trail) te kunnen volgen naar de brongegevens waaruit de EUInfo is samengesteld, maar ook om de mogelijkheid om in voorkomende gevallen te kunnen vaststellen wie (welke user/gebruiker), wanneer, een bepaalde handeling heeft verricht. Dit zal zich met name voordoen als meerdere users dezelfde bevoegdheden hebben en het achteraf wenselijk is om een handeling te kunnen herleiden naar de betreffende persoon. Een EUA omvat de applicatie en eventuele databases die daar deel van uitmaken.

10

De kwaliteitsaspecten van betrouwbaarheid zijn afgeleid uit Nivra geschrift nr. 53 (1995), Norea geschrift nr. 1 (1998)

en toegespitst op EUI.

7


1.3

Onderzoeksvraag

In deze scriptie staat de volgende onderzoeksvraag centraal: Op welke wijze en in hoeverre kan de betrouwbaarheid van EUI worden gewaarborgd? Deelvragen Vragen die naar aanleiding van de centrale onderzoeksvraag opkomen en die beantwoord zullen worden, zijn: 1. Welke beheersmaatregelen waarborgen volgens de literatuur betrouwbare EUI? 2. Waarom en op welke wijze maakt men in de praktijk gebruik van EUI? 3. Welke beheersmaatregelen worden getroffen om de betrouwbaarheid van EUI te waarborgen? 4. Welke verschillen zijn te constateren tussen de theorie en de praktijk? In hoofdstuk twee wordt deelvraag 1 beantwoord. Deelvragen 2, 3 en 4 worden in hoofdstuk vier beantwoord.

1.4

Aanpak

Ten einde antwoord te kunnen geven op de centrale onderzoeksvraag en de deelvragen is een onderzoek ingesteld door middel van literatuurstudie en interviews van praktijktoepassingen. Daarvoor zijn normen en maatregelen die gelden voor een betrouwbare informatievoorziening bestudeerd. Op basis van deze studie is een set aan beheersmaatregelen gedestilleerd aan de hand waarvan de betrouwbaarheid van EUI kan worden gewaarborgd. Vervolgens is gekeken op welke wijze EUI in de praktijk wordt toegepast. De informatie van deze casestudies is door middel van interviews verkregen. Hierna is geanalyseerd in hoeverre de beheersmaatregelen voor betrouwbare EUI zoals afgeleid uit de literatuur, in de praktijk worden gehanteerd. Ten slotte wordt een samenvatting gegeven naar aanleiding van de literatuurstudie en de bevindingen in de praktijk waarmee de centrale onderzoeksvraag wordt beantwoord. In onderstaand schema (figuur 3) is deze aanpak en hoofdstukindeling samengevat. Onderzoeksvraag: Op welke wijze en in hoeverre kan de betrouwbaarheid van EUI worden gewaarborgd? Hoofdstuk 1

Literatuuronderzoek: Afleiden beheersmaatregelen voor betrouwbare EUI.

Praktijkonderzoek: Beschrijven praktijktoepassingen EUI. (waarvoor, waarom, welke maatregelen)

Hoofdstuk 2

Hoofdstuk 3

Analyse: Op basis van literatuuronderzoek en praktijktoepassingen beantwoorden van de deelvragen. Hoofdstuk 4

Samenvatting: Samenvatting en antwoord op de centrale onderzoeksvraag. Hoofdstuk 5

Figuur 3: Stramien scriptie

8


2

Risico-analyse en literatuurstudie

In dit hoofdstuk wordt door middel van risico-analyse behandeld welke bedreigingen van invloed zijn op een betrouwbare EUI. In de risico-analyse wordt in kaart gebracht wat er fout kan gaan waardoor de betrouwbaarheid van de informatievoorziening in gevaar wordt gebracht. Vervolgens wordt aan de hand van literatuurstudie geanalyseerd welke set aan beheersmaatregelen de betrouwbaarheid van de informatievoorziening kan waarborgen. Hierbij is onder meer gebruik gemaakt van de leer van de administratieve organisatie en interne beheersing, de Code voor Informatiebeveiliging, de Microsoft whitepaper over spreadsheet compliance, de belastingwetgeving, een aantal publicaties op het gebied van het gebruik van spreadsheets en de algemeen aanvaarde raamwerken Cobit, Coso en ITIL.

2.1

Risico-analyse EUI

Het proces van EUI is in het kader van deze scriptie in drie fasen onderverdeeld: • • •

Fase 1: Geautomatiseerd binnenhalen of manueel invoeren van (betrouwbaar veronderstelde) brondata/brondocumenten in de EUA. Fase 2: Verwerken van de gegevens in de EUA. Fase 3: Distribueren van de EUInfo naar personen die op basis van deze informatie beslissingen nemen, het bedrijfsproces verder voortzetten, of hiermee kunnen zorgdragen voor het opstellen van de jaarrekening en het indienen van de aangiften.

Geformaliseerd systeem

Afgeschermde directory met betrouwbare data voor geautoriseerde gebruiker

(2) Verwerking in EUA (1) Invoer gegevens Geautomatiseerde invoer

(3) Distributie EUInfo EUInfo op papier EUInfo digitaal

betrouwbaar (geautoriseerd) DOCUMENT

Manuele invoer gegevens Analyse

Figuur 4: De drie fasen van EUI

Voor elk van de drie onderscheiden fasen in het proces van EUI, te weten invoer, verwerking en distributie, is geanalyseerd welke relevante risico’s zich kunnen voordoen met betrekking tot de vertrouwelijkheid, integriteit en controleerbaarheid. Relevante risico’s zijn díe risico’s die kunnen leiden tot onbetrouwbare EUInfo en daarmee kunnen leiden tot het nemen van verkeerde beslissingen, onjuiste verslaggeving of het niet voldoen aan de (wettelijke) eis van controleerbaarheid. Om deze risico’s te mitigeren zullen er maatregelen moeten worden getroffen.

9


De uitkomst van de risico-analyse is weergegeven in tabel 1. Deze wordt hieronder toegelicht.

2.1.1

Risico’s bij invoer

Voor de in te voeren gegevens bestaat het risico dat deze fout worden ingevoerd, of in het geheel niet worden ingevoerd, ook al komen zij uit betrouwbare brondata of brondocumenten. Dit leidt tot niet integere gegevens in de EUA en daarmee tot niet integere EUInfo, hetgeen kan leiden tot het nemen van verkeerde beslissingen en het opstellen van onjuiste verantwoordingen. Als eenmaal is vastgesteld dat de gegevens integer in de EUA zijn ingevoerd, dan is het niet gewenst dat deze door onbevoegden kunnen worden gewijzigd of kunnen worden geraadpleegd. De risico’s die de vertrouwelijkheid en integriteit van de input ondermijnen zullen daarom moeten worden afgedekt. Uit hoofde van controleerbaarheid bestaat het risico dat achteraf niet meer kan worden nagegaan wie, wanneer, welke wijzigingen heeft aangebracht in de gegevens.

2.1.2

Risico’s bij verwerking

Met betrekking tot de verwerking van gegevens in de EUA is het van belang dat de EUA geen programmeerfouten bevat, dus dat het doet wat het moet doen voor de gebruiker die de verantwoordelijkheid draagt voor de EUInfo, maar ook dat de EUA niet tussentijds zonder zijn toestemming kan worden gewijzigd. Ten behoeve van de controleerbaarheid (maar bijvoorbeeld ook ten behoeve van overdraagbaarheid en onderhoudbaarheid) bestaat het risico dat niet beschreven is hoe de EUA is opgezet en werkt. Uit hoofde van controleerbaarheid bestaat het risico dat achteraf niet kan worden nagegaan wie, wanneer, welke wijzigingen heeft aangebracht in de rekenregels, logica of de tabellen.

2.1.3

Risico’s bij output en distributie

Het is niet gewenst dat de output kan worden gewijzigd of door onbevoegden kan worden geraadpleegd. Indien EUInfo tot stand komt doordat eerst een selectie op de gegevens in de EUA plaatsvindt, bestaat het risico dat dit niet integer gebeurt, waardoor de geëxporteerde digitale EUInfo niet in overeenstemming is met de gegevens in de EUA. Ten slotte bestaat het risico dat van de output of EUInfo de toestand op een bepaald moment, bijvoorbeeld de toestand per 31-12-2009, niet meer kan worden gereproduceerd of herleidbaar is uit welke brongegevens deze is opgebouwd. Ten aanzien van de controleerbaarheid geldt overigens niet alleen dat vanuit de eigen organisatie de beheersingsbehoefte zal bestaan om EUI te kunnen controleren, maar ook de (fiscale) wet legt hier een verplichting op. Artikel 52 lid 6 van de Algemene wet inzake rijksbelastingen11 (AWR) bepaalt dat de administratie zodanig moet zijn ingericht en gegevensdragers zodanig dienen te worden bewaard, dat controle daarvan binnen een redelijke termijn mogelijk is. Bovendien moeten deze gegevensdragers gedurende (ten minste) zeven jaar worden bewaard (artikel 52 lid 4 AWR). In bijlage 1 wordt nader ingegaan op de invloed van weten regelgeving op EUI.

11

Algemene wet inzake rijksbelastingen, Wet van 2 juli 1959, Stb. 301, laatstelijk gewijzigd bij Wet van 18-12-2008,

Stb. 566 en 567.

10


Tabel 1: Risico’s bij EUI Kwaliteitsaspecten

INVOER gegevens ---> (manueel / digitaal)

---> VERWERKING --->

---> Resultaat/Output --->

--->Distribueren EUInfo (papier / digitaal)

Vertrouwelijkheid

Onbevoegden kunnen kennis nemen van de gegevens (lezen).

Onbevoegden kunnen kennis nemen van de Onbevoegden kunnen kennis nemen Onbevoegden kunnen kennis nemen rekenregels (formules), logica (code) of van de gegevens (lezen). van de EUInfo (lezen). datastructuur.

Integriteit

Onbevoegden kunnen gegevens muteren (schrijven).

Onbevoegden kunnen wijzigingen aanbrengen in de rekenregels, logica en datastructuur of de EUA verwijderen;

Gegevens uit brondocumenten worden onjuist of onvolledig ingevoerd. Digitale gegevens worden onjuist of onvolledig in de EUA ingevoerd (geimporteerd).

Wijzigingen in de rekenregels, logica, of datastructuur worden ongeautoriseerd aangebracht; De verwerking is onjuist/onvolledig door fouten in de rekenregels, logica of in de datastructuur (zoals bijvoorbeeld onjuiste koppelingen in Access).

De output wordt rechtstreeks De EUInfo wordt onjuist of onvolledig gemuteerd. Dit is vooral in Excel een geëxporteerd. groot risico. De output bevat fouten als gevolg van niet integere invoer of logica.

Het is niet te herleiden wie, wanneer, welke gegevens heeft gemuteerd.

De opzet en werking van de EUA is niet inzichtelijk; Het is niet te herleiden welke wijzigingen, wanneer, zijn aangebracht in de rekenregels/logica.

Er is geen audit-trail waardoor niet is te herleiden uit welke (bron)gegevens de output is opgebouwd; Reconstructie en aansluting met eerdere rapportages, bijvoorbeeld de toestand per 31-12-2009, is tijdrovend of onmogelijk; De EUA is niet voor controledoeleinden beschikbaar.

Controleerbaarheid

De risico’s zoals vermeld in de tabel bepalen uiteindelijk de beheersmaatregelen die getroffen moeten worden. Indien een risico niet of onvoldoende is onderkend, en er daardoor geen maatregelen worden getroffen om dat risico te mitigeren, bestaat de mogelijkheid dat het risico zich manifesteert en de informatievoorziening onbetrouwbaar is, met alle gevolgen van dien. In het ergste geval wordt zelfs diefstal van waarden mogelijk. Bewustzijn en het onderkennen van risico’s alsmede de positionering hiervan in de juiste context is dus essentieel. Ter nuancering wordt gemeld dat de mate van de te treffen maatregelen sterk afhankelijk zal zijn van de context waarbinnen een EUA wordt gebruikt. Zo zal een EUA die uitsluitend door één persoon wordt gebruikt met andere maatregelen zijn omgeven dan een EUA voor gemeenschappelijk gebruik. Een EUA voor één persoon hoeft immers geen authenticatie en autorisatie mechanismen te bevatten als deze zich in een persoonlijke directory van de gebruiker bevindt. Maar ook bij deze persoonlijke EUA’s zal de integriteit en controleerbaarheid van de EUI moeten worden gewaarborgd indien op basis daarvan beslissingen worden genomen en verantwoording plaatsvindt. Een oude wijsheid luidt bovendien: je moet geen kwartje uitgeven om een dubbeltje te beveiligen. De essentie hiervan is dat op basis van een rationele kosten/baten analyse bepaald moet worden wat het belang is van de EUA en de impact van onbetrouwbare EUInfo voor de operationele activiteiten, de besluitvorming en de verslaggeving. Het treffen van beheersmaatregelen en het naleven daarvan, kost immers ook geld en tijd. Deze inventarisatie en analyse valt buiten het kader van deze scriptie. 12 In deze scriptie wordt ervan uitgegaan dat de EUI belangrijk (bedrijfskritisch) is voor het ondersteunen van de dagelijkse operaties of de verslaggeving.

Samenvatting In het proces van EUI zijn drie fasen te onderkennen waarbinnen risico’s zich kunnen voordoen die de betrouwbaarheid van de EUI ondermijnen. Deze risico’s zijn te onderscheiden in risico’s voor de vertrouwelijkheid, integriteit en contoleerbaarheid. De risico’s zijn per fase samengevat in tabel 1. Hierna wordt op basis van de literatuur herleid welke beheersmaatregelen betrouwbare informatievoorziening kunnen waarborgen.

12

Bij de inventarisatie van het informatielandschap met daarbinnen de processen en de applicaties die deze processen

ondersteunen, moeten de relevante EUA’s in kaart worden gebracht.

11


2.2

Literatuurstudie

Beheersing van EUI betekent het implementeren van maatregelen die de betrouwbaarheid van de informatievoorziening waarborgen waardoor de risico’s voor de vertrouwelijkheid, integriteit en controleerbaarheid worden gemitigeerd. De relevante risico’s in het proces van EUI zijn in de voorgaande paragraaf behandeld. Op basis van literatuuroriëntatie is een selectie gemaakt van literatuur die waardevolle informatie bevat voor de beheersing van EUI. Dat zijn onder meer Bestuurlijke Informatieverzorging deel 1 Algemene grondslagen, de Code voor Informatiebeveiliging (NEN-ISO/IEC 17799:2005/27001), Microsoft Whitepaper13, de general-control processen volgens ITIL, een aantal artikelen over het gebruik van spreadsheets en VU collegemateriaal over onder meer applicatie-ontwikkeling.14 De voornoemde literatuur, alsmede persoonlijke praktijkervaringen en kennis uit het bijwonen van de VU colleges, zijn gebruikt bij de analyse van te treffen beheersmaatregelen ter waarborging van betrouwbare EUI. Hoewel de maatregelen primair ingaan op EUA’s die door middel van Excel zijn vervaardigd, geldt het overgrote deel van de maatregelen ook voor EUA’s die met behulp van Access zijn gebouwd omdat de principes identiek zijn. Database Access specifieke elementen, zoals het waarborgen van referentiële integriteit tussen stamgegevens en mutatiegegevens, alsmede de inrichting en koppeling van tabellen (als gevolg van het normaliseren) worden niet behandeld. Er is voor gekozen om de beheersmaatregelen die in de literatuur zijn aangetroffen te groeperen naar algemene maatregelen voor EUI, maatregelen van organisatorische aard en logische toegangsbeveiliging alsmede maatregelen voor de betrouwbaarheid van de invoer, verwerking en distributie. Dit is in de lijn van het proces van EUI.

2.2.1

Algemene beheersmaatregelen voor EUI

Beleid EUI De leiding van een organisatie dient (informatie)beleid te formuleren voor de ontwikkeling, het gebruik en beheer van EUA’s. De beheersmaatregelen hebben uitsluitend een kans van slagen als daarvoor beleid wordt uitgevaardigd en dit binnen de organisatie wordt ingebed en nageleefd. Een belangrijke voorwaarde om het beleid te laten slagen is het commitment van het management dat moet zorgdragen voor de juiste uitvoering en naleving van dat beleid.15 Het beleid dient onder meer in te gaan op het definiëren van bedrijfskritische EUA’s en de daarvoor te treffen maatregelen. Volgens PriceWaterhouseCoopers geldt als algemene richtlijn: hoe groter het gebruik en de complexiteit van de EUA, hoe belangrijker het is dat de informatie van de EUA betrouwbaar is, en dus hoe meer nadruk moet liggen op de te treffen beheersmaatregelen. 16 Indicatoren voor een hogere complexiteit zijn gebruik door meer dan een individu of afdeling, gebruik van macro’s, gebruik van formules die complexer zijn dan optellen, aftrekken, vermenigvuldigen of gebruik van berekeningen die niet of niet eenvoudig zelf zijn na te rekenen. Het gebruik van de EUA kan volgens PWC in drie soorten worden onderverdeeld: 1. Operationeel: de EUA wordt gebruikt ter ondersteuning of bewaking van operationele processen. Bijvoorbeeld een workflow systeem ter bewaking van tijdige verwerking van werkvoorraden. 2. Analytisch / Managementinformatie: de EUA wordt gebruikt als basis voor analyses en 13 14

Microsoft Whitepaper: Spreadsheet Compliance in the 2007 Microsoft Office System. Raamwerken die geen praktische waarde bevatten voor dit onderwerp zijn buiten beschouwing gelaten. Als

voorbeeld worden genoemd Coso en Cobit. In bijlage 1 is een korte samenvatting van deze raamwerken opgenomen omdat deze in de praktijk veelvuldig als beheersraamwerken worden genoemd. 15 Artikel Herken uw spreadsheet risico’s en Microsoft Whitepaper. 16 PWC: The use of Spreadsheets: Considerations for section 404 of the Sarbanes-Oxley Act.

12


3.

management beslissingen. Bijvoorbeeld: spreadsheets die gekoppeld zijn aan een grootboek en/of aanleverend systeem en worden gebruikt als basis voor cijferbeoordeling bij periode afsluiting. Financieel: de EUA wordt als basis gebruikt voor financiële transacties of voor de jaarrekening. Bijvoorbeeld: materiële vaste activa worden in Excel bijgehouden en de periodiek te boeken afschrijving wordt met dit Excel bestand berekend.

De complexiteit kan volgens PWC worden onderverdeeld in: 1. Laag: de EUA wordt alleen gebruikt voor elektronische registratie van gegevens. 2. Gemiddeld: de EUA maakt eenvoudige berekeningen met formules door bepaalde velden bij elkaar op te tellen of door de inhoud van twee velden met elkaar te vermenigvuldigen. 3. Hoog: met de EUA worden ingewikkelde berekeningen gemaakt, waarderingen bepaald of werkprocessen ondersteund. De EUA maakt vaak gebruik van macro’s, databasefuncties en aan elkaar gekoppelde werkbladen, cellen, waarden of velden. Deze EUA functioneert feitelijk als een echte applicatie.

2.2.2

Beheersmaatregelen van organisatorische aard en logische toegangsbeveiliging

Er is voor gekozen om de organisatorische maatregelen en toegangsbeveiliging afzonderlijk te behandelen omdat deze betrekking hebben op alle fasen van de EUI. De mate waarin de beheersmaatregelen worden geïmplementeerd is afhankelijk van de context waarbinnen de EUA wordt gebruikt. Voor de bedrijfskritische EUA’s met meerdere gebruikers dienen onderstaande uitgangspunten als minimum. 17 Organisatorische maatregelen: functiescheiding, rollen en verantwoordelijkheden De rollen, bevoegdheden en verantwoordelijkheden rond de ontwikkeling en het gebruik van de EUA dienen te zijn belegd. Duidelijk moet zijn wie de eigenaar is, wie wijzigingen mag aanbrengen, wie testbevindingen mag aftekenen of accepteren en wie bepaalt welke rechten worden toegekend aan welke (groepen van) gebruikers binnen de EUA. Bij het toekennen van rechten aan gebruikers dient rekening te worden gehouden met de controletechnische functiescheiding. Zo kan bijvoorbeeld functiescheiding worden aangebracht tussen het beheer van stamgegevens in de EUA en het muteren van gegevens; dit waarborgt de betrouwbaarheid van de EUInfo.18 Door deze maatregelen mogen alleen bevoegde gebruikers de gegevens muteren, raadplegen, de informatie delen, of wijzigingen aanbrengen in de rekenregels of databasetabellen. Hiermee wordt voorkomen dat onbevoegden toegang hebben tot de gegevens of rekenregels/databasetabellen. Eveneens worden hiermee de wijzigingen in de rekenregels of databasetabellen bewaakt. Technische maatregelen voor logische toegangsbeveiliging De volgende maatregelen kunnen worden genoemd: • Aan gebruikers dienen toegangsrechten te worden toegekend die nodig zijn voor uitvoeren van hun taken (leesrechten/schrijfrechten: Create, Read, Update, Delete). • Beperken van toegang tot de map (directory) op het netwerk waarin de EUA staat en de bestanden zijn opgeslagen. • Wachtwoordbeveiliging op toegang tot de functionaliteit van de EUA, toegang tot de logica, en toegang tot de databases. • Blokkeren of beschermen van cellen in een spreadsheet, bijvoorbeeld van cellen met formules. • De database van een MS Access EUA verborgen houden waardoor toegang voor gebruikers alleen via menu’s kan plaatsvinden. (Ten behoeve van de controleerbaarheid) • Voorzover mogelijk inbouwen van logging waardoor herleidbaar is welk (persoonsgebonden) 17 18

Microsoft Whitepaper en PWC: The use of Spreadsheets. Bestuurlijke informatieverzorging deel 1.

13


UserID op welk moment een bepaalde wijziging heeft aangebracht.

2.2.3

Beheersmaatregelen voor betrouwbare invoer

Invoercontroles moeten waarborgen dat de invoer van gegevens juist en volledig is. Met behulp van geprogrammeerde invoercontroles (applicatiecontroles) wordt voor zover mogelijk de invoer gecontroleerd. Enkele voorbeelden van geprogrammeerde invoercontroles zijn: 19 -Verplichte velden: de toepassing dwingt af dat een veld wordt ingevuld voordat naar een ander veld kan worden overgegaan. -Bestaanscontrole: de toepassing controleert of de ingevoerde waarde reeds bestaat. -Default-waarde: de toepassing laat voor een bepaald invoerveld een standaardwaarde zien, bijvoorbeeld de huidige datum. -Formaatcontrole: alfabetisch, numeriek, alfanumeriek, datum/tijd (Europees of Amerikaans). -Redelijkheidscontrole: limietcontroles of tolerantiecontroles. -Controletotaal: de toepassing telt het totaal van ingevoerde records (regels) en het totaal van een bepaalde veldwaarde die vergeleken worden met de in te voeren records/veldwaarde. Naast de geprogrammeerde controles kan het vier-ogen principe worden toegepast ter waarborging van de betrouwbare invoer. De ingevoerde gegevens worden bij het vier-ogen principe door een andere persoon gecontroleerd en goedgekeurd voor eventuele verdere bewerking. Handmatige invoer Bij handmatige invoer past de gebruiker zelfcontrole (of visuele controle) toe. Invoerfouten worden hersteld naar aanleiding van signalen op het beeldscherm van geprogrammeerde invoercontroles en op basis van evaluatie van de ingevoerde brondocumenten. Geautomatiseerde invoer Door middel van een speciaal daarvoor ontwikkeld programma wordt de klaargezette data ingevoerd (geïmporteerd) in de door de EUA te gebruiken database of tabel. Het programma dient te waarborgen dat de juiste velden uit het klaargezette bestand worden gehaald en in de juiste tabel van de EUA worden ingevoerd. Het grondig testen van deze importfunctionaliteit is daarom van essentieel belang. Deze functionaliteit maakt mede deel uit van de ontwikkeling van de EUA. De daarvoor te treffen beheersmaatregelen worden behandeld in paragraaf 2.2.4 ‘Beheersmaatregelen voor betrouwbare verwerking’. In verband met het specifieke belang voor de geautomatiseerde invoer van gegevens in de EUA is deze functionaliteit hier behandeld. Indien gegevens niet door de validatietest komen, bijvoorbeeld omdat het veld in de EUA maximaal 50 karakters kan bevatten en het veld van het aangeleverde bestand 60 karakters bevat, kan het programma verdere verwerking beëindigen en een foutmelding genereren, waarna nadere analyse moet plaatsvinden van het probleem. Gegevens die niet door de validatietest komen, kunnen ook worden weggeschreven in een foutenbestand en nader geanalyseerd. Door middel van een controletotaal kan worden bepaald of de gegevens juist/volledig zijn geïmporteerd.

2.2.4

Beheersmaatregelen voor betrouwbare verwerking

Volgens Microsoft blijkt uit wetenschappelijk onderzoek dat de ontwikkeling van spreadsheet EUA’s veel gemeen heeft met conventionele softwareontwikkeling.20 Beide tenderen niet alleen naar 19 20

Vu collegemateriaal april 2008 Application Controls d.d. 21 april 2008. Panko, R. en Nicholas O., Sarbanes-Oxley: What about All the Spreadsheets?, University of Hawaii, 2005.

14


dezelfde foutmarges maar ook naar hetzelfde profijt van een gedegen ontwikkelingslevenscyclus die ontwerp, testen en onderhoud omvat. Van oudsher heeft de ontwikkeling van spreadsheets nooit dezelfde aandacht gekregen als de ontwikkeling van andere bedrijfssoftware. Het gevolg is dat spreadsheets die belangrijke aspecten van de bedrijfsvoering ondersteunen, vaak de noodzakelijke beheersmaatregelen missen. Microsoft stelt dat de oplossing eenvoudig is door bedrijfskritische spreadsheets op dezelfde manier te benaderen als de ontwikkeling van bedrijfssoftware. Benader de ontwikkeling van bedrijfskritische EUA’s op dezelfde manier als de ontwikkeling van bedrijfssoftware en volg daarbij een standaard software ontwikkelmethodiek. Een mogelijke benadering voor de ontwikkeling van EUA’s is een methodologie naar analogie van traditionele systeemontwikkelingscyclussen zoals de waterval methode. Kenmerkend voor deze vorm is dat altijd sprake is van een systematische, gestructureerde aanpak waarbij een aantal fasen kunnen worden onderscheiden die achtereenvolgens doorlopen moeten worden. Dit is weergegeven in figuur 5 (waterval methode). 21

Figuur 5: Traditionele softwareontwikkelingsfasen

De benadering die Microsoft hanteert en gebaseerd is op de traditionele softwareontwikkeling wordt hierna behandeld.

2.2.4.1 Eisen formuleren Als startpunt wordt genomen het formuleren van de eisen waaraan het spreadsheetmodel moet voldoen. Tijdens deze fase wordt in detail beschreven wat het doel is van het spreadsheet; onder meer de functies van het spreadsheet en de relatie met het bredere bedrijfsproces. In deze fase wordt ook aangegeven wat de reikwijdte en de grenzen van het spreadsheet zijn, om te voorkomen dat het spreadsheet tijdens de ontwerpen ontwikkelingsfase uit zijn voegen groeit. Eveneens moet in deze fase door de afzonderlijke spreadsheetgebruikers worden gevalideerd dat het model aan hun behoeften tegemoet komt.

2.2.4.2 Ontwerpen In de ontwerpfase wordt een gedetailleerd plan opgesteld voor implementatie van de eisen die in de eerste fase zijn geformuleerd. Het resultaat is een blauwdruk van het spreadsheet. Deze blauwdruk beschrijft de formules en functies, die ten grondslag liggen aan de logica en indeling van het spreadsheet. Goed ontworpen spreadsheets hebben volgens Microsoft de volgende kenmerken: • Een duidelijke, zichtbare scheiding tussen invoer-, uitvoeren rekencellen. Dit kan worden bereikt via indeling, plaatsing en opmaak. • Vergrendelde en beveiligde cellen die niet kunnen worden gewijzigd. • Een standaardmethode van inrichting. Bijvoorbeeld een top-down benadering waarbij formules nooit kunnen verwijzen naar lager gesitueerde cellen. • Standaardbenamingen in het hele spreadsheet. • Benoemde bereiken om het aantal fouten te beperken en de leesbaarheid van formules te 21

Andere benamingen in de praktijk van de fasen zijn: Informatieplanning/analyse/definitiestudie, Functioneel ontwerp, Technisch ontwerp, Bouwen, Testen, Implementeren/conversie, Onderhouden.

15


• •

vergroten. Eenvoudige formules. Dit kan worden bereikt door complexe logica op te splitsen en te verdelen over meerdere cellen. Uitgebreide toelichtingen in het hele spreadsheet. Bijvoorbeeld: ingebed commentaar, inhoudsopgaven en legenda’s ter verduidelijking van structuur en indeling.

In de ontwerpfase is het noodzakelijk eventuele feedback van de spreadsheetgebruikers te verwerken. Dit waarborgt dat de definitieve blauwdruk flexibel genoeg is voor gebruiksdoeleinden en voldoende strikt in termen van organisatorische controles.

2.2.4.3 Bouwen/Ontwikkelen Zodra de blauwdruk is gemaakt en gevalideerd, kan het spreadsheet worden ontwikkeld. Als de eerste twee fasen zorgvuldig zijn doorlopen en een hoge mate van detaillering hebben opgeleverd, resteert het assembleren van de onderdelen zoals beschreven in de spreadsheetblauwdruk. Alleen personen die deskundig zijn op het gebied van de spreadsheet of database tool mogen de EUA wijzigen.

2.2.4.4 Testen en verifiëren Het testen en verifiëren van het spreadsheet is essentieel om te waarborgen dat de EUA betrouwbare informatie oplevert. De EUA kan op verschillende manieren worden getest: gerichte controles, testcase-verificatie, het testen van scenario’s en het controleren van de code. Ongeacht de gekozen methode, dienen tests tijdens de implementatiefase regelmatig te worden uitgevoerd, en wel door andere personen dan de ontwikkelaars van het spreadsheet.

2.2.4.5 In gebruik nemen Bij het in gebruik nemen van de EUA zijn een aantal aandachtspunten waarmee rekening dient te worden gehouden. Dit zijn bijvoorbeeld: • de formele overzetting naar de productieomgeving; • het maken van reservekopieën van de bronbestanden; • het onderbrengen op een beveiligde locatie met functionaliteit voor het beheer van bestandstoegang; • het afmelden van ontwikkelaars, testers en gebruikers; • het formaliseren van versiebeheer; • het schrijven van een gedetailleerde gebruikershandleiding; • het ontwikkelen van trainingscursussen; • het trainen en opleiden van gebruikers van de EUA.

2.2.4.6 Beheer van wijzigingen en onderhoud Er dienen maatregelen te worden getroffen om te waarborgen dat wijzigingen in een EUA gecontroleerd worden aangebracht. Beheersmaatregelen hiervoor zijn: 22 • Alleen door de eigenaar van de EUA geautoriseerde wijzigingen mogen worden doorgevoerd. • Alleen geautoriseerde (en gekwalificeerde) ontwikkelaars mogen de EUA wijzigen. • Testen van de wijziging dient plaats te vinden door iemand die niet zelf de wijziging heeft doorgevoerd. Overwogen kan worden om periodiek de logica (rekenregels, formules, e.d.) te laten beoordelen door iemand die niet zelf gebruiker of ontwikkelaar van de EUA is (logica review). • Formele acceptatie van de wijziging door iemand die niet zelf de wijziging heeft doorgevoerd. • Documenteren en archiveren van behandelde wijzigingsverzoeken en bijbehorende testbevindingen en de formele acceptatie. • Versiebeheer: zorg via naamconventies en gebruik van een duidelijke folderstructuur ervoor dat alleen de actuele en geaccepteerde versies in gebruik zijn. 22

Presentatie: From record tot report.

16


•

Het is aan te bevelen dat meer dan één persoon goede kennis heeft van de EUA in verband met continuïteitsaspecten.

2.2.4.7 Documenteren Onderhoud en documentatie zijn essentieel voor de bruikbaarheid van een EUA op de lange termijn en de controleerbaarheid daarvan. Gebruikers, ontwikkelaars en testers, alsmede controlerende instanties, kunnen aan de hand van documentatie een duidelijk beeld krijgen van doel en werking van de EUA. De EUA dient te worden ondersteund door functionele en technische documentatie. In deze documentatie is in detail de functionaliteit beschreven vanuit het perspectief van het bedrijfsproces en vanuit technisch perspectief; gegevens input en output, rekenregels of databasestructuur, en interactie met andere systemen. Gebruikersdocumentatie moet de gebruikers (na een storing of bij uitval van een collega) ondersteunen met het begrijpen, bedienen en beheren van de EUA. Documentatie bij bedrijfskritische spreadsheets dient in ieder geval de volgende informatie te bevatten: 23 • een overzicht van wijzigingen, inclusief vermelding van zowel de personen die de wijzigingen hebben aangebracht, als de gevolgen van de wijzigingen voor het spreadsheet; • een gedetailleerde beschrijving van het doel van het spreadsheet; • ingebed commentaar als toelichting bij alle invoer-, uitvoeren rekencellen; • een beschrijving van de standaardbenamingen in het spreadsheet; • een legenda ter verklaring van de opmaak die in het spreadsheet is gebruikt; • een gebruikshandleiding met tekst en uitleg bij het juiste gebruik van het spreadsheet, inclusief voorbeelden van invoeren uitvoerwaarden; • contactgegevens van de persoon die het spreadsheet heeft ontwikkeld en eerstverantwoordelijke is.

2.2.5

Beheersmaatregelen voor betrouwbare output

Ondanks maatregelen die de betrouwbaarheid van de ingevoerde en verwerkte gegevens kunnen waarborgen, kan de EUInfo alsnog onjuistheden bevatten. Door middel van cijferbeoordeling/cijferanalyses op de (verbanden tussen) gegevens kan gesignaleerd worden of er fouten in de rekenregels of gegevens voorkomen. 24 Teneinde te kunnen voldoen aan de eis van controleerbaarheid kunnen de volgende maatregelen worden ingevoerd. De audit-trail (controle-spoor) naar de brongegevens kan worden gewaarborgd door bijvoorbeeld het unieke kenmerk van het brondocument of brondata in de EUA op te nemen zodat vanuit de EUInfo is terug te herleiden uit welke brongegevens de EUInfo is opgebouwd. Van de EUA’s die specificaties of rapporten van gegevens opleveren voor het verslaggevings- of aangifteproces moet per periode een kopie worden opgeslagen. Hierbij dient bijvoorbeeld gedacht te worden aan de specificatie van de afschrijvingsberekening van de materiële vaste activa of samenstelling van de omzetbelastingaangifte. De informatie in deze kopie dient blijvend aan te sluiten op de gerapporteerde gegevens, daarom is het aan te bevelen deze bestanden als read-only te archiveren. Dit geldt met name voor EUA’s die continu worden bijgewerkt. Raadzaam is om een duidelijke omschrijving op te nemen met vermelding van bestandsnaam, titel, datum en de verantwoordelijke gebruiker; bijvoorbeeld MVA311209Memedov.xls. Periodiek moet een back-up worden gemaakt van de EUA en de gearchiveerde bestanden om te waarborgen dat de informatie mede voor controledoeleinden beschikbaar blijft.

23 24

Microsoft Whitepaper. Ter illustratie: als uit ervaring bekend is dat een gegeven niet meer dan 100.000 kan bedragen, dan moet uit

cijferanalyse op de output opvallen als bij dat gegeven 200.000 staat (want dat is 2x zoveel als gebruikelijk).

17


2.2.6

Beheersmaatregelen voor betrouwbare distributie

De EUInfo dient door een bevoegd persoon aan de geautoriseerde gebruiker ter beschikking te worden gesteld. Dit kan op meerdere manieren. Eenvoudige oplossingen zijn de EUInfo te printen en persoonlijk te overhandigen, per post te verzenden of binnen het eigen netwerk als bestand in Xls formaat per e-mail te verzenden. Bij te grote bestanden kan de EUInfo in een directory worden geplaatst waar uitsluitend de geautoriseerde gebruiker de bestanden kan ophalen.25 In sommige EUA’s wordt de mogelijkheid ingebouwd om data naar Xls formaat te exporteren. In een menu kan dan eerst een selectie van de gewenste velden worden gemaakt en vervolgens de selectiecriteria en de sorteervolgorde worden opgegeven. Door een fout in de programmeercode kan de inhoud van verkeerde velden worden opgehaald, en gepresenteerd en gedistribueerd. Het grondig testen van deze selectie- en exportfunctionaliteit is daarom van essentieel belang. Deze functionaliteit maakt mede deel uit van de ontwikkeling van de EUA. De daarvoor te treffen beheersmaatregelen zijn behandeld in paragraaf 2.2.4 ‘Beheersmaatregelen voor betrouwbare verwerking’. In verband met het specifieke belang voor de distributie van EUInfo is deze functionaliteit hier behandeld.

Samenvatting In paragraaf 2.1 is bepaald welke risico’s de betrouwbaarheid van de EUI ondermijnen in de te onderscheiden fasen invoer, verwerking en distributie. Deze risico’s zijn onderverdeeld naar de drie betrouwbaarheidsaspecten: vertrouwelijkheid, integriteit en controleerbaarheid. Vervolgens is op basis van literatuuronderzoek bepaald welke normen en maatregelen van toepassing kunnen zijn teneinde de betrouwbaarheid van EUI te waarborgen. Deze normen en maatregelen zijn in de lijn van de fasen van EUI gegroepeerd en behandeld: algemene maatregelen voor EUI, maatregelen van organisatorische aard en logische toegangsbeveiliging en maatregelen voor de betrouwbaarheid van de invoer, verwerking en distributie. Hiermee is deelvraag 1 uit hoofdstuk één beantwoord: ‘Welke beheersmaatregelen waarborgen volgens de literatuur betrouwbare EUI?’

25

Het distribueren en presenteren in Pdf formaat, in HTML code of opmaak die geschikt is voor een mobiele device

behoren eveneens tot de mogelijkheden, maar worden in dit kader verder niet behandeld.

18


Voor het totaaloverzicht zijn de eerder beschreven risico’s en maatregelen samengevoegd in tabel 2. Hierdoor is in één oogopslag te zien welke beheersmaatregel dient ter afdekking van een risico.

Tabel 2: Risico’s en maatregelen voor betrouwbare EUI

19


3

Casestudies

In dit hoofdstuk worden de praktijkcases beschreven die op basis van interviews zijn verkregen. Hierbij is voor zover mogelijk inzicht gekregen in de toepassingsvormen, de redenen en overwegingen voor het gebruik van EUI en de getroffen beheersmaatregelen.

3.1

Casus niet-routinematige processen

Interviews gehouden in de periode december 2008/januari 2009 met vier registeraccountants die werkzaam zijn in de openbare praktijk en de Belastingdienst. Uit gesprekken met registeraccountants is inzicht gekregen in veel voorkomende toepassingen van EUA’s. Gebleken is dat veel EUA’s worden gebruikt in het verslaggevingstraject en betrekking hebben op de niet-routinematige processen. De volgende voorbeelden zijn genoemd: 26 • Managementinformatie, met toevoeging van tekst en analyses ten opzichte van de begroting over bijvoorbeeld de omzetontwikkeling per productgroep, per divisie, per regio, per vierkante meter alsmede over personeelsmutaties, ziekteverzuim, etcetera. • Vastlegging van materiële vaste activa en berekening van de periodieke afschrijvingspost.27 • Berekening van voorzieningen, zoals garantievoorziening, voorziening grootonderhoud, vakantiedagenvoorziening, en de daarmee corresponderende kostenpost. • Analyse van debiteurenouderdom en berekening van de voorziening voor dubieuze debiteuren en de daarmee corresponderende kostenpost. • Analyse van goederenposities en berekening van voorzieningen en afwaarderingen. • Consolidatie van twee of meer jaarrekeningen met verwerking van eliminatieposten. • Extracomptabele vastlegging van fiscale boekwaarden. • Consolideren van omzetbelastinggegevens van meerdere filialen voor de OB aangifte. • Netto contante waardeberekeningen ten behoeve van investeringsbeslissingen, bedrijfsovernames en impairmenttests waaruit eventueel een afwaarderingspost volgt. • Berekening van te verstrekken jaarkortingen aan afnemers op basis van de jaarafzet en de daarmee corresponderende verplichting, alsmede berekeningen van zelf te ontvangen kortingen. • Berekeningen van fiscaal niet aftrekbare rente en de daarmee corresponderende journaalpost. • Samenstelling en berekening van te activeren kosten bij acquisities en fiscaal aftrekbare financieringskosten. • Berekeningen van te verdelen concernkosten naar rato van een bepaalde verdeelsleutel, en de daarmee corresponderende boeking. • Berekeningen voor diverse fiscale regelingen zoals: de kantineregeling en de integratieheffing voor de omzetbelasting, beschikbaar gestelde telefoons en de 80-maaltijdenregeling voor de loonbelasting, het constante deel van de algemene kosten voor de waardering van het onderhandenwerk of het buitenlandse vaste inrichtingsresultaat in de vennootschapsbelasting.

3.1.1

Reden gebruik EUA

Als reden voor het gebruik van EUA werden genoemd: het kostenaspect, de geringe frequentie van de informatiebehoefte, de beperkte hoeveelheid data en de niet vast omlijnde informatiebehoefte. Er wordt gebruik gemaakt van een EUA omdat de administratie er vaak niet op is ingericht om in een 26

EUA’s in de vorm van spreadsheets variëren in de praktijk van eenvoudige berekeningen tot complexe modellen

bestaande uit meerdere werkbladen met macro’s, verwijzingen naar andere werkbladen en complexe formules. 27 Deze (niet-routinematige) posten leiden in de financiële administratie tot een zogenaamde memoriaalboeking. Om de betrouwbaarheid van deze boekingen te beheersen dient autorisatie voor de boeking plaats te vinden door de proceseigenaar/business en registratie hiervan door de financiële administratie. Het belang van archivering en dossiervorming (onderbouwing) van deze posten wordt versterkt door de omvang van het ermee gemoeide bedrag.

20


bepaalde informatiebehoefte te voorzien. Dit kan zijn omdat de betreffende gegevens niet afzonderlijk worden vastgelegd, bijvoorbeeld omdat deze in één totaal worden opgenomen, of omdat de programmatuur het vastleggen hiervan niet ondersteunt. De alternatieve oplossing is uit kosten/baten overwegingen daarom vaak het bouwen van een EUA waarin de gewenste informatie, buiten het formele systeem, wordt geproduceerd. De relatief geringe periodiciteit van de informatievoorziening en het wisselende karakter van de informatiebehoefte, maken het uit economische overwegingen niet opportuun om de informatievoorziening te formaliseren. 28 Ook al zijn daarmee grote belangen gemoeid.

3.1.2

Maatregelen

Meestal wordt pas bij de jaarrekeningcontrole door de externe accountant de EUInfo inhoudelijk getoetst. De externe accountant sluit de gegevens in de managementrapportages en kritische posten in de verslaggeving aan met de brondata. Ook beoordeelt hij de logica en rekenregels in de EUA op inhoudelijke juistheid en rekent hij de berekeningen in de EUA na. Deze werkzaamheden zijn gegevensgericht omdat er vaak geen organisatorische beheersmaatregelen zijn waarop gesteund kan worden en die systeemgerichte controles mogelijk maken. Als de externe accountant uit hoofde van zijn jaarrekeningmaterialiteit de EUInfo niet belangrijk genoeg vindt, dan wordt de EUInfo in het geheel niet beoordeeld en zal dit pas bij een belastingcontrole, eveneens gegevensgericht, worden gecontroleerd. Voorzover de beheerder van de EUA alle rechten heeft binnen een EUA, wordt door middel van aanvullende procedures gewaarborgd dat hij geen waarden aan de onderneming kan onttrekken. Als voorbeeld is genoemd: de feitelijke betalingen die door de leiding plaatsvinden met kennisname van de onderliggende facturen en de daarop vermelde rekeningnummers. Een ander voorbeeld is de periodieke analyse van de EUInfo met het budget of de begroting, waar eventuele bijzonderheden uit kunnen blijken. De beheerder van de EUA heeft meestal het vertrouwen van de leiding (soft-control), dat ook gebaseerd is op de inschatting dat een beheerder geen belang heeft bij het doelbewust manipuleren van de EUA.

3.1.3

Rest-risico’s

De betrouwbaarheid van de EUInfo wordt in de praktijk door de gebruiker gegarandeerd. In de praktijk is dit meestal een financieel manager, fiscaal manager of (concern)controller. Deze gebruiker heeft de toepassing zelf gebouwd, zelf getest, zelf tussentijds gewijzigd, en gebruikt deze voor de informatievoorziening. Het betreft vaak een persoonlijke EUA. Door de leiding wordt vaak blind erop vertrouwd dat de informatie die de manager/controller presenteert betrouwbaar is. Dit is gebaseerd op vertrouwen in zijn deskundigheid en zorgvuldigheid. De integriteit van de informatie is objectief bezien niet gewaarborgd. Fouten in de EUI kunnen pas laat worden ontdekt, waardoor de schade voor de organisatie reeds kan zijn veroorzaakt. De betrouwbaarheid van de EUI is vaak volledig afhankelijk van het beheersingsbewustzijn van de gebruiker (bouwer).

28

Bijvoorbeeld door aanpassing of uitbreiding van bestaande programmatuur, aanschaf van nieuwe programmatuur of

het zelf (laten) bouwen van maatwerkprogrammatuur.

21


De leiding van een organisatie is zich vaak niet bewust van de risico’s. Veelal worden risico’s echter ook aanvaard op grond van een kosten/baten afweging (kosten van de maatregelen in relatie tot het voordeel daarvan). De leiding accepteert risico’s met als argumentatie: ‘het werkt al jaren goed zo en de beheerder is betrouwbaar’, ‘één persoon die zonder tal van procedures bij de EUA kan is praktisch en kostenefficiënt’ en ‘de impact op de continuïteit is gering en het onttrekken van waarden is afgedekt’.

Er zijn vaak geen formele procedures over archivering en dossiervorming van de EUInfo. Hierdoor kunnen met name bij fiscale controles over het verleden problemen ontstaan ten aanzien van de controleerbaarheid van de gegevens en onderbouwing van de verantwoorde posten.29 Documentatie over de opbouw en werking van de EUA is er eveneens niet, waardoor overdracht van het beheer van de EUA tot een probleem kan leiden. Bovendien wordt de controle bemoeilijkt omdat niet eenvoudig inzicht kan worden verkregen in de opzet en werking van de EUA.

3.2

Casus vliegtuigonderhoud

Interview gehouden op 6 januari 2009 met een voormalig gebruiker (accountmanager) van een EUA, werkzaam bij een organisatie die vliegtuigen verhuurt. De activiteiten van deze organisatie bestaan uit het verhuren (leasen) van vliegtuigen. Van contracten worden samenvattingen van de highlights gemaakt in MS Word. Hierin is onder meer de (juridisch) relevante informatie opgenomen voor de accountmanager. De voorraad vliegtuigen was verdeeld over een aantal accountmanagers. Voor ieder vliegtuig was een directory (map) aangemaakt waarin een aantal Excel spreadsheets waren opgenomen. De belangrijkste hiervan waren: • Een spreadsheet met een overzicht van te factureren termijnen (rental schedule). • Een spreadsheet voor het berekenen van de onderhoudsreservering van de motor. • Een spreadsheet voor het berekenen van de onderhoudsreservering van het onderstel. • Een spreadsheet voor het berekenen van de onderhoudsreservering van het vliegframe. Ieder soort onderhoudsreservering (maintenance reserve) werd bepaald op basis van grootheden die voor dat type onderhoud en voor een bepaald type vliegtuig relevant was. De uitgaven voor onderhoudskosten van een vliegtuigmotor zijn bijvoorbeeld aanzienlijk hoger dan die van het vliegframe. Onderhoud aan de motor moet gemiddeld om de twee á drie jaar worden uitgevoerd en aan het vliegframe gemiddeld om de 10 jaar. Daarnaast kent een type vliegtuig een bepaald aantal gemiddelde vlieguren per jaar en een gemiddeld aantal landingen. Op basis van deze grootheden wordt onder andere het tarief per vlieguur berekend voor de reservering voor motoronderhoud. Dit gebeurde in het spreadsheet van Motoronderhoudreservering. Zo werden bijvoorbeeld van de Airbus A320-200 met motor CFM65-5A1 de reserveringskosten per vlieguur begroot op basis van: onderhoudskosten van motor CFM65-5A1 (marktgegevens) gedeeld door gemiddeld aantal vlieguren per jaar (marktgegevens). De huurder van het vliegtuig (lessee) diende op basis van het contract maandelijks een opgave naar de accountmanager te sturen van de werkelijk gevlogen vlieguren. Dit is essentieel omdat op basis van de werkelijk gevlogen uren, vermenigvuldigd met het onderhoudstarief, de voorschotfacturering plaatsvindt voor de reservering van onderhoudskosten. De accountmanager voerde de werkelijk gevlogen vlieguren in het spreadsheet in, waarop een bedrag volgde voor de in rekening te brengen onderhoudsreserveringskosten. Een overzicht van deze bedragen werd door de accountmanager aan de administratie doorgegeven. 29

De openbare accountant beoordeelt de administratie vaak in het verslagjaar zelf (interimcontrole) of kort na afloop

van het verslagjaar waardoor de oorspronkelijke gebruiker nog toelichting kan geven op de EUInfo.

22


De administratie zorgde vervolgens voor de facturering en vastlegging in het grootboek. Er is dus een aantal grootheden dat per type vliegtuig en per type motor moet worden vastgelegd in de diverse spreadsheets.

3.2.1

Reden gebruik EUA

De organisatie maakte gebruik van spreadsheets omdat voor de bedrijfsactiviteit de rekenfaciliteit en snelheid benodigd waren. Excel kan snel en gemakkelijk rekenen en vereist geen specifieke deskundigheid. Voor deze bedrijfsprocessen was geen standaardpakket te koop en er ontbrak destijds tijd en geld om een applicatie te laten bouwen, evenals de know-how om zelf iets te bouwen. Dit, ondanks het feit dat het belang zeer materieel was en er in totaal een kleine honderd vliegtuigen werd verhuurd.

3.2.2

Risico’s

De organisatie heeft zelf de volgende problemen en risico’s onderkend: 1. Er was geen uniformiteit in de opzet van de spreadsheets: de gebruiker bouwde het spreadsheet op volgens zijn/haar denkstappen, de lay-out was verschillend, de ‘zichtbare’ stappen in de spreadsheets verschilden. 2. Hierdoor vergde het ‘lezen’ van ieder spreadsheet tijd; men moest zich verdiepen in de opbouw, werking en logica van het spreadsheet. Bij de één werden stappen overgeslagen en waren ingebakken in formules, bij de ander waren alle opeenvolgende stappen inzichtelijk gemaakt. 3. De know-how over de opbouw van het spreadsheet zat in het ‘hoofd’ van de accountmanager. Dit gaf een risico exposure als deze persoon weg zou vallen. 4. Soms was een spreadsheet op de harde schijf van de pc van de accountmanager opgeslagen en niet op het netwerk. Als bij afwezigheid van die persoon informatie uit dat spreadsheet nodig was, kon niemand daar bij, waarna de beheerder de pc moest kraken. 5. Sommige spreadsheets bevatten een totaalblad. Het is voorgekomen dat in een tabblad een rij of kolom werd tussengevoegd, waardoor de link van dat tabblad naar het totaalblad verdween en de gegevens in het totaalblad niet meer juist waren. Op de grote getallen valt dan niet meer op of het 100 miljoen of 100 miljoen plus een paar honderdduizend had moeten zijn. 6. Er werden risico’s gelopen ten aanzien van: -de correcte werking van het spreadsheet; -de juiste invoer van de (stam)gegevens (de juiste grootheden bij het juiste type vliegtuig en juiste type motor); -de blijvende correcte werking van het spreadsheet en juistheid van de gegevens (het per ongeluk wijzigen of wissen van cellen, kolommen en rijen kon onopgemerkt blijven); -controleerbaarheid: er kon achteraf niet meer worden nagegaan wat er in het spreadsheet was gewijzigd, wie dat had gedaan en wanneer dat was gedaan. 7. Er was geen totaaloverzicht en het samenvoegen van de informatie uit die honderden spreadsheets was een tijdrovende aangelegenheid waarbij ook vaak dubbel werk werd verricht.

3.2.3

Maatregelen

Het risico op de juiste werking van het spreadsheet werd in de praktijk ondervangen door bij een collega langs te lopen en te vragen of hij even wilde kijken of het ‘goed’ was. In feite is dit een vorm van review of test door een collega, maar met een grote vrijblijvendheid en geen formele status. Hiervan werd ook niets vastgelegd. Management informatie en beheersing vonden plaats door middel van user controls en veelvuldig overleg tussen de accountmanagers en de financieel directeur en commercieel directeur. Bovendien bestond er een grote mate van vertrouwen in de deskundigheid van de accountmanagers. Dagelijks werd een back-up gemaakt van het netwerk om de continuïteit zeker te stellen.

23


Software ontwikkeling Een aantal jaren geleden is besloten om middelen vrij te maken om zelf software te gaan ontwikkelen voor de ondersteuning van de bedrijfsactiviteiten. Dit is gedaan in Microsoft SQL Server die draait op een (dot).net platvorm. Voornaamste reden hiervoor was dat door de groei van het aantal vliegtuigen (meer dan honderd) het totaaloverzicht er niet meer was en het relatief veel tijd kostte om dat totaaloverzicht op te bouwen. De functionaliteiten en informatievoorziening die voorheen verspreid waren in Word (highlights van de contracten) en de omvangrijke hoeveelheden spreadsheets, worden nu centraal in de database opgeslagen en kunnen direct worden getoond. Dit maakt het ondermeer mogelijk om direct inzicht te krijgen in het totaal van door te berekenen vlieguren, maar ook in verschillen op totaalniveau tussen gebudgetteerde tarieven en contractueel afgesproken tarieven. Dit blijkt met name van belang te zijn als zich continuiteitsrisico’s voordoen bij de huurder en het vliegtuig wordt teruggehaald. Als er dan nog noodzakelijk onderhoud moet worden verricht en er te weinig is gereserveerd, dus in rekening gebracht aan de huurder, komen de kosten voor rekening van de verhuurder. Daarnaast wordt in de applicatie functiescheiding gewaarborgd en is de audit-trail gegarandeerd; er is een registratie van wat de data was, wat het is geworden, door wie het is gewijzigd op welke dag en op welk tijdstip. Dit geldt ook voor de wijzigingen die in de software worden aangebracht. De autorisaties zijn op rollen gebaseerd (role-based). Voorts is er een helpdesk en zijn er procedures voor recovery. Door het ontwikkelen van deze nieuwe applicatie is de organisatie in de gelegenheid gekomen om met dezelfde hoeveelheid mensen de verhuur- en onderhoudsadministratie van meer vliegtuigen bij te houden. Inmiddels wordt de software ook in licentie ter beschikking gesteld aan derden die zelf hun vliegtuigadministratie kunnen voeren en wordt naast voor de eigen organisatie ook voor derden de verhuur- en onderhoudsadministratie gevoerd. De software draait op een co-locatie (datacenter) in Amsterdam waar een klant in zijn eigen database kan inloggen. Met de klant zijn tevens SLA’s afgesloten. De organisatie is thans bezig om een SAS70 certificering te krijgen omdat voornamelijk klanten uit de Verenigde Staten die SOx compliant werken hierom vragen.

Samenvatting Excel is hier gebruikt ter ondersteuning van de primaire processen. Er waren grote risico’s voor de integriteit en controleerbaarheid. De bedrijfsactiviteiten werden beheerst doordat directeuren veel aandacht en tijd besteedden (communiceerden) met de accountmanagers en er door de administratie veel cijferbeoordelingen/cijferanalyses werden verricht. Het opbouwen van totaaloverzichten uit de grote hoeveelheden spreadsheets van de diverse accountmanagers om inzicht te krijgen in een bepaalde positie (exposure) was tijdrovend en gevoelig voor fouten. Door de groei van de activiteiten is het verkrijgen van inzicht in de gewenste informatiebehoefte voor het management, voor sturing en besluitvorming, een tijdrovende aangelegenheid geworden. De grenzen van het beheersbare werden gevoeld, waarna is besloten om een eigen pakket te ontwikkelen. De IT, in de vorm van het nieuw ontwikkelde softwarepakket en de database, heeft bij deze organisatie ervoor gezorgd dat: a. Met dezelfde groep mensen aanzienlijk meer vliegtuigen kunnen worden geadministreerd. Groeipotentieel is hierdoor toegenomen doordat zowel voor de eigen organisatie meer vliegtuigen kunnen worden geadministreerd maar ook het administreren voor derden mogelijk is. b. Het mogelijk is geworden de applicatie als product aan anderen te verkopen. c. De informatievoorziening betrouwbaarder en sneller kan plaatsvinden waardoor snel en gerichter op de bedrijfsactiviteiten kan worden ingespeeld en gereageerd.

24


3.3

Casus pensioenverzekeraar

Interview gehouden op 16 januari 2009 met een interim controller bij een pensioenverzekeraar. Bij een pensioenverzekeraar is de continuïteit en betrouwbaarheid van de geautomatiseerde gegevensverwerking onderzocht door de interim controller in het kader van de jaarrekeningcontrole. Op meerdere plekken is hij Excel/Access applicaties tegengekomen. Hieronder worden twee door een afdeling zelf gebouwde applicaties (EUA’s) beschreven. Waardeoverdracht Het waardeoverdrachtproces ziet op het overnemen van pensioenverplichtingen van een (bedrijfs)pensioenfonds bij uittreding van een verzekerde. Het registreren van pensioenen vindt plaats in standaardprogrammatuur voor polisregistraties. De applicatie bezit niet de functionaliteit van het registreren van waardeoverdrachten. Het verzoek van de afdeling collectief pensioenbeheer om de applicatie uit te breiden met deze functionaliteit werd door de directie afgewezen omdat het te duur zou zijn. De afdeling heeft toen besloten zelf een toepassing te ontwikkelen in Access. De toepassing is door één persoon gebouwd. Dezelfde persoon voert het beheer en onderhoud uit. Verzoeken voor wijzigingen ontvangt hij per e-mail. De Access toepassing ondersteunt het primaire proces operationeel door het bieden van workflow ondersteuning van de correspondentie rond waardeoverdrachten. De ontvangst van een verzoek van een bedrijf tot waardeoverdracht wordt in de toepassing vastgelegd. De verwerking van het verzoek (ontvangstbevestiging, offerte en ontvangen brieven) en de voortgangsbewaking vinden eveneens in de toepassing plaats.

Uitkeringen bij ingaan pensioenen Het systeem genereert een signaal als een pensioen ingaat. Deze bevat geen functionaliteit om het traject van uitkeren dat volgt af te handelen. De brieven met uitkeringsgegevens die door het systeem worden gegenereerd worden handmatig ingevoerd in een Access toepassing. De Access toepassing functioneert als een doorgeefluik naar CMG. CMG is een extern bureau dat de bruto-netto uitbetalingen van ingegane pensioenen berekent. Berekeningen inzake doorbelastingen, voorschotbetalingen, correcties met terugwerkende kracht en verdere informatie worden in de Access toepassing vastgelegd.

3.3.1

Reden gebruik EUA

De standaardprogrammatuur ondersteunt niet de gewenste functionaliteit en voor uitbreiding daarvan is geen geld beschikbaar.

3.3.2

Maatregelen

De maatregelen die in de MS Access toepassing zijn getroffen, zijn: - toepassing van het 4-ogen principe; - logging van mutaties, die door een derde worden beoordeeld; - functiescheiding tussen de registratie van vaste gegevens en het muteren van variabele gegevens; - invoer van uitsluitend geautoriseerde brondocumenten; - toegang tot de applicatie en data is beperkt tot bepaalde gebruikers; - periodiek testen van de beheersingsmaatregelen.

3.3.3

Rest-risico’s

Er is geen documentatie over de werking van de EUA en de integriteit van de EUA berust op vertrouwen in de bouwer.

25


3.4

Casus ATK

Interviews gehouden in januari 2009 met gebruikers en ontwikkelaars/beheerders van een EUA bij de Belastingdienst. Deze casus beschrijft de evolutie van een EUA.

3.4.1

Het Controlebestand

Van procesgericht naar risicogericht werken De systemen van de Belastingdienst zijn van oorsprong systemen die voor een proces zijn gebouwd. Ieder middel heeft zijn eigen systeem waarin de aangiften, aanslagen en bezwaren staan. Zoals bijvoorbeeld het middel Vennootschapsbelasting, de Inkomstenbelasting, de Omzetbelasting, de Loonbelasting. Daarnaast zijn er systemen waarin uitgevoerde belastingcontroles worden bijgehouden en een systeem voor de NAW-gegevens. De informatie uit de diverse processystemen wordt verzameld en getoond in het systeem IKB (Individuele Klant Behandeling), dat fungeert als een klantinformatiesysteem. In dit systeem kan op klantniveau (aangifteplichtige) inzicht worden verkregen in de informatie die in de afzonderlijke processystemen staat. De inhoud van contacten en correspondentie tussen een inspecteur en de klant kan eveneens in dit systeem worden vastgelegd. Ook eventuele attentiepunten en risico’s die over de klant bekend zijn worden door de inspecteur in een tekstdocument opgenomen. Een klantmanager kan op deze wijze zijn beeld vormen over een klant, maar moet daarvoor wel eerst diverse documenten doorlezen, samenvatten en vastleggen in een nieuw tekstdocument. Het nadeel van dit systeem was dat het niet voorzag in de informatiebehoefte om snel van een groep klanten de attentiepunten, de risico’s en het belang in kaart te krijgen; er was dus geen totaaloverzicht. In de praktijk was bij de teammanagers deze behoefte er namelijk wel, alleen al uit hoofde van het stellen van prioriteiten en de selectie van klanten voor belastingcontroles. De manager bouwde deze informatie op in ‘zijn hoofd’ door te praten met de inspecteurs van de diverse middelen en met de individuele klantmanagers die op hun beurt het totaalbeeld van hun klantenpakket in het ‘hoofd’ moesten hebben zitten. Op basis van deze kennis ‘in het hoofd’ werden prioriteiten gesteld en keuzes gemaakt. Een situatie die dus erg afhankelijk was van welke informatie de manager had bereikt en bij hem “in het hoofd” was blijven hangen. Dit leidde ertoe dat gebruikers binnen teams zelf toepassingen gingen ontwikkelen om te voorzien in de informatiebehoefte voor het inzicht in de risico’s bij klanten. Zo is ondermeer in een team een EUA gemaakt ten behoeve van de selectie van posten voor fiscale boekenonderzoeken. Deze EUA had de naam ‘Controlebestand’. De EUA was door een gebruiker gemaakt in een MS Access database waarin de risico’s werden verzameld van het teampakket, waardoor totaaloverzicht ontstond. Hierin waren per middel (vennootschapsbelasting, loonbelasting, omzetbelasting) onderwerpcategorieën gemaakt met daaraan gekoppeld een prioriteit zoals bijvoorbeeld: Vpb Intercompany Pricing (3; hoog), Vpb Niet aftrekbare kosten (3), Vpb Afschrijvingen (2; midden), Vpb Voorzieningen (2), Vpb Voorraadwaardering (1; laag), LB Kostenvergoeding (3), OB gemengde omzetbelasting prestaties (hoog/laag tarief) (2), etcetera. Daarnaast werd een prioriteit toegekend aan het bedrag dat gemoeid was met het risico. In een stamtabel was per onderwerpcategorie een prioriteit gekoppeld. Deze kwalificatie was bepaald in overleg met enkele inspecteurs. Dit was mede gedaan om inzicht te krijgen in het belang. De klantmanagers brachten van hun klanten de risico’s en attentiepunten in het Controlebestand in.

26


3.4.1.1 Reden gebruik EUA Met behulp van deze EUA kon met één druk op de knop inzicht worden verkregen in het totaal van de lopende risico’s binnen een bepaald klantenpakket waar eventueel controle voor nodig was.

3.4.1.2 Maatregelen Om het risico van onbevoegde toegang te mitigeren was de database in een directory geplaatst waar alleen eigen teamleden bij konden. De database was beschermd met een wachtwoord zodat de lay-out en de tabellen (velden en stamgegevens) niet konden worden gewijzigd. Er waren maatregelen genomen om invoerfouten zoveel mogelijk te voorkomen, zoals validatie van datum en gebruik van keuzeopties/uitrolmenu’s.

3.4.1.3 Rest-risico’s De MS Access Database was muteerbaar door alle teamleden. Wijzigingen konden door iedereen worden aangebracht zonder dat bekend was wat er was gewijzigd, wie dat had gedaan en wanneer dat was gedaan.

Samenvatting Controlebestand Er was hier sprake van een informatiebehoefte voor de sturing van de controleactiviteiten. Een totaaloverzicht van de problemen/risico’s binnen een klantenpakket kon niet door de bestaande systemen worden geproduceerd. Hierdoor was het niet mogelijk om op inzichtelijke wijze prioriteit in het werk aan te brengen en inzicht te geven in gemaakte keuzes; wat doe je wel, waarom, wat laat je liggen. Men wist wat er speelde omdat de managers en inspecteurs daarover met elkaar praatten. De informatie zat in de hoofden van mensen, maar kon niet objectief inzichtelijk worden gemaakt. Voor de selectie van belastingcontroles was hiervoor binnen een team de applicatie Controlebestand ontwikkeld, waardoor beslissingen en keuzes aantoonbaar onderbouwd konden worden. MS Access was aan de gebruikers ter beschikking gesteld, waardoor deze EUA kon worden ontwikkeld. Het bestaansrecht van de EUA ligt besloten in het feit dat met name de teammanager belang heeft bij de informatiebehoefte. Het niet doorlopen van een formeel ontwikkeltraject is binnen organisatieonderdelen vaak een kwestie van tijd en geld; de informatiebehoefte is er nú en het budget en de personeelscapaciteit voor een formeel ontwikkeltraject zijn niet direct aanwezig.

3.4.2

Het Probleembestand

Evolutie van het Controlebestand tot integraal Probleembestand In een ander team was een EUA ontwikkeld, soortgelijk aan het Controlebestand, maar ter ondersteuning van de selectie binnen het heffingsproces. De naam hiervan was het Heffingsbestand. Hierin werden door de inspecteurs de risico’s ingevoerd uit de aangiften Vennootschapsbelasting zodat een totaalinzicht binnen het klantenpakket ontstond van de attentiepunten en het daarmee gemoeide belang in de aangiften. Anders dan in het Controlebestand, werd de prioriteit hierin door de gebruiker zelf ingebracht op basis van een schaal van één tot vijf. Voorts werd aangeven of het een weglek- dan wel verschuivingsbelang betrof. Hiermee werd inzichtelijk gemaakt welke risico’s er allemaal bestonden binnen het pakket van te behandelen aangiften en welk belang daarmee was gemoeid. 30 Op basis van de in dit bestand ingevoerde risico’s vond selectie plaats en werden de te 30

Normaliter vond een gedetailleerde vastlegging van al deze risico’s niet plaats en vond op basis van kennis van het

werkpakket en inzicht in de aangiften een selectie plaats.

27


behandelen risico’s onder de inspecteurs verdeeld. De EUA ondersteunde hierin het besluitvormingsproces van de selectie van te behandelen aangiften. Een teamleider die van beide teams deze werkwijze kende, kwam op het idee om een EUA te ontwikkelen voor zijn team waarin beide functionaliteiten werden gecombineerd. In Excel ontwikkelde een teamlid een toepassing waarin voor alle middelen de risico’s en het daarmee gemoeide belang in kaart konden worden gebracht. Dus zowel de risico’s die uit de aangiften volgden en voor de heffing van belang waren, als de risico’s die voor de controle van belang waren. Deze EUA had de naam Probleembestand en bood ondersteuning aan de selectie van posten en risico’s voor de controle en heffing omdat het een totaaloverzicht verschafte. Het belang van een juiste vulling van dit bestand was dan ook evident, zowel voor de risico’s als voor de status daarvan zoals: onbehandeld (default waarde), in behandeling of afgedaan. Dit Excel spreadsheet bestond uit drie zichtbare werkbladen: één werkblad waarin alle risico’s werden ingevoerd die nog niet tot behandeling hadden geleid, één werkblad waarin de voor behandeling geselecteerde risico’s stonden en één werkblad waarin de afgedane risico’s stonden. Met behulp van een macro werden de tabbladen bijgewerkt op basis van de vulling van het veld Status. De werkwijze van dit team werd door de directie van de eenheid omarmd en er werd besloten om deze wijze van werken ook in andere teams door te voeren. Ieder team kreeg haar eigen Probleembestand dat ondersteuning bood aan het selectieproces.

3.4.2.1 Reden gebruik EUA De reden voor het gebruik van de EUA was dat er behoefte aan ondersteuning was van het primaire proces voor de selectie van posten en dat er op het niveau van een groep klanten behoefte was aan inzicht in de risico’s voor de controle en heffing (totaaloverzicht).

3.4.2.2 Maatregelen Ook hier werd de Excel toepassing in een directory op het netwerk gezet waarvoor alleen de gebruikers van het team gerechtigd waren. Het werkblad was beveiligd tegen het invoegen, toevoegen of wijzigen van kolomvelden. Verder waren er - om invoerfouten in het werkblad te voorkomen - maatregelen opgenomen zoals: datumvalidatie, keuzeopties/uitrolmenu’s en automatische vulling van velden zoals naamgegevens bij invoer van het veld fiscaalnummer. Op basis van de door de gebruiker in te voeren UserID kon achterhaald worden wie het bestand had geraadpleegd, maar niet wat daarin was gemuteerd. Er werd dagelijks een back-up gemaakt zodat bij een eventuele crash het bestand van de dag ervoor beschikbaar was.

3.4.2.3 Rest-risico’s Audit-trail was onmogelijk. Achteraf kon niet worden nagegaan of de inhoud van een veld was gewijzigd, een record was gewist, wie dat had gedaan en wanneer dat was gedaan. Vanwege de macro’s en verwijzingen die op de achtergrond waren aangebracht, bestond het risico dat als door een gebruiker een rij werd tussengevoegd (met de optie invoegen rij) het spreadsheet volkomen vastliep. Dit gebeurde dan ook wel eens, waarna een recovery procedure moest worden ingezet met de back-up van de dag ervoor. De mutaties die op die dag waren aangebracht moesten als verloren worden beschouwd en opnieuw worden ingevoerd.

28


3.4.3

Applicatie Transparante Klantbehandeling

Evolutie Probleembestand tot ATK Op directieniveau van Belastingdienst Grote Ondernemingen was reeds doorgedrongen dat verschillende eenheden het wiel aan het uitvinden waren. Daarom werd besloten een inventarisatie te houden naar de verschillende vormen van werken. Hieruit bleek dat integratie van middelen en processen het meest vergevorderd was in Amsterdam. In Utrecht had men een EUA ontwikkeld die de werkstroom zeer goed kon ondersteunen en was voorzien van beveiligingsmaatregelen als logische toegangsbeveiliging en audit-trail. De gebruikers van Amsterdam en Utrecht hebben onder goedkeuring van de directie toestemming gekregen om de risicogerichte EUA uit Amsterdam en de werkstroomgerichte EUA uit Utrecht te ontwikkelen tot één EUA. Dit is een uiterst bijzondere situatie omdat de gebruikersorganisatie hier zelf iets ontwikkelt en niet de automatiseringsorganisatie (ontwikkelorganisatie). De gebruikers hebben hiervoor enorm gelobied omdat ervaringen uit het verleden hebben laten zien dat sommige door de ontwikkelorganisatie opgeleverde producten uiteindelijk toch niet helemaal naar de wens van de gebruikers functioneerden. De integratie van het risicogerichte (Amsterdamse) en het procesgerichte (Utrechtse) kwam samen in de EUA die als naam kreeg: Applicatie Transparante Klantbehandeling (ATK). De transparantie zat hem daarin dat van een klant in één oogopslag bekend was welke risico’s er speelden en wat de status van de behandeling was. De applicatie is door drie personen gemaakt binnen twee weken tijd. In ATK kon worden aangegeven welke risico’s op voorraad lagen, welke risico’s in behandeling waren en door wie, wat de voortgangsstatus daarvan was, welke risico’s waren afgedaan en wat de conclusie of uitkomst daarvan was. Maar ook het financiëel belang dat gemoeid was met een bereikt compromis in een vooroverleg situatie, kon hierin worden vastgelegd en met één druk op de knop inzichtelijk worden gemaakt. Aldus was een systeem voor Bestuurlijke Informatievoorziening ontwikkeld. Op personeelsniveau kon inzicht worden verkregen in het onderhandenwerk en de voortgang. Maar ook per middel en per proces kon de stand van zaken worden opgevraagd: “controle”, “ohw”, “resultaat vooroverleg”. De afgelopen drie jaar zijn alle Belastingeenheden voor de individuele klantbehandling met ATK gaan werken. ATK is nog immer een EUA. De EUA ATK werd gebouwd met behulp van Visual Basic van MS Excel en MS Access, omdat deze middelen de gebruikers ter beschikking stonden. De invoerschermen waren in Visual Basic Excel gebouwd en de data opgeslagen in tabellen binnen Access databases. Bij deze ontwikkeling werd frequent aan gebruikers teruggekoppeld of het programma voldeed aan de behoefte en werd door gebruikers ook getest. Hierdoor ontstond een gebruiksvriendelijke toepassing. Drie jaar geleden is het traject ingegaan om ATK door de ontwikkelorganisatie van de Belastingdienst te laten ontwikkelen. Dit gebeurt in Cobol en DB2 Database. Ten tijde van dit interview was de EUA ATK niet vervangen door het formele systeem ATK+ (plus). Hoewel er een goed werkend voorbeeld bestaat van wat de gebruikersorganisatie wil, is het in de praktijk toch nog een tijdrovende aangelegenheid om hiervan een geformaliseerd en beheerst systeem te maken. ATK+ moet immers ook vanaf de bodem worden opgebouwd. Zo is er bijvoorbeeld geen beschrijving van de business logica en de programmacode. Voor iedere functionaliteit wordt een use-case beschreven die weer geprogrammeerd moet worden. Afstemming tussen groepen kan vaak niet even snel, maar moet aansluiten op de agenda’s van de betrokkenen. Bij een eventuele annulering van een afstemmingsvergadering, duurt het al snel een maand voor een eerstvolgende mogelijkheid.

29


3.4.3.1 Maatregelen De applicatie en de database staan in een directory die niet bekend is bij gebruikers. De databases en het programma zijn met een wachtwoord beveiligd. Audit-trail is mogelijk: gelogd wordt welke user, wanneer, welk veld heeft gemuteerd. Er is een op rollen gebaseerde autorisatiematrix aan functionaliteiten gekoppeld. Sommige posten worden op verzoek van het management uitsluitend toegankelijk gemaakt voor bepaalde gebruikers (VIP-posten). 3.4.3.2 Rest-risico’s De kennis van ATK, de programmacode en de business logica, zit in het hoofd van de twee ontwikkelaars. Er is hiervan geen documentatie. De EUA is daardoor alleen onderhoudbaar door deze twee personen, waardoor bij het wegvallen van deze personen een risico ontstaat voor de operationele activiteiten.31 De functionaliteit is door gebruikers getest maar een capaciteit en performance test is naar verwachting niet in volle omvang uitgevoerd voordat het programma in productie is genomen. Geen of zeer gebrekkige documentatie over de werking van een complexe EUA en know-how daarover bij slechts twee personen, brengen bij het wegvallen van deze personen risico’s met zich mee voor de onderhoudbaarheid en de continuïteit.

3.4.4

Brondata in ATK

In de paragrafen 3.4.1, 3.4.2 en 3.4.3 is beschreven hoe ATK is geëvolueerd van een relatief eenvoudige EUA die diende ter ondersteuning van de besluitvorming (selectie van behandelrisico’s), naar een EUA waarin naast de risico’s ook de voortgang en uitkomsten van het werk worden geregistreerd. De EUA ATK wordt naast de mutaties door de gebruikers ook gevoed met data uit bronsystemen. Dit zijn bijvoorbeeld de NAW-gegevens en fiscaalnummers. Hiermee worden de stamtabellen gevuld. De aanlevering en invoer van deze data in ATK is omgeven met maatregelen ter waarborging van de betrouwbaarheid. De aanlevering en invoer kan worden onderverdeeld in de volgende fasen: Data-acquisitie, Datadistributie, Data-bewerking en Data-invoer. Hierbij zijn de volgende maatregelen getroffen: Data-acquisitie Vooraf is een formeel verzoek (formulier) ingediend door de gebruikersorganisatie (lokale toepassingsbeheerder) bij de Automatiseringsorganisatie. Voorafgesproken is dus: • om welke bestanden (data) het gaat; • op welke locatie op het netwerk de data moet worden geplaatst (deze locatie heeft zeer beperkte autorisaties); • het tijdstip en de frequentie van aanlevering. De automatiseringsorganisatie heeft hiervan een query vervaardigd en draait deze op de voorafgesproken dagen. Data-distributie De automatiseringsorganisatie zendt over het interne netwerk de bestanden in zipfile naar de vooraf afgesproken directory. Hiertoe heeft een beperkt aantal personen toegang.

31

Er is geen directe bedreiging voor de continuiteit van de bedrijfsactiviteiten omdat de bronsystemen zoals de Vpb-

base, ABS-base en IKB-base niet geraakt worden.

30


Data-bewerking De ATK-toepassingsbeheerder haalt de zipbestanden naar zijn persoonlijke directory. Hij bewerkt deze bronbestanden tot Mdb doelbestanden voor de ATK database met behulp van een zelf geschreven en getest programma. Data-invoer in ATK In de avonduren worden de doelbestanden middels een scheduler gekopieerd naar de productieomgeving (de directory waar de ATK databases staan). De scheduler is zelf ontwikkeld en getest. Het hiervoor beschreven beschreven proces om stamgegevens (brondata) uit de bronsystemen in ATK te vullen is weergegeven in figuur 6.

Figuur 6: Proces brondata-acquisitie, bewerking en invoer in ATK

31


4

Analyse van theorie en praktijk

In hoofdstuk twee zijn uit de literatuur beheersmaatregelen herleid aan de hand waarvan de betrouwbaarheid van EUI kan worden gewaarborgd. In de praktijk is vervolgens gekeken op welke wijze gebruik wordt gemaakt van EUI. Op basis van interviews is hierin inzicht verkregen. Deze praktijktoepassingen zijn in hoofdstuk drie beschreven. In dit hoofdstuk wordt naar aanleiding van een analyse van de cases antwoord gegeven op de volgende deelvragen: • Waarom en op welke wijze maakt men in de praktijk gebruik van EUI? • Welke maatregelen worden getroffen om de betrouwbaarheid van EUI te waarborgen? • Welke verschillen zijn te constateren tussen de theorie en de praktijk?

4.1

Waarom en op welke wijze maakt men in de praktijk gebruik van EUI?

Uit de interviews valt op dat EUI vaak wordt toegepast ter ondersteuning van niet-routinematige processen. De EUI verzorgt informatie voor het verslaggevingstraject maar ook voor de periodieke (maandelijkse) managementrapportages en –analyses. Als belangrijkste redenen voor het gebruik van EUI worden genoemd: het kostenaspect, de gebruiksvriendelijkheid van Excel of Access, de geringe frequentie van de informatiebehoefte, de beperkte hoeveelheid data en de niet vastomlijnde, wisselende informatiebehoefte. Daarnaast blijkt uit de casuïstiek dat EUI wordt toegepast ter ondersteuning van primaire bedrijfsprocessen. Reden hiervoor is het feit dat de standaardsystemen niet voorzien in de gewenste informatiebehoefte. Ook hierbij speelt het kostenaspect een belangrijke rol bij de overweging om gebruik te maken van EUI. Voorts valt op dat het ontwikkelen van een EUA plaatsvindt op het niveau van een team of unit zodra een teammanager daarbij belang heeft, bijvoorbeeld om de operationele activiteiten beter te kunnen managen.

4.2

Welke maatregelen worden getroffen om de betrouwbaarheid van EUI te waarborgen?

Uit de interviews blijkt dat de mate waarin beheersmaatregelen worden genomen afhankelijk is van de context waarbinnen EUI wordt gebruikt. EUA’s die voor de niet-routinematige processen worden gebruikt, zijn vaak persoonlijke EUA’s. Deze worden door één persoon gebouwd, gebruikt, onderhouden en bevinden zich in een persoonlijke (afgeschermde) directory van de gebruiker. Dit is meestal een financieel directeur, manager of controller. De vertrouwelijkheid van de EUI is daardoor gewaarborgd. De integriteit en controleerbaarheid van de EUA/EUInfo is objectief niet gewaarborgd en volledig afhankelijk van het beheersingsbewustzijn van de gebruiker/bouwer van de EUA. De gepresenteerde EUInfo wordt door de (interne) gebruikers daarvan, vaak de leiding van organisaties, als waarheid aangenomen. Dit is gebaseerd op vertrouwen in de deskundigheid en zorgvuldigheid van de opsteller. De EUInfo wordt meestal pas bij externe controle (gegevensgericht) gecontroleerd. Bij EUA’s die gebruikt worden ter ondersteuning van primaire processen is een diversiteit aan maatregelen aangetroffen: Logische toegangsbeveiliging Vaak is er sprake van enige mate van toegangsbeveiliging. Het gebruik van de EUA is bijvoorbeeld beperkt door deze in een directory te plaatsen waarin uitsluitend geautoriseerde personen toegang hebben en aan wie lees- en/of schrijfrechten zijn toegekend. De EUA (code, datatabellen, cellen) is vaak beveiligd door middel van een wachtwoord.

32


Invoer Om invoer van fouten te voorkomen zijn waarborgen getroffen zoals validatieregels, keuzeopties en uitrolmenu’s. Ook het 4-ogen principe wordt als procedure toegepast voor het waarborgen van betrouwbare EUInfo. Ontwikkel- en wijzigingsprocedures Er is functiescheiding tussen de ontwikkelaar en de gebruikers van een EUA. De EUA wordt door de gebruikers getest op de gebruikerseisen. Soft control en aanvullende beheersmaatregelen De leiding heeft vaak veel vertrouwen in de beheerder (soft control). De beheerder van de EUA heeft alle bevoegdheden en kan ongemerkt, ongedocumenteerd, wijzigingen in de EUA aanbrengen, hetgeen is ingegeven door kostenefficiency. Soms worden procedures gehanteerd die waarborgen dat de beheerder niet ongemerkt waarden kan onttrekken, bijvoorbeeld doordat de facturen en/of rekeningnummers worden beoordeeld voorafgaand aan de betaling. Back-up De EUA’s bevinden zich op het netwerk van de organisatie en worden opgenomen in de dagelijkse back-up. Opvallend is dat hoewel er geen formeel beleid in de praktijk is aangetroffen omtrent het ontwikkelen, en gebruik van EUA’s, de EUA’s niettemin zijn voorzien van beheersmaatregelen. Dit is klaarblijkelijk het gevolg van de betrokkenheid van deskundige gebruikers. Ten slotte blijkt dat voorzover de leiding zich bewust is van de risico’s, op grond van kosten/baten overwegingen het risico van onbetrouwbare EUInfo vaak wordt aanvaard, indien volgens de inschatting van de leiding de impact gering is voor de continuïteit.

4.3

Welke verschillen zijn te constateren tussen de theorie en de praktijk?

Beleid Uit de interviews volgt dat in de praktijk geen beleid wordt uitgedragen omtrent het gebruik van EUI, hoewel in de literatuur informatiebeleid als maatregel wordt genoemd zoals beschreven in paragraaf 2.2.1. Ten behoeve van het aantoonbaar beheersbaar maken én houden van EUI, is beleid vanuit de leiding gewenst. Er is anders te veel vrijblijvendheid waardoor de beheersing afhankelijk wordt van het beheersingsbewustzijn (professionaliteit) van de gebruikers. Dit geldt met name bij de grotere organisaties waar de (hoogste) leiding die de eindverantwoordelijkheid draagt niet meer overziet wat er op lagere echalons binnen de organisatie gebeurt. Organisatorische maatregelen, ontwikkelen wijzigingsprocedures Organisatorische maatregelen, zoals functiescheiding tussen eigenaar, ontwikkelaar en gebruiker van de EUA, zoals behandeld in paragraaf 2.2.2, worden niet getroffen bij EUA’s voor niet-routinematige processen. Bij EUA’s die primaire processen ondersteunen, wordt meestal alleen functiescheiding toegepast tussen de ontwikkelaars/beheerders en gebruikers. De ontwikkelen wijzigingsprocedures zoals beschreven in paragraaf 2.2.4 worden slechts ten dele gehanteerd. Zo werd in de aangetroffen praktijksituaties door de gebruikers getest of de EUA de gewenste informatie oplevert. Echter, dit vond plaats zonder de formele procedures, registraties en parafen. Dit gold ook voor het ontwikkelen van het programma voor de geautomatiseerde invoer van gegevens en de export van EUInfo. De beheerder (bouwer) van de EUA heeft in de praktijk alle bevoegdheden en kan ongemerkt en ongedocumenteerd wijzigingen aanbrengen. Er is in de praktijk veel persoonlijk vertrouwen in de betrouwbaarheid van de beheerder wat is ingegeven door pragmatisme en kostenefficiency.

33


Documentatie Documentatie over de opzet en werking van de EUA is er in de praktijk niet. Daardoor wordt niet alleen de controleerbaarheid van de EUA bemoeilijkt maar kunnen er ook problemen ontstaan voor het onderhoud waardoor de continuïteit in gevaar kan komen. Logging Meestal ontbreekt er een logging functionaliteit in de EUA waardoor binnen een groep gebruikers met gelijke rechten achteraf niet herleidbaar is welke user, welk gegeven, wanneer heeft gewijzigd. Archivering In de praktijk blijkt dat de bestanden worden gearchiveerd, veelal ingegeven door de fiscale wetgeving met betrekking tot de controleerbaarheid en de bewaarplicht (artikel 56 AWR). Echter, de herleidbaarheid naar de brongegevens levert vaak een probleem op doordat goede verwijzingen en toelichting ontbreken.

34


5

Samenvatting

End User Informatievoorziening (EUI) is het proces waarbij informatie door een eindgebruiker wordt vervaardigd met behulp van een door hemzelf of namens hem gebouwde toepassing: de End User Applicatie (EUA). Dit gebeurt in de praktijk meestal met Microsoft Excel of Microsoft Access. De informatie hieruit (EUInfo) wordt gebruikt voor het nemen van beslissingen en het afleggen van verantwoording (jaarrekening/aangiften). Geformaliseerde informatiesystemen zijn vaak omgeven met tal van beheersmaatregelen om de betrouwbaarheid van de informatievoorziening te waarborgen. EUI daarentegen lijkt een onbeheerst proces te zijn met risico’s voor de besluitvorming en verslaggeving. De centrale vraagstelling in deze scriptie luidt daarom: Op welke wijze en in hoeverre kan de betrouwbaarheid van EUI worden gewaarborgd? Het begrip betrouwbaarheid bestaat uit de kwaliteitsaspecten: vertrouwelijkheid, integriteit en controleerbaarheid. Om tot het beantwoorden van de centrale vraagstelling te komen is eerst antwoord gezocht op de volgende deelvragen: 1. Welke beheersmaatregelen waarborgen volgens de literatuur betrouwbare EUI? 2. Waarom en op welke wijze maakt men in de praktijk gebruik van EUI? 3. Welke beheersmaatregelen worden getroffen om de betrouwbaarheid van EUI te waarborgen? 4. Welke verschillen zijn te constateren tussen de theorie en de praktijk? Deelvraag 1 is behandeld in hoofdstuk twee. Op basis van literatuurstudie is onderzocht welke beheersmaatregelen de belangrijkste risico’s ondervangen die te onderkennen zijn binnen het proces van EUI. EUI is hierin onderverdeeld in drie fasen; de invoer van gegevens, de verwerking van gegevens en de distributie van informatie. De in de literatuur aangetroffen beheersmaatregelen voor een betrouwbare informatievoorziening zijn gegroepeerd naar deze fasen en dienovereenkomstig behandeld. De samenvatting van risico’s en beheersmaatregelen is weergeven in tabel 2 op pagina 19. De belangrijkste conclusie die uit de literatuurstudie kan worden getrokken is: Benader de ontwikkeling en het gebruik van bedrijfskritische EUA’s op dezelfde manier als de ontwikkeling en het gebruik van bedrijfssoftware. Dit komt vooral neer op het uitdragen van beleid omtrent EUA’s, het vaststellen van rollen, bevoegdheden en de daarbij horende toegangsrechten in de EUA, het beveiligen van de EUA, het invoeren van ontwikkelen wijzigingsprocedures met de daarbij horende vastleggingen, het implementeren van invoercontroles, exportcontroles en een duidelijke audit-trail van de EUInfo naar de brongegevens. Voor het beantwoorden van deelvragen 2, 3 en 4 is in de praktijk gekeken naar toepassingsvormen van EUI. Hiervoor zijn interviews gehouden met registeraccountants, gebruikers en ontwikkelaars/beheerders van EUA’s. De casuïstiek die aan bod is gekomen is behandeld in hoofdstuk drie. Op basis van deze interviews zijn de deelvragen beantwoord in hoofdstuk vier. Uit het praktijkonderzoek kan het volgende worden geconcludeerd. EUI die gebruikt wordt voor niet-routinematige processen bevat nauwelijks beheersmaatregelen die de integriteit en controleerbaarheid waarborgen. De interne gebruikers vertrouwen op de deskundigheid van de persoon van wie de EUInfo afkomstig is. Controle van die informatie, als dat al gebeurt, vindt plaats door externen zoals de openbare accountant of de belastingcontroleur. EUI voor het ondersteunen van primaire bedrijfsprocessen is vaak wel omgeven met maatregelen die in enige mate de vertrouwelijkheid, integriteit en controleerbaarheid waarborgen.

35


Echter, documentatie over de opzet en werking van de EUA is er niet waardoor de organisatie afhankelijk is van de ontwikkelaar/beheerder in het verschaffen van inzicht bij controles en het verrichten van onderhoud aan de EUA. Ook formele registraties van wijzigingsaanvragen en doorgevoerde wijzigingen in de EUA vinden niet plaats, waardoor de betrouwbaarheid van de EUI niet geobjectiveerd is. De leiding is zich vaak niet bewust van de risico’s die gepaard gaan met EUI omdat zich in het verleden nimmer problemen hebben voorgedaan. Externe accountants wijzen de leiding op de onderkende risico’s. Desondanks worden op grond van economische overwegingen (kosten van de maatregelen in relatie tot de toegevoegde waarde daarvan), de risico’s van onbetrouwbare EUI geaccepteerd als volgens de inschatting van de leiding de impact voor de continuïteit laag is of een eventuele fout in de jaarrekening door externe accountantscontrole wordt afgedekt. Dit laatste uitgangspunt blijkt in de praktijk niet altijd terecht, met name als het gaat om de fiscaliteit. Dat komt doordat enerzijds de gehanteerde materialiteit van de externe accountant hoger is dan die van de Belastingdienst, en anderzijds de Belastingdienst de aangetroffen fouten over de laatste vijf jaren (de navorderingstermijn) kan corrigeren en het totaal van de (meestal) te weinig betaalde belasting alsnog substantieel kan zijn. Uit de praktijk blijkt dat indien de EUI niet meer kan voldoen aan de gebruikerswensen en de risico’s voor de continuiteit te groot worden, bijvoorbeeld door de groei van de bedrijfsactiviteiten, de leiding besluit tot het formaliseren van de informatievoorziening en wordt overgegaan tot het ontwikkelen van een echte applicatie. Zowel de SOx-wetgeving als de Belastingdienst met het Horizontaal Toezicht eisen van de leiding van een organisatie dat zij hun processen aantoonbaar beheersen. Met betrekking tot SOx richt dit zich op processen die hun weerslag hebben in de jaarrekening en met betrekking tot Horizontaal Toezicht op processen die hun weerslag hebben in de fiscale aangiften. Om daaraan te kunnen voldoen zullen beheersmaatregelen moeten worden getroffen zoals behandeld in hoofdstuk twee. Tot slot kan worden opgemerkt dat de betrouwbaarheid van EUI kán worden gewaarborgd op basis van de maatregelen zoals behandeld in hoofdstuk twee. De implementatie van deze maatregelen zal in de praktijk echter afhankelijk zijn van de toegevoegde waarde die de leiding van een organisatie hiermee denkt te behalen en de mate waarin zij SOx of Horizontaal Toezicht compliant wil zijn. Het implementeren van deze maatregelen kost immers ook extra inspanning, capaciteit en geld. Nader onderzoek zal moeten uitwijzen in hoeverre met betrekking tot EUI beheersmaatregelen worden getroffen om compliant te zijn aan Horizontaal Toezicht.

36


6

Persoonlijke reflectie

Sinds 1991 ben ik werkzaam als belastingcontroleur bij de Belastingdienst/Amsterdam en heb in 1998 de Nivra-Nijenrode Accountancy opleiding afgerond. Het werk als belastingcontroleur bevalt mij erg goed; het is afwisselend werk waarin je veel gebruik maakt van je sociale- en communicatieve vaardigheden, de kennis op het gebied van de fiscaliteit en jaarrekeningrecht, de kennis van de administratieve-organisatie/interne beheersing en de bedrijfseconomie. In 2007 had ik de behoefte aan een nieuwe uitdaging/prikkel op het professionele vlak en ben daarom de IT-auditopleiding gaan volgen. Persoonlijk heb ik dit gezien als een verdieping in mijn vakgebied. Mijn grootste leerervaring tijdens deze opleiding is bewustwording van risico’s die met IT verband houden en de beheersing daarvan. Ook tijdens de Accountancy opleiding zijn onder meer de general IT-controls aan bod gekomen, maar gedurende de IT-auditopleiding zijn de begrippen voor mij meer gaan leven en hebben een plaats gekregen. Ik noem bijvoorbeeld het begrip ‘change management’. De bewustwording van wat dit inhoudt en het belang van een goed change managementproces voor de betrouwbaarheid van de informatievoorziening, is iets wat tijdens deze opleiding is ontstaan. Door deze opleiding kan ik ook bepaalde concepten en architectuurinrichtingen plaatsen. Als voorbeeld noem ik architecturen als Demilitarized Zone maar ook bijvoorbeeld de scheiding tussen applicaties en databases en de beheersingsmaatregelen daaromheen. Normenkaders en best practices, zoals de Code voor Informatiebeveiliging, NIST, ITIL en Cobit waren voor mij volkomen nieuw. Het is handig als referentiekader om het bestaan van deze normenkaders te kennen voor het auditen en het inrichten van IT-beheer. Ik was gewend om vanuit proces-analyse en risico-analyse een proces te beoordelen en van daaruit te bepalen of de getroffen maatregelen toereikend waren voor de betrouwbaarheid van een fiscale aangifte. Als sluitstuk van de opleiding moet er een scriptie worden geschreven. Dit proces heb ik als een achtbaan ervaren met hoogte- en dieptepunten. Al vrij snel had ik het idee om te schrijven over de informatievoorziening die vaak in Excel tot stand komt en gebruikt wordt voor de aangiften. Maar gelijktijdig voelde ik een belemmering omdat ik het ITgehalte van het onderwerp nog niet goed kon duiden en concretiseren. Immers, een Excel toepassing waarin wordt gerekend moet doen waarvoor het gebouwd is, geen invoeren formulefouten bevatten en de gegevens moeten aansluiten met de brongegevens. Simpel nietwaar? Dus geen onderwerp, dacht ik. Gaandeweg ben ik gaan inzien dat alle facetten die logisch lijken, wel beheerst moeten worden. En dat zijn IT-gerelateerde zaken. De mist die aan het begin van het proces aanwezig was, begon zich langzamerhand op te lossen waardoor geleidelijkaan helder werd waar ik naartoe zou schrijven. Mijn scriptiebegeleider Abbas Shahim heeft hierin een waardevolle bijdrage geleverd, waarvoor ik hem erg dankbaar ben. Samen met een collega van de Belastingdienst, die gelijktijdig met mij aan de IT-opleiding is begonnen, zou ik de scriptie schrijven. Ik had ervoor gezorgd dat ik mijn aandeel vóór maart 2009 had geschreven omdat voor mij een zeer drukke periode zou aanbreken tot en met juni. Vanwege ziekte heeft mijn collega uiteindelijk geen bijdrage kunnen leveren aan de scriptie. Ik heb zo snel mogelijk mijn deel uit februari weer opgepakt en de scriptie afgemaakt. Met uitzondering van deze, met name voor mijn collega, vervelende gebeurtenis was het schrijven van de scriptie en vooral het houden van de interviews erg leerzaam. Tijdens het houden van interviews kwamen IT-gerelateerde zaken aan bod die zoveel meer inzicht gaven en mijn beeldvorming vergrootten. Ik heb daar echt veel plezier aan beleefd en van geleerd.

Djef Memedov, Castricum 29 april 2009.

37


7

Bijlage 1: Wet- en regelgeving

7.1.1

Fiscale wetgeving

Voor de heffing van de rijksbelastingen zijn in artikel 52 van de Algemene wet inzake rijksbelastingen (AWR) bepalingen opgenomen voor het voeren van een administratie en de controleerbaarheid daarvan. 32 Artikel 52 lid 1 van de AWR: Administratieplichtigen zijn gehouden van hun vermogenstoestand en van alles betreffende hun bedrijf, zelfstandig beroep of werkzaamheid naar de eisen van dat bedrijf, zelfstandig beroep of die werkzaamheid op zodanige wijze een administratie te voeren en de daartoe behorende boeken, bescheiden en andere gegevensdragers op zodanige wijze te bewaren, dat te allen tijde hun rechten en verplichtingen alsmede de voor de heffing van belasting overigens van belang zijnde gegevens hieruit duidelijk blijken. Artikel 52 lid 4 van de AWR: Voorzover bij of krachtens de belastingwet niet anders is bepaald, zijn administratieplichtigen verplicht de in voorgaande leden bedoelde gegevensdragers gedurende zeven jaren te bewaren. Artikel 52 lid 6 van de AWR: De administratie dient zodanig te zijn ingericht en te worden gevoerd en de gegevensdragers dienen zodanig te worden bewaard, dat controle daarvan door de inspecteur binnen een redelijke termijn mogelijk is. Daartoe verleent de administratieplichtige de benodigde medewerking met inbegrip van het verschaffen van het benodigde inzicht in de opzet en de werking van de administratie. Met betrekking tot EUI zijn dus de integriteit van de gegevens, de beschikbaarheid en controleerbaarheid van belang.

7.1.2

Horizontaal Toezicht

In het kader van horizontaal toezicht sluit de Belastingdienst individuele convenanten af met zeer grote en middelgrote ondernemingen. In deze convenanten worden gewenste houding en gedrag benoemd en afspraken gemaakt over de wijze en intensiteit van het toezicht. Dit toezicht stemt de Belastingdienst af op de mate waarin het bedrijf "in control" is. Hiervoor moet de Belastingdienst inzicht hebben in de opzet, het bestaan en de werking van het fiscaal relevante deel van de interne beheersing, door de Belastingdienst aangeduid met Tax Control Framework (TCF). De fiscaal relevante administratieve organisatie en interne beheersing (ao/ib) vormt het Tax Control Framework (TCF). 33 Een TCF biedt de Belastingdienst de basis om de mate, vorm en intensiteit van het toezicht op de onderneming af te stemmen op de mate waarin de onderneming in control is. Het toezicht verschuift van een controle van de ingediende aangifte naar een oordeel over de wijze waarop de aangifte tot stand komt en het vooroverleg. Dit betekent uiteraard dat de Belastingdienst inzicht moet hebben in 32

De algemene eis voor het voeren van een administratie, en het bewaren daarvan, volgens het burgerlijk wetboek is

opgenomen in het Burgerlijk Wetboek Boek 2, titel 1 artikel 10 lid 1 en 10 lid 3 (voor rechtspersonen) en Burgerlijk Wetboek Boek 3, afdeling 1B, artikel 15i (voor natuurlijke personen die een bedrijf uitoefenen). De formulering van deze bepalingen is van gelijke strekking als artikel 52 lid 1 AWR en 52 lid 4 AWR. 33 Brochure Horizontaal Toezicht (uitgave Belastingdienst 2008). De Belastingdienst wil met horizontaal toezicht de samenwerking in het toezicht veel meer centraal zetten. Dat betekent afstemming vooraf waar nodig, in plaats van controles achteraf. Samenwerken staat dus centraal: ieder vanuit zijn eigen rol, maar wel gericht op een goede uitvoering van de belastingwetten, op een efficiënte manier én op een manier waarbij de belastingplichtige weet waar hij aan toe is. Vertrouwen in elkaar speelt hierbij een belangrijke rol.

38


het TCF. Bij dit inzicht zijn ook de maatregelen van externe controle van belang. De Belastingdienst beperkt zijn activiteiten daarmee tot vooroverleg en het monitoren van het proces: heeft de ondernemer of zijn intermediair het proces zo op orde dat de Belastingdienst erop kan vertrouwen? 34 Met betrekking tot EUI betekent dit dat de organisatie waarborgen dient te treffen zodat kan worden aangetoond dat de EUInfo die in de aangifte tot uitdrukking komt betrouwbaar is. 35

7.1.3

Sarbanes-Oxley Act

In de Verenigde Staten is de aandacht de laatste jaren steeds meer uitgegaan naar aantoonbare naleving van weten regelgeving, vooral binnen de financiële processen van ondernemingen. Dit is onder meer het gevolg van de Sarbanes-Oxley Act (SOx). 36 Dit heeft de behoefte onderstreept aan een stringentere beheersing van financiële overzichten uit EUA’s waarop beslissingen worden gebaseerd. De Sarbanes-Oxley Act (SOx) werd in 2002 van kracht als reactie op de beursschandalen rond Enron en Worldcom. In 2006 is de Sarbanes-Oxley wet voor het eerst van kracht voor bestuurders van Nederlandse ondernemingen met een Amerikaanse beursnotering. De wet bevat maatregelen bedoeld om beleggers te behoeden voor dergelijke schandalen in de toekomst. Deze wet geldt voor alle bedrijven, dus ook voor niet-Amerikaanse, die een beursnotering in de VS hebben of daar andere financiering hebben aangetrokken.37 De belangrijkste maatregelen van SOx hebben betrekking op regels ter verbetering van het interne beheersingssysteem. Onderdeel van deze regels is sectie 404, het meest beruchte onderdeel van de wet, waarin wordt geëist dat bestuurders persoonlijk instaan voor de kwaliteit van de jaarcijfers, dat ze dus “in control” zijn. Ook externe accountants dienen een dergelijke verklaring af te geven. Mochten naderhand tekortkomingen in de jaarcijfers aan het licht komen dan zijn bestuurders en accountants persoonlijk aansprakelijk en zijn celstraffen tot twintig jaar mogelijk. Het belang van SOx voor EUA is gelegen in het feit dat EUA’s die relevant zijn voor de financiële verslaggeving moeten worden omgeven met beheersmaatregelen om de betrouwbaarheid van de EUI te garanderen. 38 Hierbij zijn twee soorten maatregelen te onderscheiden: maatregelen om de betrouwbare werking van de EUA vast te stellen en maatregelen die ervoor zorgen dat de werking van de EUA betrouwbaar blijft (general IT-controls). De organisatie dient deze maatregelen aan te tonen. Voor SOx moet het management van de organisatie, maar ook de externe accountant, vaststellen dat de organisatie hiervoor adequate maatregelen heeft ingericht en dat deze maatregelen over een bepaalde periode effectief zijn gebleken. 34

De Belastingdienst wil daartegenover open en transparant zijn, bijvoorbeeld door snel een standpunt in te nemen

met begrip voor commerciële belangen en termijnen. 35 Een essentieel verschil tussen het bedrijfskritische gehalte van een EUA voor de jaarrekening, waarvoor SOx geldt, en een EUA voor fiscale doeleinden is gelegen in de materialiteit. Het financiële belang kan voor fiscale doeleinden substantieel zijn maar in het kader van de jaarrekening, en daarmee voor SOx niet relevant zijn. De hogere materialiteit van de externe accountant zorgt ervoor dat hij zijn controle zodanig inricht dat fouten van een bepaalde omvang niet hoeven te worden geconstateerd omdat die niet relevant zijn voor het beeld van de jaarrekening. 36 De inhoud van deze paragraaf is gebaseerd op de volgende publicaties: Corporate governance: SOX rijmt niet met Hollandse cultuur; De spreadsheet van het strafbankje en de brochure Tax Control Framework. In Nederland heeft de commissie Tabaksblat de Nederlandse Corporate Governance Code ontwikkeld, die stringente

37

eisen stelt aan het ondernemingsbestuur van Nederlandse beursgenoteerde ondernemingen. Bedrijven hoeven niet aan alle onderdelen van de Code te voldoen. Wel is wettelijk geregeld dat ondernemingen uitleg geven wanneer zij de code niet volledig naleven. Een belangrijke bepaling zowel in SOx als Tabaksblat is dat de ondernemingsleiding een uitspraak moet doen over de effectiviteit van de interne beheersing, de mate waarin de onderneming in control is. Zij doet dat door middel van het “in control statement” in het jaarverslag. 38 Relevantie van de EUA is afhankelijk van professionele oordeelsvorming en het belang van de betreffende data voor de verslaggeving.

39


8

Bijlage 2: Algemeen aanvaarde raamwerken

In deze bijlage zijn enkele normen/maatregelen opgenomen uit best practices en raamwerken zoals beschreven in de Code voor Informatiebeveiliging (NEN-ISO/IEC 17799:2005/27001), Coso, Cobit en ITIL. Deze zijn gebruikt bij de analyse van bruikbare beheersmaatregelen ter waarborging van betrouwbare EUI. De informatie over Coso, Cobit en ITIL is ontleend aan het collegemateriaal van de VU en Wikipedia, de vrije internet encyclopedie.

8.1.1

Code voor informatiebeveiliging

De code voor informatiebeveiliging geeft in elf hoofdbeveiligingscategorieën richtlijnen en algemene principes voor het initiëren, implementeren, handhaven en verbeteren van de informatiebeveiliging in een organisatie. Op basis van een beoogde doelstelling wordt een norm, een beheersmaatregel en een implementatierichtlijn geformuleerd. Enkele beheersmaatregelen uit de Code zijn ter illustratie hieronder opgenomen. •

A4.1 Beoordelen van beveiligingsrisico’s Risicobeoordelingen behoren risico’s te identificeren en te kwantificeren en prioriteit toe te kennen aan de hand van de criteria voor risicoacceptatie en doelstellingen die relevant zijn voor de organisatie.

•

A5.1 Informatiebeveiligingsbeleid Een document met informatiebeveiligingsbeleid moet door de directie worden goedgekeurd en gepubliceerd en kenbaar worden gemaakt aan alle werknemers en relevante externe partijen.

•

A6.1.4. Goedkeuringsproces voor IT-voorzieningen

•

A7.1.2. Eigendom van bedrijfsmiddelen

Er moet een goedkeuringsproces voor nieuwe IT-voorzieningen worden vastgesteld en geïmplementeerd. Alle informatie en bedrijfsmiddelen die verband houden met IT-voorzieningen moeten een eigenaar hebben in de vorm van een aangewezen deel van de organisatie. •

A7.2. Classificatie van informatie Informatie moet worden geclassificeerd met betrekking tot de waarde, wettelijke eisen, gevoeligheid en onmisbaarheid voor de organisatie.

•

A10.1.2 Wijzigingsbeheer

•

A10.1.3 Functiescheiding

Wijzigingen in IT-voorzieningen en informatiesystemen moeten worden beheerst. Taken en verantwoordelijkheidsgebieden moeten worden gescheiden om gelegenheid voor onbevoegde of onbedoelde wijziging of misbruik van de bedrijfsmiddelen van de organisatie te verminderen. •

A10.1.4 Scheiding van faciliteiten voor ontwikkeling, testen en productie Faciliteiten voor ontwikkeling, testen en productie moeten zijn gescheiden om het risico van onbevoegde toegang tot of wijzigingen in het productiesysteem te verminderen.

•

A10.3.2 Systeemacceptatie Er moeten aanvaardingscriteria worden vastgesteld voor nieuwe informatiesystemen, upgrades en nieuwe versies en er moet een geschikte test van het systeem of de systemen worden uitgevoerd tijdens de ontwikkeling en voorafgaand aan de acceptatie.

•

A10.5.1. Reservekopieën maken (back-ups) Er moeten back-up kopieën van informatie en programmatuur worden gemaakt en regelmatig worden getest overeenkomstig het vastgestelde back-upbeleid.

•

A10.7.4 Beveiliging van systeemdocumentatie

•

A10.10.1 Aanmaken audit-logbestanden

Systeemdocumentatie moet worden beschermd tegen onbevoegde toegang. Activiteiten van gebruikers, uitzonderingen en informatiebeveiligingsgebeurtenissen moeten worden vastgelegd in audit-logbestanden. Deze logbestanden moeten gedurende een overeengekomen periode worden bewaard, ten behoeve van toekomstig onderzoek en toegangscontrole. •

A11.1.1 Toegangsbeleid Er moet toegangsbeleid worden vastgesteld, gedocumenteerd en beoordeeld op basis van bedrijfseisen en beveiligingseisen voor toegang.

•

A11.2.1 Registratie van gebruikers

40


Er moeten formele procedures voor het registreren en afmelden van gebruikers worden vastgesteld, voor het verlenen en intrekken van toegangsrechten tot alle informatie-systemen en diensten •

A12.2.1 Validatie van invoergegevens Gegevens die worden ingevoerd in toepassingen moeten worden gevalideerd om te bewerkstelligen dat deze gegevens juist en geschikt zijn.

•

A12.2.4 Validatie van uitvoergegevens Gegevensuitvoer uit een toepassing moet worden gevalideerd, om te bewerkstelligen dat de verwerking van opgeslagen gegevens op de juiste manier plaatsvindt en geschikt is gezien de omstandigheden.

•

A12.4.3. Toegangsbeheersing voor broncode van programmatuur

•

A12.5.1. Procedures voor wijzigingsbeheer

De toegang tot broncode van programmatuur moet worden beperkt. De implementatie van wijzigingen moet worden beheerst door middel van formele procedures voor wijzigingsbeheer.

8.1.2

Coso

Het Coso beheersingsmodel is ontwikkeld door the Committee of Sponsoring Organizations of the Treadway Commission (COSO). Dit comité, bestaande uit een aantal private organisaties, heeft in 1992 naar aanleiding van een aantal boekhoudschandalen en fraudegevallen aanbevelingen gedaan en richtlijnen gegeven ten aanzien van interne controle en interne beheersing. In 1994 is hier een aanvulling op gekomen en samengevoegd tot het Coso-rapport ‘Internal Control-Internal Framework’. Dit rapport is bedoeld om aan organisaties een uniform en gemeenschappelijk referentiekader voor interne controle aan te bieden om het management te ondersteunen bij het verbeteren van het interne controlesysteem. In 2004 is het model geactualiseerd en staat bekend als Coso II of Enterprise Risk Management Framework. 39 De focus in het Coso model ligt op beheersing van de (interne) financiële verslaggeving. Het Coso referentiemodel wordt samengevat in de onderstaande kubus.

De essentie van Coso is dat interne beheersingsmaatregelen worden getroffen om de bedrijfsdoelstellingen te bereiken zoals: -de strategische doelstellingen, missie en visie (Strategic) -de effectiviteit en efficiëntie van bedrijfsprocessen (Operations) -de betrouwbaarheid van de (financiële) informatieverzorging (Reporting) -de naleving van weten regelgeving (Compliance)

39

Ten opzichte van Coso I is Coso II uitgebreid met de doelstelling Strategic en de componenten Objective setting,

Event identification en Risk response. Ondernemingen die voor de inrichting van hun internal control framework kiezen voor Coso II blijven extern rapporteren dat zij het Coso I raamwerk hanteren met de achterliggende gedachte dat een onderneming die rapporteert dat zij meer doet dan gevraagd, mogelijk kwetsbaarder is voor claims.

41


Het proces van inrichten van de beheersingsmaatregelen teneinde de bedrijfsdoelstellingen te bereiken wordt beschreven door de componenten: - internal environment: dit zijn de normen en waarden van een organisatie. Hierin zijn de integriteit, ethiek en competenties van de organisatie en zijn leden opgenomen. Te denken valt aan een code of conduct, compliance officer, etcetera; -objective setting: bepalen van de doelstellingen; -event identification: identificatie van de gebeurtenissen; - risk assessment: bepalen van het inherente risico in een proces en de inschatting van de waarschijnlijkheid dat het risico zich zal voordoen en de gevolgen indien het zich voordoet -risk response: risico’s vermijden, aanvaarden, delen of verminderen; - control activities: ontwerpen, implementeren en uitvoeren (opzet, bestaan en werking) van maatregelen (key controls) met als doel de inherente risico’s in het proces te beheersen. Deze controls zijn onder meer functiescheiding, informatie controle, fysieke controle en prestatie beoordeling; - information and communication: verzorgen van bestuurlijke informatie voor de beoordeling in hoeverre de doelen worden behaald en communicatie over het internal control systeem, zodat de organisatieleden weten wat er van hen wordt verwacht; - monitoring: bewaken van de kwaliteit van het internal control systeem en bijsturen waar nodig. Het zijvlak van de kubus geeft weer dat de doelen en componenten gelden voor alle onderdelen van de organisatie.

8.1.3

Cobit

Cobit (Control Objectives for Information and related Technology) is een set van best practices, de beste praktijkoplossingen, voor het gestructureerd inrichten en beoordelen van een IT beheeromgeving. Cobit stelt IT managers in staat om op basis van algemeen geaccepteerde best practices de IT beheersmaatregelen in te richten. De focus van Cobit ligt op de beheersing van IT. Enkele beheersmaatregelen uit Cobit zijn hierna opgenomen: • P01 Define a Strategic IT Plan IT Strategic planning is required to manage and direct all IT resources in line with the business strategy and priorities.

• AI2.3 Application Control and Auditability Ensure that business controls are properly translated into application controls such that processing is accurate, complete, timely, authorized and auditable. Issues to consider especially are authorisationmechanisms, information integrity, access control, backup and design of audit trails.

• AI2.7 Development of Application Software Ensure that automated functionality is developed in accordance with design specifications, development and documentation standards and quality requirements. Approve and sign off on each key stage of the application software development process following successful completion of functionality, performance and quality reviews. Issues to be considered include approval that design specifications meet business, functional and technical requirements; approval of change requests; and confirmation that application software is compatible with production and ready for migration. In addition, ensure that all legal and contractual aspects are identified and addressed for application software developed by third parties.

• AI2.9 Applications Requirements Management Ensure that during design, development and implementation the status of individual requirements (including all rejected requirements) is tracked and changes to requirements are being approved through an established change management process.

42


De vier beheerdomeinen van de Cobit-cyclus zijn weergegeven in de onderstaande figuur. Plan and Organize (1)

Acquire and Implem ent (2)

PO1

Define a Strategic IT Plan and direction

AI1

Identify Automated Solutions

PO2

Define the Information Architecture

AI2

Acquire and Maintain Application Software

PO3

Determine Technological Direction

AI3

Acquire and Maintain Technology Infrastructure

PO4

Define the IT Processes, Organization and Relationships

AI4

Enable Operation and Use

PO5

Manage the IT Investment

AI5

Procure IT Resources

PO6

Communicate Management Aims and Direction

AI6

Manage Changes

PO7

Manage IT Human Resources

AI7

Install and Accredit Solutions and Changes

PO8

Manage Quality

PO9

Assess and Manage IT Risks

PO10

Manage Projects

Monitor and Evaluate (4)

Deliver and Support (3)

ME1

Monitor and Evaluate IT Processes

DS1

Define and Manage Service Levels

ME2

Monitor and Evaluate Internal Control

DS2

Manage Third-party Services

ME3

Ensure Regulatory Compliance

DS3

Manage Performance and Capacity

ME4

Provide IT Governance

DS4

Ensure Continuous Service

DS5

Ensure Systems Security

DS6

Identify and Allocate Costs

DS7

Educate and Train Users

DS8

Manage Service Desk and Incidents

DS9

Manage the Configuration

DS10

Manage Problems

DS11

Manage Data

DS12

Manage the Physical Environment

DS13

Manage Operations

Cobit cyclus bestaande uit 4 beheerdomeinen en 34 high-level IT processen

8.1.4

ITIL

Information Technology Infrastructure Library, meestal afgekort tot ITIL, is ontwikkeld als een referentiekader voor het inrichten van de beheerprocessen binnen een ICT-organisatie. ITIL is een set van best practices. In ITIL worden maatregelen beschreven ter waarborging van een betrouwbare gegevensverwerking. Deze zien onder meer op de inrichting van de procedures rondom: Logische Toegangsbeveiliging, Change Management, Incident Management, Problem Management, Back-up, Recovery, Uitwijk en Fysieke Beveiliging De ICT-beheerprocessen zijn ingedeeld in een aantal sets, waaronder: 1. Service Delivery. Security Management Capacity Management, Availability Management, IT Service Continuity Management (ITSCM) Service Level Management Financial Management for IT Services (FMITS) 2. Service Support. Service Desk, Incident Management, Problem Management Release Management, Change Management, Configuration Management

43


3. ICT Infrastructure Management. Network service management, Operations management, Management of local processors Computerinstallation and acceptance, System management 4. 5. 6. 7.

Planning to Implement Service Management. The Business Perspective. Application Management. Software Asset Management.

Bron (www.itil-officialsite.com)

44


9

Geraadpleegde Literatuur

Algemene wet inzake rijksbelastingen, Wet van 2 juli 1959, Stb. 301, laatstelijk gewijzigd bij Wet van 18-12-2008, Stb. 566 en 567 e

Bestuurlijke Informatieverzorging deel 1 Algemene grondslagen 3 druk, R.W. Starreveld, H.B. de Mare, E.J. Joëls, 1993 Informatietechnologie-Beveiligingstechnieken-Code voor Informatiebeveiliging (ISO/IEC 17799:2005, IDT), juni 2005 Informatietechnologie-Beveiligingstechnieken-Managementsystemen voor informatiebeveiliging-Eisen (ISO/IEC 27001:2005, IDT), november 2005 Microsoft Access 97 Step by Step, Academic Service, 1999 Microsoft Excel 97 Step by Step, Academic Service, 1999 Nivra geschirift 13: Deel III De invloed van de geautomatiseerde gegevensverwerking op de accountantscontrole, 1995 Nivra geschrift 53: Deel VII Kwaliteitsoordelen over informatievoorziening, 1994 Nivra studierapport 21: Functiescheidingen in software, 1988 Nivra studierapport 27: Beheersing van de micro, 1991 Norea geschrift 1: IT-auditing aangeduid, 1998 The Use of Spreadsheets: Considerations for section 404 of the Sarbanes-Oxley Act, PriceWaterhouseCoopers july 2004 Whitepaper Microsoft: Spreadsheet compliance in the 2007 Microsoft Office System, Microsoft Corporation, april 2006 Whitepaper Xactly: Spreadsheets and Sarbanes-Oxley, regulations, risks and control frameworks; R.R. Panko University of Hawaii, 2006 artikel Corporate governance: SOX rijmt niet met Hollandse cultuur, Jeroen Kerkhof, FEM Business nr. 36, 2006 artikel De Spreadsheet van het strafbankje, ing. G.M. Onland RE MSc, De EDP-Auditor nr. 4, 2007 artikel Herken uw spreadsheetrisico's, C. Wielinga en A. Wielinga, Financieel Management, 2006 brochure Belastingdienst: Horizontaal Toezicht, samenwerken vanuit vertrouwen, 2008 brochure Belastingdienst: Tax Control Framework, 21 maart 2008 presentatie Beheersing van record to report, drs. C. Blom RA RE, 2008 VU collegemateriaal Cobit d.d. 10 maart 2008 VU collegemateriaal Information Risk & Security Management d.d. 17 maart 2008 VU collegemateriaal Change, Incident & Problemmanagment d.d. 31 maart 2008 VU collegemateriaal Applicatie Onwikkeling d.d. 14 april 2008 VU collegemateriaal Application Controls d.d. 21 april 2008 VU collegemateriaal Systeemontwikkeling d.d. 29 september 2008

45

Vrije Universiteit Amsterdam Postgraduate IT-Audit opleiding

Recommend Documents