Monitoring SoD controles

(1)

Monitoring SoD controles

Een oplossing voor complexe autorisatiestructuren in SAP?

Lieke-Rosa Koetsier

Auteur: Lieke-Rosa Koetsier Studentnummer: 12894559

E-mail: Lieke-Rosa.Koetsier@nl.gt.com Plaats: Maarssen, Nederland

Datum: 15-1-2022

Begeleider: Paul Hamaker

Onderwijsinstelling: Universiteit van Amsterdam

Opleiding: Executive Program of Digital Auditing

(2)

Verklaring van eigen werk

Hierbij verklaar ik, Lieke-Rosa Koetsier, dat ik deze scriptie zelf geschreven heb en dat ik de volledige verantwoordelijkheid op me neem voor de inhoud ervan.

Ik bevestig dat de tekst en het werk dat in deze scriptie gepresenteerd wordt origineel is en dat ik geen gebruik heb gemaakt van andere bronnen dan die welke in de tekst en in de referenties worden genoemd.

De Faculteit Economie en Bedrijfskunde is alleen verantwoordelijk voor de begeleiding tot het inleveren van de scriptie, niet voor de inhoud.

(3)

Voorwoord

Tijdens mijn werk als IT auditor merk ik dat het vaak lastig is om inzicht te krijgen in ingerichte autorisaties in ERP applicaties. Hierdoor is het moeilijk om werkelijk vast te stellen welke gebruikers welke rechten hebben.

Vooral in het ERP pakket SAP is dit erg ingewikkeld, terwijl dit pakket toch zo veel gebruikt wordt. Tijdens het volgen van de opleiding “Executive Program of Digital Auditing” aan de Universiteit van Amsterdam volgde ik het vak “ERP”, dat werd gegeven door docenten Paul Hamaker en Friso van Wieringen. Hier leerde ik meer over de onderliggende autorisatie concepten in SAP, waarna ik nog beter begreep waarom het zo lastig is om te bepalen wie welke rechten heeft in SAP, en waarom het zo lastig is om een goed werkend autorisatie concept in te richten.

Dit zorgde ervoor dat ik meer ben gaan nadenken over de mogelijke alternatieven voor dit soort complexe autorisatie concepten. Samen met mijn begeleider Paul Hamaker kwam ik tot het idee om gebruik te maken van nieuwe real-time monitoring technieken om compenserende of vervangende maatregelen te ontwerpen en in te richten zodat niet langer enkel op complete autorisatiestructuren gesteund hoeft te worden. De vraag waar vervolgens naar gekeken kan worden is of dit een oplossing kan bieden voor deze complexe

autorisatiestructuren. We zijn nu op een punt dat het technologisch mogelijk is om dit uit te voeren. De vraag is alleen hoe een organisatie dit het beste kan implementeren en wat de bijhorende risico’s en voordelen zijn.

Ook is de vraag hoe je hier als auditor mee om zou moeten gaan. Deze vragen beantwoord ik in deze scriptie.

Bij het zoeken naar een onderwerp voor deze scriptie, heb ik meerdere malen gesproken met Erwin Albers van SAP. In maart 2021 is hij bij zijn collega’s van verschillende teams gaan nazoeken of zij een tool konden bouwen waarmee transacties preventief geblokkeerd kunnen worden. Hij wist van een organisatie waar deze functionaliteit als maatwerk was gebouwd, maar er was nog geen tool beschikbaar die deze functionaliteit aanbood. In juni 2021 besprak hij dit ook met het team van SAP UI Masking. Zij gaven aan dat dit technisch mogelijk zou zijn, en gaven aan deze functionaliteit in hun tool te gaan bouwen. In oktober 2021 heb ik een interview gehouden met een aantal van hen. Op dit moment was de preventieve blokkeer-functionaliteit beschikbaar, hoewel deze nog niet af was. Ik heb hen gevraagd of het mogelijk was een workflow-

functionaliteit te bouwen en deze toe te voegen in de tool. Toen ik de programmeurs drie weken later weer sprak was de basis voor deze functionaliteit al gelegd en werkend.

Ik heb het erg bijzonder gevonden om op een afstand betrokken te zijn bij deze ontwikkeling.

Ik wil graag mijn begeleider Paul Hamaker bedanken voor zijn ondersteuning, de leerzame brainstormsessies en het beantwoorden van al mijn vragen. Als ik even vastzat, kwam hij altijd weer met nieuwe inzichten die me verder hielpen.

Mijn hartelijke dank gaat ook uit naar Erwin Albers die me in contact heeft gebracht met zijn collega’s bij SAP en heeft geregeld dat ik hen kon interviewen voor mijn scriptie. Ook wil ik hem bedanken voor alle gesprekken die ik met hem heb gehad over de mogelijkheden voor monitoring controles in SAP, en voor het binnen SAP promoten van het idee om preventieve blokkades te gaan bouwen.

Ook wil ik alle zeer ervaren professionals die ik heb mogen interviewen bedanken voor hun bijdrage.

Dankjewel Chris Radkowski, Susan Stapleton, Gerhard Hafner, Tobias Keller, Deepak Gupta, Gabriele Fiata, Deepa Sharma, Manpreet Kaur, Jack van Der Voort, Dennis Hallemeesch, Diego Ashruf, Ivan Spruit, Remko Lagendijk en Christiaan Dommerholt.

(4)

Als laatste wil ik ook mijn collega Sander van der Zon bedanken die altijd beschikbaar was voor het beantwoorden van mijn SAP-gerelateerde vragen.

(5)

Inhoudsopgave

Verklaring van eigen werk 2

Voorwoord 3

Samenvatting 6

1 Inleiding 9

1.1 Aanleiding 9

1.2 Context 10

1.3 Probleemstelling en onderzoeksvragen 10

1.4 Structuur van deze scriptie 10

2 Theoretisch kader 12

2.1 Definities 12

2.2 Toepassing 14

2.3 Praktisch kader 16

2.4 Technisch kader 18

3 Methodologie 20

3.1 Deelvraag 1 20

3.2 Deelvraag 2 20

3.3 Deelvraag 3 20

3.4 Hoofdvraag 21

4 Onderzoeksresultaten 22

4.1 Deelvraag 1 22

4.2 Deelvraag 2 26

Beslisboom 28

4.3 Deelvraag 3 30

5 Conclusie 32

6 Discussie 34

7 Literatuurlijst 36

Bijlagen 37

Interview SAP Identity Access Governance en Access Control 37

Interview SAP Access Violation Management 39

Interview SAP Business Integrity Screening 41

Interview SAP UI Masking 43

Interview SAP autorisatie consultant 46

Interview Technology Advisor 49

Interview accountant (RA) 51

Interview IT auditor (RE) 54

(6)

Samenvatting

Het autorisatie concept van SAP ECC en SAP S4 is complex, en veel bedrijven hebben moeite deze op een effectieve manier in te richten, waardoor er geen overzicht is van welke gebruikers welke rechten hebben (Vreeke & Hallemeesch, 2006) (Zon, Spruit, & Schutte, 2013). Hierdoor is het vaak niet duidelijk of de essentiële functiescheidingen wel op orde zijn.

Vanuit interne controle dienen organisaties functiescheiding te controleren in processen waar geen applicatie controles of handmatige controles zijn ingericht. Traditioneel wordt deze functiescheiding afgedwongen door autorisaties. Om meer inzicht te verkrijgen in de ingerichte autorisaties, wordt echter steeds vaker gekeken naar controles op uitgevoerde acties in plaats van ingerichte autorisaties omdat ingerichte autorisaties moeilijk inzichtelijk te maken zijn (Zon, Spruit, & Schutte, 2013).

De effectiviteit van deze controle kan vervolgens worden gemonitord door het genereren van rapportages, geven van meldingen en/of blokkeren van verdachte transacties. Om hun klanten te ondersteunen bij deze monitoring biedt SAP verschillende producten aan die deze functionaliteiten bieden, waaronder SAP Access Violation Management, SAP Business Integrity Screening en SAP UI Masking.

Deze scriptie onderzoekt het effect van het (gedeeltelijk) vervangen van autorisaties door monitoring

controles, welke voordelen en risico’s hieraan verbonden zijn, welke van deze controles in welke situaties het meest bruikbaar zijn en wat de impact van het gebruik van deze controles is op de auditor. Omdat dit

werkterrein heel erg breed is, is er voor gekozen om te focussen op SoD controles in SAP ECC en SAP S4.

Er is hierbij gekeken naar de volgende vier monitoring controles.

1. Controle 1: Periodieke rapportages

Uitzonderingen worden periodiek gerapporteerd in de vorm van rapportages. De controle eigenaar inspecteert de rapportages en neemt actie indien nodig.

2. Controle 2: Real time meldingen

Direct wanneer er zich een uitzondering voordoet, wordt deze gemeld aan de controle eigenaar, welke meteen actie kan ondernemen.

3. Controle 3: Real time meldingen, blokkeren en een workflow

Direct wanneer er zich een uitzondering voordoet, wordt deze gemeld aan de controle eigenaar.

Tevens worden de transacties waarin een uitzondering is geconstateerd geblokkeerd. De controle eigenaar inspecteert de uitzondering, neemt maatregelen indien nodig en deblokkeert de transacties.

4. Controle 4: Melding en blokkeren nog voor er op verzenden is geklikt en een workflow Wanneer een gebruiker gegevens in een transactie invult die tot een uitzondering zouden leiden, wordt de transactie geblokkeerd, nog voor er op verzenden is geklikt. De ingevoerde gegevens worden niet in een transactie opgeslagen. Deze gegevens worden in een aparte tabel opgeslagen. De controle eigenaar wordt real time op de hoogte gesteld. Hij inspecteert de uitzondering, bepaalt welke acties er moeten worden ondernomen en deblokkeert eventueel de transactie. Indien ervoor wordt gekozen om te deblokkeren, worden de gegevens vanuit de aparte tabel overgenomen in een transactie, waarmee verder gewerkt kan worden.

(7)

De volgende onderzoeksvragen zijn geformuleerd.

Hoofdvraag

Wat zijn de voordelen en risico’s van het gebruik van verschillende vormen van monitoring SoD controles in SAP, welke controles kunnen het best worden gebruikt in welke situatie en wat is de impact van het gebruik op de auditor?

Deelvragen

1. Wat zijn de voordelen en risico’s van het vervangen van autorisaties door monitoring SoD controles?

2. Welke soort van monitoring SoD controles kunnen het best worden gebruikt in welke situatie?

3. Wat is de impact van het gebruik van monitoring SoD controles op de auditor?

Om de onderzoeksvragen te kunnen beantwoorden zal literatuuronderzoek worden gedaan. Om de praktische uitvoerbaarheid te toetsen zullen er interviews worden gehouden met Product Architecten van de teams van SAP Identity Access Governance, SAP Access Violation Management, SAP Business Integrity Screening en SAP UI Masking. Ook zal er een interview worden gehouden met een SAP autorisatie consultant, een Technology Advisor, een ervaren RA en een ervaren RE. Voor de vierde mogelijkheid waarin transacties al worden geblokkeerd voordat deze zijn verzonden is op dit moment nog geen standaard tool beschikbaar.

Technisch en conceptueel is dit echter wel mogelijk en om inzicht te krijgen in de werking en implicaties, zal er voor deze scriptie en proof-of-technology worden opgezet door het development team van SAP UI Masking.

Zij zullen deze functionaliteit in hun tool bouwen. Met ondersteuning van een programmeur van SAP zal naar een opzet van deze functionaliteit worden gekeken om te zien hoe deze zou werken.

Resultaten

Wanneer een organisatie ervoor kiest om het autorisatie concept in te perken en gebruik te gaan maken van monitoring controles, kan dit leiden tot een lagere cost of control, terwijl het netrisico hetzelfde blijft. Hierbij is het belangrijk om de juiste controle mix te gebruiken. Op dit moment is er nog geen tool beschikbaar die alle 4 monitoring controles aanbiedt. Daarom is het op deze wijze inrichten van monitoring controles in de praktijk nog veel maatwerk en erg complex. Op dit moment is de verwachting dat dit nog niet tot een lagere cost of control leidt. Met de groeiende complexiteit van informatiesystemen als SAP, nieuwe regelgeving en eisen zou dit omslagpunt echter wel eens snel bereikt kunnen worden. Organisaties kunnen er daarom nu al rekening mee houden dat dit in de toekomst een reële optie zal zijn.

Naast de voordelen van een eenvoudiger autorisatie concept, kan het implementeren van monitoring controles ook nog andere voordelen opleveren, zoals de mogelijkheid om data-gebonden autorisaties te verstrekken, een beperking van overtredingen doordat medewerkers weten dat ze worden gemonitord en meer controle doordat de organisatie actief op de hoogte wordt gesteld van uitzonderingen die zich voordoen.

Naast deze voordelen moet er rekening worden gehouden met verschillende risico’s zoals overbelasting van het systeem, incorrecte configuratie, onvolledige monitoring, monitoring van onvoldoende kwaliteit,

onduidelijkheid over waarom een transactie is geblokkeerd, het stagneren van de business door te veel

(8)

blokkades, frustratie bij medewerkers, onvoldoende kennis bij medewerkers die mogen deblokkeren en de mogelijkheid dat het systeem te erg geblokkeerd is in geval van een calamiteit.

Om deze risico’s te mitigeren kunnen verschillende maatregelen worden genomen zoals voldoende aandacht schenken aan de implementatie en onderhoud van de monitoring controles, een degelijk proces voor het opvolgen van uitzonderingen, gebruik maken van logging, goede communicatie richting medewerkers en het inrichten van een firefighter procedure. Een firefighter procedure is een procedure waarbij in geval van nood, geautoriseerde gebruikers tijdelijk hoge maar gereguleerde rechten krijgen om het incident op te lossen, zodat zij hierbij niet tegen worden gehouden door eventueel geblokkeerde transacties.

Bij het maken van een keuze welke monitoring controles een organisatie wil gaan gebruiken moet het uitgangpunt altijd een risk assessment zijn. Per geïdentificeerd risico moet worden bepaald welke monitoring controle het best gebruikt kan worden. Hiertoe kan gebruik gemaakt worden van verschillende criteria zoals waar in het proces de controle zich voordoet, wat de impact is, wat de kans is dat het risico zich voordoet, hoe snel de organisatie op de hoogte gesteld wil worden van een mogelijke uitzondering, of het nodig is een transactie te blokkeren, of het zinvol is de transactie zelf te blokkeren en of het een risico is dat zich echt nooit voor mag doen.

Ook op de externe auditor kan het gebruik van monitoring controles impact hebben. Indien deze goed geïmplementeerd zijn kunnen zij hier op steunen in hun werk. Voor een accountant kan dit leiden tot een verkleining van het aantal samples dat getrokken moet worden.

Ook voor de interne auditor heeft het gebruik van monitoring controles een grote impact, gezien het gebruik van monitoring controles een grote impact kan hebben op de gehele IT omgeving. Voor het interne audit team is het daarom ook erg belangrijk om hiernaar te kijken.

(9)

1 Inleiding

1.1 Aanleiding

Het meest gebruikte ERP pakket is het wel bekende Duitse product SAP (Martens, 2019). Het autorisatie concept van SAP ECC en SAP S4 is complex, en veel bedrijven hebben moeite deze op een effectieve manier in te richten, waardoor er geen overzicht is van welke gebruikers welke rechten hebben (Vreeke &

Hallemeesch, 2006) (Zon, Spruit, & Schutte, 2013). Hierdoor is het vaak niet duidelijk of de essentiële

functiescheidingen wel op orde zijn. Zo kan het bijvoorbeeld gebeuren dat de crediteurenadministrateur via de ene taak autorisatie voor een betaalrun krijgt en via een andere taak toegang tot stamdata van crediteuren.

Los van elkaar vormen deze autorisaties geen probleem, maar in samenhang levert het een conflict op (Fluitsma, 2018).

Binnen SAP ECC en SAP S4 zijn verschillende methoden om autorisaties toe te kennen aan gebruikers. Zo moet er rekening worden gehouden met profielen, groepen en verschillende soorten rollen zoals enkele rollen, afgeleide rollen en samengestelde rollen (What is Authorization, 2021). Dit maakt het autorisatie concept extra ingewikkeld. Daarnaast zijn er binnen SAP S4 standaard al 3700 autorisatie objecten beschikbaar.

Het toekennen van rechten in SAP ECC en SAP S4 is een ingewikkelde balans die bedrijven moeten bereiken. Indien er te veel rechten worden vergeven ontstaan er conflicten en indien er te weinig rechten worden vergeven kunnen gebruikers hun werk niet doen (Roest & Rooij, 2008).

Aan de basis van dit probleem ligt het onderhouden van rollen in SAP ECC en SAP S4. In vele gevallen ontstaat er een wildgroei van rollen die niet meer te overzien is, wat het toekennen van de juiste rechten en het bepalen of gebruikers de juiste rechten hebben bemoeilijkt (Radkowski, 2021). Wanneer er geen duidelijke structuur is in de rollen, is het erg moeilijk deze te onderhouden (Voort, 2021).

Vanuit interne controle dienen organisaties functiescheiding te controleren in processen waar geen applicatie controles of manual controles zijn ingericht. Traditioneel wordt deze functiescheiding afgedwongen door autorisaties. Om meer inzicht te verkrijgen in de ingerichte autorisaties, wordt echter steeds vaker gekeken naar controles op uitgevoerde acties in plaats van ingerichte autorisaties omdat ingerichte autorisaties moeilijk inzichtelijk te maken zijn. Hiervoor zijn verschillende SAP access control applicaties ontwikkeld (Zon, Spruit, &

Schutte, 2013). In deze tools kunnen vooraf regels worden gedefinieerd, zoals “gebruikers mogen geen betaalrun uitvoeren voor crediteuren van wie zij zelf het bankrekeningnummer hebben aangepast”.

De effectiviteit van deze controle kan vervolgens worden gemonitord door het genereren van rapportages, geven van meldingen en/of blokkeren van verdachte transacties. Om hun klanten te ondersteunen bij deze monitoring biedt SAP verschillende producten aan die deze functionaliteiten bieden, waaronder SAP Access Violation Management (Frenehard, 2021), SAP Business Integrity Screening (Unknown, 2017) en SAP UI Masking (SAP, 2020). Deze functionaliteiten zijn momenteel geen onderdeel van de SAP standaard programmatuur. De verschillende tools zijn los van elkaar ontwikkeld en zijn niet standaard met elkaar geïntegreerd.

(10)

1.2 Context

Deze scriptie onderzoekt de mogelijke effecten van het (gedeeltelijk) vervangen van autorisaties door monitoring controles, welke voordelen en risico’s hieraan verbonden zijn, welke van deze controles in welke situaties het meest bruikbaar zijn en wat de impact van het gebruik van deze controles is op de auditor.

Het vervangen van autorisaties door monitoring controles was in het verleden niet mogelijk, maar door de ontwikkeling van nieuwe technologie bestaat deze mogelijkheid nu wel.

Hoewel veel van deze problematiek ook speelt in andere ERP pakketten zal er specifiek enkel worden gekeken naar SAP ECC en SAP S4 (hierna afgekort tot SAP).

Monitoring tools zijn toepasbaar op tal van controles, maar binnen dit onderzoek zal worden gefocust op SoD controles, om het onderwerp tastbaar te maken. Hierbij spreken we dan specifiek over SoD controles die standaard door autorisaties worden ingericht en dus niet over applicatie controles zoals het 4-ogen principe.

SAP heeft verschillende tools ontwikkeld waarmee transacties en acties van gebruikers kunnen worden gemonitord. De focus ligt hierbij op de tools SAP Access Violation Management, SAP Business Integrity Screening en SAP UI Masking.

Een gedeelte van de monitoring controles die zullen worden bekeken, zijn gebaseerd op relatief nieuwe technologieën en bestaan daarom nog niet lang. Er zal daarom worden gefocust op wat de mogelijkheden voor gebruik kunnen zijn. Er zal niet worden gekeken naar toepassingen in de praktijk.

1.3 Probleemstelling en onderzoeksvragen

De onderzoeksvraag die dit onderzoek tracht te beantwoorden is het volgende.

De deelvragen die hiertoe beantwoord zullen worden zijn als volgt.

1. Wat zijn de voordelen en risico’s van het vervangen van autorisaties door monitoring SoD controles?

2. Welke soort van monitoring SoD controles kunnen het best worden gebruikt in welke situatie?

3. Wat is de impact van het gebruik van monitoring SoD controles op de auditor?

Met het beantwoorden van deze deelvragen kan vervolgens de hoofdvraag worden beantwoord.

1.4 Structuur van deze scriptie

Deze scriptie is op de volgende wijze opgebouwd. Het eerste hoofdstuk is de inleiding. Hierin worden de aanleiding, context, probleemstelling en de onderzoeksvragen gegeven. In het tweede hoofdstuk is het theoretisch kader beschreven. De definities van belangrijke begrippen voor dit onderzoek worden gegeven en vervolgens wordt beschreven hoe deze definities op elkaar kunnen worden toegepast. Vervolgens wordt in het praktisch kader de toepassing gegeven van de begrippen in SAP en worden in het technisch kader de mogelijkheden en beperkingen beschreven van de technische inrichting van de verschillende controles. In het derde hoofdstuk wordt per deelvraag de methodologie beschreven. In het vierde hoofdstuk worden per

(11)

uitgevoerd zoals beschreven in hoofdstuk drie. In het vijfde hoofdstuk wordt een conclusie gegeven waarin de hoofdvraag wordt beantwoord. In hoofdstuk zes wordt een discussie opgenomen. Hierin wordt een reflectie opgenomen met betrekking tot het onderzoek. Ook worden de beperkingen van het onderzoek beschreven en de mogelijkheden voor vervolgonderzoek. In het zevende en laatste hoofdstuk is de literatuurlijst opgenomen.

De afgenomen interviews zijn bijgevoegd in de bijlagen.

(12)

2 Theoretisch kader

2.1 Definities

In dit hoofdstuk wordt een definitie gegeven voor verschillende begrippen die worden gebruikt in dit onderzoek.

Preventieve, detectieve en intermediaire controle

Een preventieve controle wordt door Starreveld gedefinieerd als een controle die de opzet van de organisatie betreft en vooraf door of namens de leiding of toezichthouders is getroffen (Starreveld, 1962), (Leeuwen &

Bergsma, 2014).

Een detectieve controle (of repressieve controle) wordt gedefinieerd als een controle die achteraf door of namens de leiding wordt genomen om vast te stellen dat de preventieve maatregelen gewerkt hebben (Starreveld, 1962), (Leeuwen & Bergsma, 2014).

In deze definities wordt gebruik gemaakt van de woorden “vooraf” en “achteraf”. Dit impliceert dat er een moment van een specifieke actie is vanuit waar wordt geredeneerd. Als de controle vóór dit moment wordt uitgevoerd, is deze preventief, en wanneer de controle ná dit moment wordt uitgevoerd is deze detectief.

Wanneer dit moment exact plaatsvindt wordt echter niet omschreven.

Ter illustratie kijken we naar het volgende proces. Inkoopfacturen worden door een medewerker van de afdeling inkoop in het ERP pakket ingevoerd. Eens per week worden alle facturen door de CEO betaald. In dit proces zijn de volgende drie controles ingericht.

A. Middels autorisaties is afgedwongen dat alleen medewerkers van de afdeling inkoop inkoopfacturen kunnen verwerken.

B. Voordat de CEO de inkoopfactuur betaalt, controleert hij of er een legitieme order ten grondslag ligt aan deze factuur.

C. Aan het eind van elke maand wordt de totale waarde van ingekochte goederen vergeleken met de begroting. Indien er ver van de begroting is afgeweken, wordt gedocumenteerd wat hiervoor de verklaring is.

Het is duidelijk dat controle A vooraf is getroffen. Dit is een preventieve controle. Ook is het duidelijk dat controle C achteraf wordt uitgevoerd. Dit is een detectieve controle.

Als we naar controle B kijken is dit echter minder duidelijk. Enerzijds gebeurt deze controle nadat de factuur in het ERP pakket is ingevoerd (achteraf, dus detectief). Anderzijds gebeurd de controle voordat de factuur betaald is (vooraf, dus preventief).

Ook (Voort, 2021) geeft aan dat het voor sommige controles niet altijd eenduidig is of deze preventief of detectief zijn.

In dit onderzoek definiëren we een controle die tijdens het proces plaatsvindt, dus nadat een gedeelte van het proces al is uitgevoerd en gedocumenteerd, maar voordat er een betaling wordt gedaan, een goed de

organisatie verlaat, een verplichting wordt aangegaan met een externe partij of een andere actie wordt uitgevoerd die niet meer ongedaan kan worden, als een intermediaire controle.

Autorisaties

Autorisaties zijn rechten om bepaalde acties te mogen uitvoeren die zijn toegekend aan specifieke gebruikers

(13)

Autorisaties zijn een vorm van preventieve SoD controle. Door specifieke rechten niet aan een gebruiker toe te kennen is het voor hem onmogelijk deze acties uit te voeren.

Vervangbare en onvervangbare controles

Een vervangbare controle is een controle die door de accountant (of een andere derde) kan worden

gecompenseerd door dezelfde of andersoortige werkzaamheden alsnog uit te voeren en hiermee de gebreken in de interne controle te compenseren (Starreveld, 1962), (Leeuwen & Bergsma, 2014).

Een onvervangbare controle is een controle waarbij dit niet het geval is (Starreveld, 1962), (Leeuwen &

Bergsma, 2014).

Het bovenstaande is specifiek gericht op de controlerend accountant. Wanneer een organisatie besluit een controle te vervangen, moet zij ook bepalen of zij hiermee niet te veel risico neemt. Er moet altijd worden gekozen voor een goede controle-mix die in lijn is met de risk-appetite (Coumou & Schoemaker, 1999).

Monitoring SoD controle

Een monitoring SoD controle is een controle op de acties die een gebruiker uitvoert in een applicatie.

De implementatie van een monitoring controle start altijd met het definiëren van regels. Wanneer er zich een uitzondering op een van deze regels voordoet, wordt dit gerapporteerd en indien nodig wordt er actie

ondernomen.

De volgende vormen van monitoring SoD controles worden bekeken. Deze zijn gegeven in volgorde van minste hoeveelheid controle naar meeste hoeveelheid controle en van minste impact naar meeste impact.

Controle 1: Periodieke rapportages

Uitzonderingen worden periodiek gerapporteerd in de vorm van rapportages. De controle eigenaar inspecteert de rapportages en neemt actie indien nodig.

Controle 2: Real time meldingen

Direct wanneer er zich een uitzondering voordoet, wordt deze gemeld aan de controle eigenaar welke meteen actie kan ondernemen.

Controle 3: Real time meldingen, blokkeren en een workflow

Direct wanneer er zich een uitzondering voordoet, wordt deze gemeld aan de controle eigenaar. Tevens worden de transacties waarin een uitzondering is geconstateerd geblokkeerd. De controle eigenaar inspecteert de uitzondering, neemt maatregelen indien nodig en deblokkeert de transacties.

Controle 4: Melding en blokkeren nog voor er op verzenden is geklikt en een workflow

Wanneer een gebruiker gegevens in een transactie invult die tot een uitzondering zouden leiden, wordt de transactie geblokkeerd, nog voor er op verzenden is geklikt. De ingevoerde gegevens worden niet in een transactie opgeslagen. Deze gegevens worden in een aparte tabel opgeslagen. De controle eigenaar wordt real time op de hoogte gesteld. Hij inspecteert de uitzondering, bepaalt welke acties er moeten worden ondernomen en deblokkeert eventueel de transactie. Indien ervoor wordt gekozen om te deblokkeren, worden de gegevens vanuit de aparte tabel overgenomen in een transactie, waarmee verder gewerkt kan worden.

(14)

Merk hierbij op dat het laatste onderdeel van controle 4, waarin een controle eigenaar de mogelijkheid krijgt om de transactie alsnog goed te keuren, deze controle programma-technisch extra complex maakt. Dit wordt verder beschreven in hoofdstuk 2.4. Dit onderdeel van deze controle definiëren we als de workflow in controle 4.

Controle 4 kan ook worden uitgevoerd zonder de workflow. In dit geval spreken we over de volgende controle:

Wanneer een gebruiker gegevens in een transactie invult die tot een uitzondering zouden leiden, wordt de transactie geblokkeerd, nog voor er op verzenden is geklikt. De gegevens worden in dit geval niet opgeslagen en het is onmogelijk deze transactie aan te maken.

2.2 Toepassing

In dit hoofdstuk wordt de relatie tussen verschillende definities in sectie 2.1 aangegeven, door de definities toe te passen.

Vervangbaarheid van verschillende typen controles

In hun boek over de algemene grondslagen van Starreveld geven Leeuwen en Bergsma ook aan dat

preventieve controles meestal niet vervangbaar zijn en detectieve controles wel. Een preventieve controle kan nooit worden vervangen door een detectieve controle omdat de accountant preventieve controles niet achteraf alsnog kan treffen (Leeuwen & Bergsma, 2014).

De vraag is nu of een preventieve controle wel kan worden vervangen door een intermediaire controle. Een intermediaire controle wordt niet door de accountant uitgevoerd, maar de accountant kan naderhand wel vaststellen dat deze controle is uitgevoerd. Daarnaast worden alle acties in de meeste moderne ERP pakketten (waaronder SAP) tegenwoordig gelogd. Indien autorisaties niet (volledig) zijn ingericht, kan een accountant daardoor naderhand nog valideren welke gebruiker welke boekingen gemaakt heeft.

Wanneer er voldoende logging in het systeem aanwezig is, is het dus mogelijk om een preventieve controle te vervangen door een intermediaire controle. Indien hiervoor wordt gekozen, moet de organisatie wel bepalen of zij hiermee niet te veel risico neemt. Er moet altijd worden gekozen voor een goede controle-mix die in lijn is met de risk-appetite (Coumou & Schoemaker, 1999), (Hafner, 2021), (Voort, 2021).

Eigenschappen van monitoring controles

Hieronder wordt per monitoring controle beschreven of het een preventieve, detectieve of intermediaire controle is.

Controle 1: Periodieke rapportages

Het periodiek genereren en inspecteren van rapportages van uitzonderingen is in het algemeen een detectieve controle.

In het specifieke geval dat een actie zoals het uitvoeren van een betaal run, of het afsluiten van een periode consistent eens per vaststaande periode (bijvoorbeeld week, maand, kwartaal of jaar) wordt uitgevoerd, kunnen specifieke uitzonderingen toch nog tijdig worden opgevolgd door de periodieke rapportage op het juiste moment te maken en uitzonderingen op te volgen (Voort, 2021), (Hafner, 2021), (Hallemeesch, Ashruf,

& Spruit, 2021).

(15)

Bijvoorbeeld, stel dat elke dinsdag de betaal run draait waarin alle betalingen van de afgelopen week (maandag tot en met zondag) worden verwerkt. Dan kan maandag ochtend de rapportage worden gedraaid en heeft de controle eigenaar de hele maandag om alle uitzonderingen op te volgen, voordat de betaalrun plaatsvindt, zie ook Tabel 1.

Ma Di Wo Do Vr Za Zo Ma Di

Week waarover wordt gerapporteerd. Alleen de inkoop facturen die in deze week zijn aangemaakt worden betaalt tijdens de betaalrun.

Draaien rapportage en opvolgen van uitzonderingen.

Uitvoeren betaalrun.

Tabel 1

De controle zoals hierboven beschreven is een intermediaire controle. Op het moment dat de controle wordt uitgevoerd, is een gedeelte van het proces al uitgevoerd. Echter, het proces is nog niet volledig uitgevoerd gezien er nog geen betaling is gedaan.

Controle 2: Real time meldingen

Ook het genereren van real time meldingen is een detectieve controle. De uitzondering heeft al plaatsgevonden wanneer de melding wordt gegeven.

In het specifieke geval dat een actie consistent eens per vaststaande periode wordt uitgevoerd, kunnen specifieke uitzonderingen toch nog tijdig worden opgevolgd door de meldingen tijdig op te volgen (Voort, 2021), (Hafner, 2021). Ook hier spreken we over een intermediaire controle. Zie “Controle 1: Periodieke rapportages” hierboven, voor een uitgebreide toelichting en een voorbeeld. In Tabel 2 is dit voorbeeld aangepast voor de situatie van real time meldingen.

Ma Di Wo Do Vr Za Zo Ma Di

Week waarover wordt gerapporteerd. Alleen de inkoop facturen die in deze week zijn aangemaakt worden betaalt tijdens de betaalrun. Tijdens deze week worden uitzonderingen real time gerapporteerd. Deze kunnen meteen worden opgevolgd.

Afronden van de opvolging van uitzonderingen.

Uitvoeren betaalrun.

Tabel 2

Controle 3: Real time meldingen, blokkeren en een workflow

Wanneer uitzonderingen in real time worden gemeld en de bijhorende transacties worden geblokkeerd, is het van de situatie afhankelijk of dit een intermediaire of een detectieve controle is. Indien er een uitzondering wordt geconstateerd in een actie die tijdens het proces plaatsvindt, is het vaak nog mogelijk het proces stil te leggen door de juiste transactie te blokkeren. In sommige gevallen is dit de transactie zelf en in sommige gevallen is dit een andere transactie verderop in het proces. Bijvoorbeeld, wanneer er een uitzondering wordt gevonden in een inkoopfactuur, kan deze worden geblokkeerd voor betaling. In dit geval is dit een

intermediaire controle. Wanneer de uitzondering echter plaatsvindt aan het einde van het proces, bijvoorbeeld bij het uitvoeren van een betaalrun, is het een detectieve controle.

(16)

Controle 4: Melding en blokkeren nog voor er op verzenden is geklikt en een workflow

Wanneer uitzonderingen al worden gedetecteerd nog voordat er op verzenden is geklikt, is dit een

preventieve controle. Deze is vooraf genomen en wordt uitgevoerd voordat er een transactie in het systeem is verwerkt, dus nog voordat er een actie is uitgevoerd.

De eigenschappen van de verschillende controles zijn samengevat in Tabel 3.

Preventief Intermediair Detectief

Controle 1: Periodieke rapportages 2 1

Controle 2: Real time meldingen 2 1

3 3

1

Legenda

1 In het algemeen is deze eigenschap van toepassing op deze controle.

2 Alleen in specifieke gevallen.

3 Afhankelijk van de situatie.

Tabel 3 Eigenschappen van monitoring controles.

2.3 Praktisch kader

In dit onderzoek worden drie SAP tools bekeken, namelijk SAP Access Violation Management, SAP Business Integrity Screening en SAP UI Masking. Hieronder is per tool een korte introductie gegeven.

SAP Access Violation Management

De SAP access Violation management tool is geschreven door Pathlock (voorheen Greenlight), een partner van SAP. Dit is gedaan in reactie op de invoering van de SoX-wetgeving. De tool geeft organisaties inzicht in wanneer SoD gebroken wordt door het geven van meldingen. Deze worden traditioneel gegeven in de vorm van periodieke rapportages. De tool kan ook gebruikt worden om de financiële impact van specifieke toegangsrisico’s te bepalen.

SAP Business Integrity Screening

De SAP business Integrity Screening tool is geschreven door SAP om het makkelijker te maken om verdachte transacties te detecteren. Dit was voor het eerst mogelijk na de introductie van de HANA database. De tool geeft inzicht door het analyseren van de grote hoeveelheden data die beschikbaar zijn in SAP. Uit deze data wordt bepaald welke transacties potentieel verdacht kunnen zijn, zodat de organisatie dit kan beoordelen en actie kan ondernemen indien nodig. De incidenten worden weergegeven in dashboards om overzicht te creëren. Ook kunnen er meldingen worden gegeven wanneer uitzonderingen zich voordoen en kunnen verdachte transacties worden geblokkeerd.

(17)

SAP UI Masking

De SAP UI Masking tool is ontwikkeld door SAP in reactie op de invoering van de GDPR wetgeving. De tool wordt gebruikt om potentieel gevoelige data onzichtbaar te maken voor specifieke gebruikers. Hiermee geeft het organisaties de mogelijkheid om beter te controleren welke gebruiker welke data kan inzien. Naast deze Masking functionaliteit, is het met de UI Masking tool ook mogelijk om de functionaliteit van specifieke

knoppen te blokkeren in specifieke gevallen. Deze functionaliteit wordt “Data Exploit Prevention” genoemd, en is op het moment van schrijven van deze scriptie nog in ontwikkeling. Naar verwachting zal deze functionaliteit beschikbaar komen voor gebruikers in 2022. Er is nog geen release datum bekend.

De eerste versie van de Data Exploit Prevention functionaliteit zal alleen de mogelijkheid hebben om het aanmaken van specifieke transacties te blokkeren in specifieke gevallen. De gebruiker krijgt in dit geval een melding dat deze transactie niet aangemaakt kan worden. De data die de gebruiker in dit geval ingeeft in de transactie zal dan niet worden opgeslagen (Keller, Deepak, Fiata, Sharma, & Kaur, 2021). In terminologie van dit onderzoek is dit controle 4 zonder workflow.

Nadat deze versie is uitgebracht, zal het UI Masking team de tool nog verder gaan uitbreiden en ook een workflow-functionaliteit toevoegen. Indien een gebruiker input variabelen ingeeft die tot een uitzondering zouden leiden, krijgt hij een melding dat deze transactie een uitzondering veroorzaakt. De gebruiker krijgt vervolgens de optie om op een knop te klikken waarna de ingevoerde gegevens alsnog worden opgeslagen.

Deze gegevens worden opgeslagen in een aparte tabel. De transactie zelf is dan dus nog niet aangemaakt.

Er zal vervolgens een melding worden gestuurd naar een controle eigenaar die op basis van de input data kan bepalen of de transactie wordt vrijgegeven of niet (Keller, Deepak, Fiata, Sharma, & Kaur, 2021).

In Tabel 4 is per tool aangegeven welke monitoring controles hierin geïmplementeerd zijn.

SAP Access Violation Management

SAP Business Integrity Screening

SAP UI Masking

Controle 1: Periodieke rapportages 1 1

Controle 2: Real time meldingen 2 1

3 1

3 3 4

Legenda

1 Dit is standaard onderdeel van deze software.

2 Het is mogelijk om meldingen (vrijwel) real time te genereren, maar de toepassing is hier niet specifiek voor ontwikkeld.

3 Het is mogelijk deze functionaliteit toe te voegen middels het schrijven van maatwerk. Deze functionaliteit is geen onderdeel van de standaard software. Hieraan zijn naast de aanschaf van de tool nog extra kosten verbonden.

4 Er wordt momenteel gewerkt aan het toevoegen van deze functionaliteit aan deze tool. Deze functionaliteit is op het moment van schrijven van deze scriptie nog niet beschikbaar.

Tabel 4 Eigenschappen van SAP monitoring tools.

(18)

Hierbij is het belangrijk om op te merken dat deze monitoring controles geen onderdeel zijn van SAP

standaard programmatuur. Deze tools zijn apart geprogrammeerd en een organisatie die deze wil gebruiken moet hiervoor ook een aanvullende licentie kopen. De functionaliteit van het blokkeren van meldingen nog voor er op verzenden is geklikt (Controle 4) is vervolgens weer geen standaard onderdeel van de tool en moet hier weer als maatwerk in gebouwd worden. Naar verwachting zal controle 4 wel een standaard functionaliteit worden van de UI Masking tool, maar dit is op dit moment nog niet beschikbaar (Keller, Deepak, Fiata, Sharma, & Kaur, 2021).

De verschillende tools zijn los van elkaar ontwikkeld en zijn niet standaard met elkaar geïntegreerd. Er zijn geen certificeringen beschikbaar die de gebruiker zekerheid geven over het correct functioneren van de tools.

De tools zijn op de applicatie laag van de SAP standaard applicatie geprogrammeerd. Meldingen en blokkades worden niet op database niveau gegeven.

2.4 Technisch kader

Technisch gezien is de ene monitoring controle makkelijker in te richten dan de andere. Hieronder is een beschrijving gegeven van de mogelijkheden en beperkingen per controle.

Periodieke rapportages zijn relatief eenvoudig te produceren uit loggegevens. Dit is over het algemeen niet belastend voor het systeem en deze controle wordt dan ook al jaar en dag gebruikt om meer inzicht te verkrijgen.

Het genereren van real time meldingen is meer belastend voor het systeem. Er is veel meer rekenkracht nodig om continu te monitoren of er ergens in het systeem een uitzondering heeft plaatsgevonden.

Hedendaagse computersystemen kunnen dit over het algemeen wel aan, maar dit is afhankelijk van verschillende factoren zoals de hoeveelheid data in het systeem, de hoeveelheid nieuwe transacties die worden aangemaakt per tijdseenheid, de hoeveelheid monitoring controles, het soort monitoring controles en de hoeveelheid beschikbare capaciteit van het systeem.

Het genereren van de meldingen op zich is technisch gezien niet erg ingewikkeld. Hiervoor kunnen de beschikbare loggegevens worden gebruikt.

Het genereren van real time meldingen en vervolgens het blokkeren van relevante transacties is over het algemeen niet veel meer belastend of complex dan alleen het genereren van real time meldingen. Wanneer er eenmaal is bepaald dat zich een uitzondering heeft voorgedaan is het blokkeren van de relevante transactie relatief eenvoudig.

Het geven van een melding en het blokkeren nog voor er op verzenden is geklikt is de meest belastende controle die in dit onderzoek wordt omschreven. Dit moet niet alleen real time gebeuren, maar er moeten ook

(19)

bepaalde gevallen kan dit erg complex worden en daarom erg veel rekenkracht kosten. Ter illustratie zijn hieronder drie situaties weergegeven.

1. Er wordt een monitoring controle ingericht waarbij alle transacties worden geblokkeerd als zij om een bedrag van meer dan 100.000 euro gaan.

Deze controle is relatief eenvoudig. De enige actie die het systeem op de achtergrond moet uitvoeren is het vergelijken van het bedrag van de transactie met 100.000. Het inrichten van deze controle zal dus niet erg belastend zijn voor het systeem, en is ook niet erg ingewikkeld om te programmeren.

2. Er wordt een monitoring controle ingericht waarbij alle facturen worden geblokkeerd die zijn aangemaakt door een gebruiker die ook de bijhorende order heeft aangemaakt.

Deze controle is een stuk ingewikkelder. Om te bepalen of een factuur geblokkeerd moet worden, zal eerst moeten worden bepaald wie de bijhorende order heeft aangemaakt. Daarna moeten de

gebruikersnamen worden vergeleken om te bepalen of de factuur door dezelfde persoon wordt aangemaakt of niet.

3. Er wordt een monitoring controle ingericht waarbij betalingen worden geblokkeerd wanneer zij worden uitgevoerd door een gebruiker die gedurende het afgelopen jaar de debiteur heeft gewijzigd.

Deze controle is nog een stuk ingewikkelder. Uit het log van de wijzigingen aan de debiteur die in het afgelopen jaar zijn gemaakt moet worden bepaald welke gebruikers deze wijzigingen hebben

gemaakt. Vervolgens moet worden bepaald of de gebruiker die de betaling uitvoert voorkomt in deze lijst.

Uit de bovenstaande voorbeelden blijkt dat de complexiteit erg van het soort controle afhankelijk is. Dit kan uiteindelijk zeer complex worden, en daardoor erg veel rekenkracht opeisen.

Ook het programmeren van deze controle is complex. Dit komt doordat de transactie zelf nog niet bestaat op het moment dat al moet worden bepaald of deze geblokkeerd moet worden. SAP is hier niet standaard op ingericht. Hierdoor is het programmeren van deze controle een stuk ingewikkelder dan het programmeren van een controle waarbij de criteria voor het al dan niet blokkeren zijn vastgelegd in een transactie die al in het systeem vastligt.

Wat het programmeren van deze controle extra ingewikkeld maakt, is de workflow die hierin is opgenomen.

Om dit mogelijk te maken, moeten de gegevens die de gebruiker invoert in een aparte tabel worden opgeslagen, zodat deze vervolgens aan de controle eigenaar getoond kunnen worden. Indien de controle eigenaar de transactie goedkeurt, moeten deze gegevens vervolgens alsnog in een transactie worden opgenomen waarmee verder kan worden gewerkt. Dit is op dit moment technisch mogelijk, maar staat allemaal nog erg in de kinderschoenen (Keller, Deepak, Fiata, Sharma, & Kaur, 2021). Daarom zou je er ook voor kunnen kiezen om controle 4 zonder de workflow te implementeren. Dit leidt echter tot aanvullende risico’s waarmee rekening moet worden gehouden, zie ook hoofdstuk 4.1.

(20)

3 Methodologie

De volgende methode zal worden gebruikt om de onderzoeksvragen te beantwoorden.

3.1 Deelvraag 1

Wat zijn de voordelen en risico’s van het vervangen van autorisaties door monitoring SoD controles?

Om deze vraag te beantwoorden zal er onderzoek gedaan worden naar de eigenschappen van de verschillende vormen van monitoring SoD controles en de risico’s van het (gedeeltelijk) vervangen van preventieve SoD controles door monitoring SoD controles. Hiertoe zal in de literatuur gekeken worden naar wat hierover al is geschreven. Daarnaast zal er een interview worden gehouden met Product Architecten van de teams van SAP Access Violation Management, SAP Business Integrity Screening en SAP UI Masking om te bepalen welke functionaliteiten deze tools hebben en welke voordelen en risico’s hieraan zijn verbonden.

Voor de vierde mogelijkheid waarin transacties al worden geblokkeerd voordat deze zijn verzonden is op dit moment nog geen tool beschikbaar. Het is echter wel mogelijk om deze controle te bouwen in SAP UI Masking. SAP werkt op dit moment aan het ontwikkelen van deze functionaliteit. Er zal een interview worden gehouden met de Product owner en een programmeur van UI Masking om inzicht te krijgen in de

functionaliteiten van deze tool.

Ook zal er een interview worden gehouden met een Product Architect van SAP Identity Access Governance en Access Control, om inzicht te krijgen in zijn visie op monitoring controles en de voordelen en risico’s hiervan.

Hierbij moet worden opgemerkt dat tijdens het uitvoeren van het literatuuronderzoek bleek dat er niet veel literatuur beschikbaar is over dit onderwerp. Daarom is er voornamelijk gesteund op andere

onderzoeksmethoden, zoals interviews.

3.2 Deelvraag 2

Welke soort van monitoring SoD controles kunnen het best worden gebruikt in welke situatie?

Om deze vraag te beantwoorden zal literatuuronderzoek worden gedaan naar monitoring controles en access control. Vervolgens zal er een interview worden gehouden met Product Architecten van de teams van SAP Access Violation Management, SAP Business Integrity Screening en SAP UI Masking om te bepalen wat de visie van de ontwikkelaar op het gebruik van het product is. Ook zal er een interview worden gehouden met een SAP autorisatie consultant en een Technology Advisor om te bepalen hoe zij kijken naar het gebruik van monitoring. Daarnaast zal er worden gekeken naar de antwoorden op deelvraag 1.

Hierbij moet worden opgemerkt dat tijdens het uitvoeren van het literatuuronderzoek bleek dat er niet veel literatuur beschikbaar is over dit onderwerp. Daarom is er voornamelijk gesteund op andere

onderzoeksmethoden, zoals interviews.

3.3 Deelvraag 3

Wat is de impact van het gebruik van monitoring SoD controles op de auditor?

Deze vraag zal worden beantwoord aan de hand van de inzichten uit het theoretisch en praktisch kader en door het houden van een interview met een ervaren RE en een ervaren RA om hun inzicht in de impact te bepalen.

(21)

3.4 Hoofdvraag

Wanneer deelvragen 1, 2 en 3 zijn beantwoord, kan ook de hoofdvraag worden beantwoord.

(22)

4 Onderzoeksresultaten

In dit hoofdstuk worden de onderzoeksresultaten beschreven.

4.1 Deelvraag 1

Wat zijn de voordelen en risico’s van het vervangen van autorisaties door monitoring SoD controles?

Hieronder worden eerst de voordelen van het vervangen van autorisaties door monitoring controles genoemd.

Daarna wordt een overzicht gegeven van de risico’s, beginnend bij een algemeen risico. Vervolgens wordt een overzicht gegeven van de aanvullende risico’s in het geval dat autorisaties (gedeeltelijk) worden

vervangen door monitoring controles. Daarna wordt hierop een aanvullend overzicht gegeven van de risico’s in het geval dat er transacties geblokkeerd zullen worden. Aan het einde van deze sectie wordt per

monitoringvorm aangegeven of het mogelijk is om autorisaties gedeeltelijk door deze controle te vervangen.

In het geval dat autorisaties (gedeeltelijk) kunnen worden vervangen door monitoring controles, geeft dit de volgende voordelen:

 Het is niet meer noodzakelijk alle autorisaties omtrent dit onderwerp waterdicht in te richten. Indien een medewerker te veel rechten heeft en deze gebruikt, zal deze transactie worden geblokkeerd en kan de fout teruggezet worden. Daardoor kan er gebruik gemaakt worden van een veel eenvoudiger autorisatie concept dat makkelijker te onderhouden is (Radkowski, 2021).

 Het is mogelijk twee conflicterende rechten aan één medewerker toe te kennen, en te monitoren dat zij deze niet voor dezelfde transactie gebruiken. Dit wordt ook wel “data gebonden autorisaties”

genoemd (Voort, 2021).

 Indien medewerkers weten dat er een monitoring controle is ingericht, verkleint dit de kans dat zij opzettelijk fouten zullen maken of fraude zullen plegen (Hafner, 2021).

 Wanneer er “blind” op het autorisatie concept wordt gesteund, kan dit een vorm van schijnzekerheid geven. Je krijgt als organisatie geen enkele informatie over uitzonderingen die zich eventueel voor zouden kunnen doen. Wanneer je het autorisatie concept (gedeeltelijk) vervangt door monitoring, krijg je als organisatie meer informatie over de uitzonderingen die zich voordoen, en kan je hierop acteren (Dommerholt, 2021).

In het algemeen moet er rekening worden gehouden met het volgende risico:

 Indien er te veel complexe monitoring controles worden ingericht bestaat het risico dat dit te belastend is voor het systeem, waardoor dit kan gaan vastlopen en je bijvoorbeeld elke keer dat je een

transactie invoert een paar seconden moet wachten voordat het systeem heeft bepaald of je

transactie een melding veroorzaakt of niet (Voort, 2021). De snelheid in de doorvoer van het systeem is over het algemeen een belangrijk criterium om rekening mee te houden (Hafner, 2021).

Afhankelijk van welke tool wordt gebruikt, kan het inrichten van grote hoeveelheden monitoring controles leiden tot performance issues (Voort, 2021), (Hafner, 2021), (Stapleton, 2021). Hiermee moet rekening worden gehouden bij de keuze van een tool.

De kans op het trager worden van het systeem is groter naar mate er meer complexe controles

(23)

In het geval dat autorisaties (gedeeltelijk) worden vervangen door monitoring controles, geeft dit de volgende risico’s:

 De controles moeten worden ingericht. Dit kan een complex proces zijn, afhankelijk van de controles die de organisatie wil inrichten en de tool die gebruikt wordt (Radkowski, 2021). Ook moet worden getest of de controles die zijn ingericht wel alles blokkeren dat zij horen te blokkeren. Alle mogelijke paden die kunnen worden doorlopen om een transactie aan te maken, moeten worden doorlopen om te bepalen of deze allemaal op een juiste wijze worden geblokkeerd. Dit kan behoorlijk tijdrovend zijn en moet goed gebeuren, anders is de controle niet waterdicht (Keller, Deepak, Fiata, Sharma, & Kaur, 2021). De complexiteit hiervan is afhankelijk van de tool die wordt gebruikt en de controle die wordt ingericht.

 Ook de inrichting van de monitoring controles moet worden onderhouden. Dit wordt complexer naar mate er meer monitoring controles worden ingericht (Voort, 2021), (Hallemeesch, Ashruf, & Spruit, 2021).

 Een ander risico waarmee rekening moet worden gehouden is dat de meldingen niet (volledig) worden gemonitord. Hoe meer meldingen een tool genereert, hoe groter de kans dat een beheerder een melding over het hoofd ziet. Daarom is het belangrijk om de tool zo in te richten dat false-

positives zo veel mogelijk worden voorkomen. Dit is echter wel een balanseer-act, het is namelijk niet de bedoeling dat de tool legitieme meldingen niet meldt omdat deze worden gezien als een false- positive. Hier moet goed naar worden gekeken bij de inrichting. Het is daarom belangrijk voldoende tijd te steken in het volledig en compleet implementeren van de tool (Stapleton, 2021), (Hafner, 2021), (Hallemeesch, Ashruf, & Spruit, 2021).

 Naast het bovenstaande moet er in het algemeen rekening mee worden gehouden dat er tijd vrij moet worden gemaakt om rapportages te beoordelen en/of meldingen te monitoren (Dommerholt, 2021).

 Gebruikers met toegang tot de debug-functionaliteit kunnen mogelijk om de monitoring controles heen werken. Toegang tot de debug-functionaliteit moet daarom zo veel mogelijk worden beperkt

(Hallemeesch, Ashruf, & Spruit, 2021). Het kan ook verstandig zijn om het gebruik van de debug- functionaliteit zelf te monitoren (Keller, Deepak, Fiata, Sharma, & Kaur, 2021).

Daarnaast is het belangrijk om een proces in te richten waarbij actie wordt ondernomen als een specifieke medewerker vaak meldingen veroorzaakt.

In het geval dat er transacties geblokkeerd zullen worden, dus wanneer gebruik wordt gemaakt van controles 3 of 4, moet er rekening worden gehouden met de volgende aanvullende risico’s:

 Indien transacties automatisch kunnen worden geblokkeerd, bestaat het risico dat legitieme

transacties worden geblokkeerd. Indien deze niet tijdig worden gedeblokkeerd, stagneert de business (Radkowski, 2021), (Hallemeesch, Ashruf, & Spruit, 2021). Daarom is het belangrijk om meldingen continu te monitoren.

 Indien er gebruik wordt gemaakt van controle 4 zonder de workflow, is dit risico nog groter, gezien bepaalde transacties dan helemaal niet aangemaakt kunnen worden. Indien deze controle niet juist is geïmplementeerd, kan dit de hele business stagneren (Hallemeesch, Ashruf, & Spruit, 2021),

(Dommerholt, 2021).

(24)

 Indien medewerkers er zich niet van bewust zijn dat er gebruik wordt gemaakt van een tool waarbij transacties automatisch worden geblokkeerd, bestaat het risico dat dit leidt tot verwarring en irritatie.

Daarom is het belangrijk dat medewerkers zijn geïnformeerd dat er gebruik wordt gemaakt van een dergelijke tool. Goede communicatie is hierbij belangrijk. Je wil voorkomen dat medewerkers het idee krijgen dat het systeem hen blokkeert en daarom gaan proberen “om het systeem heen te werken”, door bijvoorbeeld meer handmatige boekingen te gaan maken, of door een geblokkeerde transactie nog eens aan te maken, maar dan net iets anders vast te leggen, in de hoop dat deze niet

geblokkeerd wordt. Het zou bijvoorbeeld kunnen helpen om het blokkeren van een transactie richting de medewerker niet te communiceren als een blokkade, maar als een workflow waarin een 2^e

persoon meekijkt met transacties die potentieel uitzonderingen kunnen vormen (Lagendijk, 2021), (Hallemeesch, Ashruf, & Spruit, 2021).

 Indien er te veel false-positeves gemeld worden, ontstaat het risico dat de controle eigenaar de meldingen niet bij kan houden of de meldingen niet goed meer leest voordat hij ze deblokkeert. Het is daarom ook belangrijk om het systeem zo in te richten dat false-positives zo veel mogelijk worden voorkomen (Stapleton, 2021).

In het geval van controle 4 kan de wijze waarop de controle is ingericht hier ook bij helpen. Wanneer het systeem detecteert dat een gebruiker gegevens invoert die tot een uitzondering leiden, kan er eerst een melding aan de gebruiker worden gegeven waarin wordt gemeld dat deze transactie tot een uitzondering zal leiden en dat deze daarom eerst zal moeten worden goedgekeurd. Vervolgens kan het systeem aan de gebruiker vragen of hij de transactie nog steeds wil aanmaken. Dit zorgt ervoor dat de gebruiker een extra keer nadenkt over het aanmaken van deze transactie. Indien het echt noodzakelijk is om de transactie aan te maken, krijgt hij de mogelijkheid, maar als het niet nodig is kan hij er ook voor kiezen het niet te doen, waardoor de controle eigenaar geen melding krijgt en deze ook niet hoeft te inspecteren.

Merk op dat het bovenstaande alleen mogelijk is wanneer er gebruik wordt gemaakt van controle 4 met workflow. Bij controle 3 wordt pas nadat de transactie is aangemaakt gesignaleerd dat deze een uitzondering bevat. Het is dan niet meer mogelijk om de gebruiker de keuze te geven om de

transactie niet meer aan te maken.

 Indien er gebruik wordt gemaakt van controle 3, moet worden bepaald wat er moet worden geblokkeerd in geval van een uitzondering. Bijvoorbeeld, indien er een uitzondering wordt

geconstateerd in een inkoopfactuur, zou niet de factuur, maar de bijhorende betaling geblokkeerd moeten worden (Voort, 2021). Dit kan tot een extra risico leiden wanneer niet de juiste transactie wordt geblokkeerd.

 Er moet ook worden bepaald welke gebruikers er mogen deblokkeren, en wat zij mogen deblokkeren.

Deze gebruikers moeten voldoende kennis hebben om te bepalen waarom de transactie was

geblokkeerd en of er actie moet worden ondernomen voordat deze kan worden gedeblokkeerd (Voort, 2021). Ook moet de medewerker die mag deblokkeren voldoende hiërarchie hebben over de

medewerkers die de transacties hebben aangemaakt. Medewerkers zouden bijvoorbeeld niet hun eigen leidinggevende moeten kunnen controleren (Lagendijk, 2021).

 Het bovenstaande risico wordt groter wanneer er gebruik wordt gemaakt van controle 3, en ervoor is gekozen om niet de transactie zelf te blokkeren, maar een andere transactie verderop in het proces.

(25)

transactie. Voor een controle eigenaar wordt het daarom nog complexer om te bepalen of een transactie weer gedeblokkeerd kan worden (Voort, 2021).

 In geval van een calamiteit moet het altijd mogelijk blijven om geblokkeerde transacties snel weer te deblokkeren. Daarom is het belangrijk een firefighter procedure in te richten (Voort, 2021). In deze procedure moet worden beschreven hoe, in geval van nood, geautoriseerde gebruikers tijdelijk toegang krijgen tot een noodaccount met hoge maar gereguleerde rechten. Hierdoor kunnen zij het incident op lossen, zonder dat zij hierbij tegen worden gehouden door eventueel geblokkeerde transacties.

Hieronder wordt per monitoringvorm aangegeven of het mogelijk is om autorisaties gedeeltelijk door deze controle te vervangen.

Periodieke rapportages zijn in het algemeen een detectieve controle, zie sectie 2.2. In het algemeen kunnen preventieve controles nooit volledig vervangen worden door detectieve controles (Leeuwen & Bergsma, 2014), (Voort, 2021). De uitzonderingen hebben al plaatsgevonden, dus het is vaak niet meer mogelijk om deze nog (volledig) te herstellen. Wel kunnen er maatregelen worden genomen om ervoor te zorgen dat deze uitzonderingen zich in de toekomst niet nogmaals voordoen. Dit kan bijvoorbeeld worden gedaan door het intrekken van rechten van de gebruiker die de uitzondering heeft veroorzaakt. Indien de uitzondering is veroorzaakt door een fout van een medewerker, kan deze hierop gewezen worden, zodat dit in de toekomst niet nogmaals zal gebeuren. Indien het gaat om een geval van fraude kunnen er indien gewenst juridische acties worden ondernomen.

Proctor, Heiser en MacDonald beschrijven het periodiek of continu monitoren van SoD controles als een methode voor het detecteren van fouten in de preventieve controles zoals het inrichten van autorisaties (Proctor, Heiser, & MacDonald, 2007). Ook Kudo beschrijft rapportages als een onderdeel van een ERP pakket dat gebruikt kan worden om SoD beter in te richten (Kudo, 2012, januari 5).

Deze controle moet dus niet worden gebruikt om autorisaties te vervangen, maar juist om de inrichting van autorisaties te verbeteren. Het voordeel van het op deze wijze implementeren van deze controle is dat SoD conflicten eerder zullen worden opgespoord en kunnen worden verholpen.

Indien deze controle toch wordt gebruikt om autorisaties te vervangen, loopt de organisatie het risico dat uitzonderingen te laat worden ontdekt en niet meer kunnen worden hersteld.

In sectie 2.2 is beschreven dat er specifieke gevallen zijn waarin periodieke rapportages een intermediaire controle zijn. Zoals aangegeven in sectie 2.2 is het mogelijk om de preventieve controle van autorisaties te vervangen door deze controle. Een voorwaarde hiervoor is wel dat logging is ingeschakeld zodat achteraf kan worden gevalideerd welke gebruiker welke boekingen heeft gemaakt. Ook moet de organisatie bepalen of zij niet te veel risico neemt en of dit wel in lijn is met de risk-appetite.

Zoals beschreven in sectie 2.2 zijn ook real time meldingen een detectieve controle. Ook deze controle kan daarom niet worden gebruikt om autorisaties (volledig) te vervangen (Leeuwen & Bergsma, 2014), (Voort, 2021).

(26)

Deze controle is een vorm van continuous monitoring. Zowel (Proctor, Heiser, & MacDonald, 2007) als (Turner & Owhoso, 2009) geven aan dat continuous monitoring het best kan worden gebruikt om SoD uitzonderingen op te sporen en vervolgens aan te passen.

Ook deze controle moet dus niet worden gebruikt om autorisaties te vervangen, maar juist om de inrichting van autorisaties te verbeteren. Het voordeel van het op deze wijze implementeren van deze controle is dat SoD conflicten direct kunnen worden opgespoord en verholpen wanneer er zich een uitzondering voordoet.

Indien deze controle toch wordt gebruikt om autorisaties te vervangen, loopt de organisatie het risico dat uitzonderingen te laat worden ontdekt en niet meer kunnen worden hersteld. Dit risico is kleiner dan in het geval van periodieke rapportages omdat uitzonderingen real time gemeld worden.

In sectie 2.2 is beschreven dat er specifieke gevallen zijn waarin real time meldingen een intermediaire controle zijn. Zoals aangegeven in sectie 2.2 is het in dit geval mogelijk om autorisaties te vervangen door deze controle, maar dan moet logging zijn ingeschakeld zodat achteraf kan worden gevalideerd welke gebruiker welke boeking heeft gemaakt en er moet worden bepaald of er niet te veel risico wordt genomen.

Wanneer uitzonderingen in real time worden gemeld en de bijhorende transacties worden geblokkeerd, is het van de situatie afhankelijk of dit een intermediaire of een detectieve controle is, zie sectie 2.2. Indien het een detectieve controle is, kunnen autorisaties niet door deze controle worden vervangen. Indien het een

intermediaire controle is, is dit wel mogelijk, zie sectie 2.2. Wanneer er voor wordt gekozen om gebruik te maken van deze controle, moet rekening worden gehouden met de risico’s die bovenaan deze sectie zijn beschreven.

Wanneer uitzonderingen al worden gedetecteerd nog voordat er op verzenden is geklikt, is dit een detectieve controle, zie sectie 2.2. Het is daarom mogelijk om autorisaties te vervangen door deze controle. Hierbij moet rekening worden gehouden met de hierboven gegeven risico’s.

4.2 Deelvraag 2

Welke soort van monitoring SoD controles kunnen het best worden gebruikt in welke situatie?

Uit de interviews die zijn gehouden met verschillende SAP medewerkers, blijkt dat alle vier de vormen van monitoring technisch mogelijk zijn en grotendeels ook al bestaan. De verschillende beschikbare tools kunnen volledig worden geconfigureerd en gecustomised indien nodig (Stapleton, 2021), (Hafner, 2021), (Keller, Deepak, Fiata, Sharma, & Kaur, 2021). Er bestaat op dit moment echter nog geen tool waarin monitoring controle 4 standaard is geïmplementeerd. Ook bestaat er nog geen tool die standaard beschikt over alle functionaliteiten voor de vier monitoringvormen, zie ook tabel 4 in sectie 2.3. Het efficiënt implementeren van deze controles is daarom vaak nog lastig. Naast deze beperkingen zijn de beschikbare tools vaak erg prijzig, waardoor het gebruik ervan vaak niet kosten-efficiënt is (Hallemeesch, Ashruf, & Spruit, 2021).

De complexiteit van de implementatie van verschillende tools kan verschillen. Voor sommige tools zullen de meeste organisaties de implementatie niet zelf kunnen uitvoeren, en zullen zij externe SAP consultants

(27)

moeten inhuren (Radkowski, 2021), (Keller, Deepak, Fiata, Sharma, & Kaur, 2021), terwijl voor andere tools het implementatie proces een stuk minder complex is (Stapleton, 2021), (Hafner, 2021).

Een organisatie kan verschillende beweegredenen hebben om monitoring controles te implementeren. Welke controle het meest passend is wordt hier sterk door beïnvloed. De volgende redenen om monitoring tools te implementeren worden onderscheden.

1. Het versimpelen van het autorisatie concept en deze controles (gedeeltelijk) vervangen door monitoring.

Dit is vooral relevant voor organisaties die merken veel middelen kwijt te zijn aan het onderhouden van het autorisatie concept, en dit op een andere manier willen gaan aanpakken. Door voor een simpeler autorisatie concept te kiezen, kunnen kosten worden bespaard. De inperking van de controle in autorisaties wordt vervolgens gecompenseerd door het inrichten van monitoring controles.

Hierbij moet worden opgemerkt dat veel organisaties al een autorisatie concept hebben en dat het omschakelen van het huidige autorisatie concept naar een eenvoudiger autorisatie concept met monitoring controles een complex project kan zijn dat ook veel middelen kost. Er moet een kosten- baten analyse worden uitgevoerd om te bepalen of dit rendabel is.

Er moet worden opgemerkt dat je autorisaties altijd nodig zal blijven hebben om vast te leggen wie er mag deblokkeren (Voort, 2021). Ook moet worden opgemerkt dat er een zekere verschuiving in mentaliteit nodig is om interne controle op deze wijze aan te pakken, zowel voor de organisatie zelf als de auditor (Hallemeesch, Ashruf, & Spruit, 2021).

2. Het inrichten van data gebonden autorisaties.

Dit is relevant voor organisaties die medewerkers de mogelijkheid willen geven om conflicterende taken uit te voeren in verschillende transacties. Er kunnen twee conflicterende rechten aan één medewerker toe worden gekend, en vervolgens kan middels monitoring worden gevalideerd dat deze beide rechten niet voor dezelfde transactie zijn gebruikt (Voort, 2021). Dit kan bijvoorbeeld relevant zijn in kleinere bedrijven die niet genoeg medewerkers in dienst hebben om voldoende

functiescheiding in te richten, maar ook in grotere organisaties kan dit zijn toepassing vinden.

3. Extra controle toevoegen op het bestaande autorisatie concept en het verkrijgen van inzicht.

Dit is vooral relevant voor bedrijven die hun autorisatie concept willen behouden, maar onvoldoende zekerheid hebben dat het autorisatie concept voldoende uitzonderingen voorkomt. Om dit probleem op te lossen kunnen ze meer controle implementeren in de vorm van monitoring. Hierbij moet worden opgemerkt dat een autorisatie concept dat alle uitzonderingen voorkomt vaak een illusie is. In het algemeen is het altijd aan te raden om monitoring in te richten in aanvulling op autorisaties. Hiermee kan meer inzicht worden verkregen in uitzonderingen die zich voordoen. (Dommerholt, 2021).

In geval 1 en 2 wijkt het gebruikte autorisatie concept af van het standaard concept. De organisatie kiest er expliciet voor om gebruik te maken van een concept dat mogelijk niet waterdicht is. Om hiervoor te

compenseren zullen er meer en/of zwaardere monitoring controles moeten worden ingericht.

In geval 3 gebruikt de organisatie een traditioneel autorisatie concept. Zij hebben echter onvoldoende vertrouwen in het altijd correct functioneren van dit concept en willen daarom aanvullende controles implementeren. In dit geval zullen deze controles voornamelijk worden genomen in de gebieden waar a.

twijfels zijn over de werking van het autorisatie concept of b. meer risico wordt gelopen en daarom meer controle nodig is. Hoe groter het risico, hoe zwaarder de controle die moet worden genomen.

(28)

Wanneer de organisatie een echt goed werkend autorisatie concept heeft ingericht, is het niet nodig om zware monitoring controles te implementeren. Periodieke rapportages kunnen in dit geval al voldoende zijn. Indien er uit deze rapportages toch veel uitzonderingen komen, moet worden overwogen om toch gebruik te gaan maken van zwaardere monitoring maatregelen (Dommerholt, 2021).

Beslisboom

Bij het implementeren van interne controle zal een organisatie eerst een risk assessment uitvoeren. Hierbij worden de doelstellingen van de organisatie bepaald, risico’s gedefinieerd, de impact van de risico’s bepaald en de maatregelen (controles) om deze risico’s te beperken vastgelegd (Hallemeesch, Ashruf, & Spruit, 2021), (Dommerholt, 2021). Per risico moet worden bepaald of er in de bijhorende controle gebruik zal worden gemaakt van monitoring controles. In context van dit onderzoek zijn de relevante risico’s de risico’s die traditioneel zouden worden afgedicht door autorisaties in te richten. Indien ervoor wordt gekozen om de traditionele autorisaties niet (volledig) in te richten, moet dit worden gecompenseerd door aanvullende monitoring controles te implementeren. Merk hierbij op dat, indien er gebruik wordt gemaakt van monitoring controles, rekening moet worden gehouden met de risico’s die zijn beschreven in hoofdstuk 4.1.

Om te bepalen welke monitoring controle het best gebruikt kan worden, kan gebruik worden gemaakt van de beslisboom in Figuur 1. In deze boom worden drie keuzes gegeven. Hieronder is per keuze beschreven hoe deze het best genomen kan worden.

Periodiek of real time monitoren?

Blokkeren of niet?

Blokkeren voordat er op

verzenden is geklikt?

Niet blokkeren

Wel blokkeren

Controle 1

Periodieke rapportages

Controle 2

Real time meldingen

Controle 3

Real time meldingen, blokkeren en een workflow

Periodiek Real time Nee Ja

Figuur 1 Beslisboom

Controle 4

Melding en blokkeren nog voor

er op verzenden is geklikt en een

workflow