Smart contracts
De ‘slimme kant’ van blockchain onder controle
M.H.J. Schreurs MA, MSc Amsterdam, 2 mei 2018 Universiteit van Amsterdam Amsterdam Business School Amsterdam IT Audit Programme Begeleider: Hans MoonenTwijfel is het begin van wijsheid René Descartes – filosoof en wiskundige (1596 – 1650)
Voorwoord
Wijze mensen zeggen wel eens: “Al het goede komt in drieën”. Die wijsheid volg ik graag, want voor u ligt het resultaat van mijn derde afstudeeronderzoek. Het was wederom een mooie zoektocht. Iedereen die mij goed kent, weet dat ik niet graag opties uitsluit. Dat was ook in dit afstudeeronderzoek weer een persoonlijke uitdaging. “Zal ik dit ook in scope nemen?”, “Maar dit is ook interessant!” en “Hier wil ik nog meer van weten.”. Die nieuwsgierigheid hoort gewoon bij mij, maar gaat ook wel eens gepaard met twijfel. Gelukkig heb ik van René Descartes geleerd dat twijfel het begin is van wijsheid… Ik hoop dat dit afstudeeronderzoek mooie deuren opent. Zowel voor mezelf als voor de mensen die zo ontzettend geïnspireerd werken aan deze nieuwe technologie en de denkwijze erachter. Graag wil ik mijn begeleider Hans Moonen bedanken voor zijn rust en tijd om mijn scriptie te lezen en mij op het juiste pad te houden met zijn wijze woorden en opbouwende kritiek. Dank! Ook een dankwoord aan mijn familie en vrienden. Dank voor jullie bemoedigende woorden en nu maak ik ook weer tijd voor jullie. Last, but not least: dank aan mijn lieve man Ed die me heeft gesteund en me voor gek heeft verklaard. Maar die ook dubbele ‘kids-diensten’ heeft gedraaid om mij de rust te geven die ik nodig had om dit tot een goed einde te brengen. En natuurlijk dank aan mijn lieve kindjes die zo trots zijn op hun mama. Ik ben ook heel trots op jullie!Inhoudsopgave
Voorwoord ... 5 Inhoudsopgave ... 7 Samenvatting ... 11 1 Inleiding ... 13 1.1 Aanleiding ... 13 1.1.1 Distributed Ledger Technology en smart contracts ... 13 1.1.2 IT-audit en beoordelingscriteria ... 15 1.2 Probleemstelling en onderzoeksvragen ... 17 1.3 Werkwijze en onderzoeksmethode ... 18 1.3.1 Onderzoeksmethode en gegevensverzameling ... 19 1.3.2 Afbakening onderzoek ... 20 1.4 Opbouw scriptie ... 21 2 DLT en Smart contracts ... 22 2.1 Inleiding ... 22 2.2 Blockchain 1.0 en DLT ... 22 2.2.1 Blockchain 1.0 ontrafeld ... 24 2.2.1.1 DLT-stack ... 25 2.2.2 Andere verschijningsvormen ... 26 2.2.2.1 Public permissioned ledgers ... 27 2.2.2.2 Private permissioned DLT ... 27 2.2.2.3 ‘Old school’ ... 28 2.2.2.4 Kanttekeningen ... 28 2.3 Blockchain 2.0: smart contracts ... 29 2.3.1 Smart contracts ... 29 2.3.2 Kenmerken smart contracts ... 30 2.3.2.1 Oracles ... 31 2.3.3 Voordelen en nadelen van het gebruik van smart contracts ... 32 2.4 Een vergelijk met traditionele transactie verwerkende informatiesystemen ... 34 2.5 Samenvatting en conclusie ... 36 3 Beoordeling ... 38 3.1 Inleiding ... 38 3.2 Kwaliteitsaspecten volgens NOREA ... 39 3.2.1 Effectiviteit ... 40 3.2.2 Efficiëntie ... 40 3.2.3 Exclusiviteit ... 40 3.2.4 Integriteit ... 403.2.5 Controleerbaarheid ... 41 3.2.6 Continuïteit ... 41 3.2.7 Beheersbaarheid ... 41 3.2.8 Beschouwing NOREA-aspecten in het licht van smart contracts ... 42 3.3 Karakteristieken van softwarekwaliteit volgens ISO/IEC ... 42 3.4 Mapping NOREA op ISO/IEC met betrekking tot integriteit ... 47 3.5 Samenvatting en conclusie ... 49 4 Kwaliteitseisen aan smart contracts en onderliggende DLT ... 51 4.1 Inleiding ... 51 4.2 Relevantie ISO/IEC 25010 sub-karakteristieken ... 51 4.2.1 Functionele juistheid en functionele volledigheid ... 52 4.2.2 Interoperabiliteit ... 53 4.2.3 Foutbestendigheid ... 54 4.2.4 Volwassenheid ... 54 4.2.5 Respons- en verwerkingstijd ... 55 4.2.6 Middelenbeslag ... 55 4.2.7 Vertrouwelijkheid ... 55 4.2.8 Integriteit ... 56 4.3 Samenvatting en conclusie ... 57 5 De praktijkbevindingen ... 59 5.1 Inleiding ... 59 5.2 Visie respondenten op de sub-karakteristieken ... 59 5.2.1 Functionele juistheid ... 60 5.2.2 Functionele volledigheid ... 62 5.2.3 Interoperabiliteit ... 64 5.2.4 Foutbestendigheid ... 66 5.2.5 Volwassenheid ... 67 5.2.6 Respons- en verwerkingstijd ... 69 5.2.7 Middelenbeslag ... 72 5.2.8 Vertrouwelijkheid ... 73 5.2.9 Integriteit ... 75 5.3 Samenvatting en conclusie ... 77 6 Conclusie ... 79 6.1 Inleiding ... 79 6.2 Normenkader voor toets integriteit in smart contracts ... 79 6.3 Beoordeling smart contracts ... 81 6.3.1 De lagen ... 81 6.3.2 De verschijningsvormen ... 82 6.3.3 Kenmerken smart contracts ... 83 6.3.4 De koppelvlakken ... 84
6.4 Conclusie ... 84 7 Reflectie en aanbevelingen ... 85 7.1 Reflectie ... 85 7.2 Snelle ontwikkelingen ... 85 7.3 Aanbevelingen ... 86 Literatuurlijst ... 88 Bijlage 1 Interview guideline ... 91 Bijlage 2 Overzicht respondenten ... 92
Samenvatting
De ontwikkelingen in blockchain-, distributed ledger technology (DLT) en smart contracts nemen in rap tempo toe. Er wordt volop geëxperimenteerd met de mogelijkheden van deze nieuwe technologie in allerlei bedrijfstakken. Bitcoin heeft inmiddels een breder publiek bereikt en er worden stappen gemaakt met het in productie nemen van DLT-toepassingen. Als gevolg hiervan ontstaan vraagstukken met betrekking tot het aanpassen of vernieuwen van wet- en regelgeving en het houden van toezicht op deze nieuwe wereld. Ook in het vakgebied van auditing wordt de vraag gesteld welke rol een IT-auditor kan spelen bij de beoordeling of advisering over deze nieuwe technologie. Hoe gaat dit vakgebied om met het beoordelen van de kwaliteit van de gegevensverwerking voor het maatschappelijk verkeer wanneer hiervoor blockchain- of distributed ledger technology en smart contracts worden ingezet? Er zijn zeer uiteenlopende publicaties over blockchain, distributed ledger technology, smart contracts en alles wat daaraan gelieerd is. Partijen proberen als eerste het ‘gat in de markt’ te vinden en elkaar te overtroeven met standpunten en proposities. Deels hoort dat bij het ontginnen van woeste grond, maar het geeft tegelijkertijd veel ruis. Dit onderzoek is daarom afgebakend. Er is gekeken naar de kwaliteitseisen die gesteld worden aan het borgen van de integriteit van smart contracts, maar ook naar de interactie met technologieën die zich op de grens met de smart contracts bevinden. In dit afstudeeronderzoek wordt antwoord gegeven op de volgende centrale vraag: Hoe kan een IT-auditor oordelen of adviseren over de mate waarin smart contracts – die gebruik maken van verschillende verschijningsvormen van blockchain of distributed ledger technology – voldoen aan de kwaliteitseisen die de integriteit van deze smart contracts moeten borgen? Voor de beantwoording van deze vraag heeft onderzoeker een voorstel gedaan voor een normenkader wat een IT-auditor kan gebruiken bij het oordelen of adviseren over de borging van de integriteit in smart contracts. Ook zijn de kenmerken van smart contracts en de onderliggende en aanpalende technologie beschreven. De IT-auditor moet begrip hebben van deze kenmerken bij het toepassen van dit normenkader om ook in de toekomst van toegevoegde waarde te kunnen zijn.1 Inleiding
1.1 Aanleiding De ontwikkelingen in de informatietechnologie (IT) volgen elkaar steeds sneller op. Futurist Kurzweil (2001, 1e alinea) beschrijft dit als volgt: An analysis of the history of technology shows that technological change is exponential, contrary to the common-sense “intuitive linear” view. So we won’t experience 100 years of progress in the 21st century — it will be more like 20,000 years of progress (at today’s rate). Als gevolg hiervan ontstaan er vragen rondom de toepasbaarheid, besturing en beoordeling van deze nieuwe ontwikkelingen en de effecten die deze innovaties hebben op de maatschappij. Dat vergt van de betrokken partijen dat zij zich aanpassen aan deze innovaties door ze sneller toe te passen. Het vergt ook snellere aanpassingen in wet- en regelgeving of het aanpassen van de beoordeling van deze innovatieve technologieën. Eén van de innovatieve technologieën de hiermee worstelt, is de blockchain technology. 1.1.1 Distributed Ledger Technology en smart contracts Anno 2018 is het gebruik van innovaties zoals Artificial Intelligence (AI), Internet of Things (IoT) en blockchain technology helemaal ‘hot’. Organisaties stellen veel resources beschikbaar om ervaringen op te doen met deze nieuwe technologieën. Voor blockchain technology gebeurt dit veelal door het uitvoeren van een Proof of Concept (PoC). Volgens “Wat betekent POC” (2012) wordt in een PoC een idee, concept of product uitgewerkt als demonstratie. Hiermee worden de haalbaarheid en mogelijkheden van het concept aangetoond. Het concept wordt dus niet volledig uitgewerkt. Ook wordt er in deze fase nog niet zo zeer nagedacht over beperkingen en details. Het voordeel van dergelijke aanpak is dat een organisatie zich kan richten op de kansen en mogelijkheden van de nieuwe technologie. In de wereld van de blockchain technology beginnen nu – nadat de eerste twee fasen van de hype cycle (Van den Berg & Pietersen, 2015, p. 216) zijn doorlopen – wat kritische geluiden te klinken over de toepasbaarheid van deze technologie. Volgens Gartner (Panetta, 2017) is de blockchain technology inmiddels over de ‘Peak of Inflated Expectations’ heen en begeeft het zich in de richting van de ‘Trough of Disillusionment’. Nu er door de PoC’s meer zicht komt op de toepasbaarheid, komt er langzaam maar zeker ook zicht op de mogelijke beperkingen en bedreigingen. De eerste implementatie van blockchain, de technologie via welke de transacties van Bitcoin wordt gerealiseerd en vastgelegd, deed veel stof opwaaien. De oprichtingspaper - het zogenaamde ‘Manifesto’ van Satoshi Nakamoto (2008) – beschrijft het principe vaneen Peer-to-Peer Electronic Cash System. In dit document wordt uitleg gegeven over de technologie die ten grondslag ligt aan het doen van electronische transacties. Het bijzondere aan deze technologie is dat transacties rechtstreeks tussen de ene en de andere partij plaatsvinden, zonder gebruik te maken van een (vertrouwde) derde partij die de transacties of de brongegevens valideert. Er wordt gebruik gemaakt van complexe geautomatiseerde berekeningen voor het valideren van de transacties. Daarnaast wordt er een combinatie van public en private keys gebruikt voor het encrypteren en authenticeren van degenen tussen wie de transactie plaatsvindt en kan iedereen aan deze blockchain meedoen en alle transacties zien. Eén van de basisprincipes van blockchain technology is dat er sprake is van een ‘distributed ledger’ (gedistribueerd grootboek), waarvan iedere ‘node’ (knooppunt) een kopie heeft. De naam Distributed Ledger Technology (DLT) dekt dan ook volgens menigeen veel beter de lading (Pels Rijcken innovatieteam, 2017, p. 2). Alle gevalideerde transacties en brongegevens zijn gedistribueerd en daarmee decentraal inzichtelijk en kunnen niet zonder meer eenzijdig gewijzigd worden. In dit concept hebben alle partijen een gelijkwaardige rol. Door de opzet van blockchain hebben alle aangesloten partijen inzicht in dezelfde waarheid. In hoofdstuk 2 wordt verder ingegaan op deze technologie. Hoewel de uitgangspunten van gelijkwaardigheid en decentralisatie de drijvende kracht zijn achter de blockchain, zijn deze tegelijkertijd ook een bedreiging voor de toepassing van de technologie in meer traditionele organisaties. Historisch gezien is gebleken dat de mensheid gekenmerkt wordt door een – meestal niet gelijke – verdeling van macht. Dit oerprincipe heeft er ook in de blockchain-wereld toe geleid dat is gekeken naar het ongelijk(er) toekennen van rechten. Als gevolg hiervan zijn er varianten op de eerste blockchain ontwikkeld en is er nu een onderscheid tussen ‘permissioned’ en ‘non-permissioned’ of ‘permissionless’ blockchain technology (Smart Contract Werkgroep – Dutch Blockchain Coalition, 2017). Met de introductie van permissioning gaat de technologie in de richting van een meer ‘traditionele’ governance. In dit geval krijgt niet zomaar iedereen toegang tot de omgeving en schrijfrechten worden gedifferentieerd toegekend aan gebruikers. Naast de introductie van (toegangs-)rechten, is er 2015 nog een ander fenomeen geïntroduceerd: de zogenaamde ‘smart contracts’. Bijzonder hieraan is dat smart contracts al in 1994 voor het eerst genoemd werden door Nick Szabo, al lang voor de introductie van de blockchain. In een publicatie van zijn gedachtegoed (Szabo, 1997) omschrijft hij smart contracts als volgt: The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can
be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher. Hoewel smart contracts doen vermoeden dat er sprake is van slimme (juridische) contracten, is een smart contract eigenlijk een stuk software dat vaststelt of er aan de vooraf gedefinieerde en geprogrammeerde voorwaarden wordt voldaan. Op basis hiervan kan er al dan niet een transactie of verwerking plaatsvinden en aan de blockchain worden toegevoegd (Mougayar, 2016). Doordat zowel deze software als de verwerkte transactie in de blockchain worden opgeslagen, is ook deze logica-laag niet zonder meer eenzijdig aan te passen. Daarmee worden de transacties, die met behulp van deze logica worden verwerkt, als te vertrouwen beschouwd (Everts, 2017). De laatste jaren wordt er gekeken naar bredere toepassing van de blockchain technology. Er worden PoC’s uitgevoerd bij de overheid, in de financiële wereld (commerciële banken, verzekeraars en pensioenfondsen), maar ook in logistieke organisaties en in handelsorganisaties (fair trade organisaties of scheepvaart). De ontwikkelingen rollen over elkaar heen, maar het aanpassen of vernieuwen van wet- en regelgeving en het houden van toezicht op deze nieuwe wereld blijft achter. En wat te denken van het werkveld van de IT-auditor? Hoe gaat dit vakgebied om met het beoordelen van de kwaliteit van de gegevensverwerking voor het maatschappelijk verkeer wanneer hiervoor blockchain technology en smart contracts worden ingezet? Kortom: hoe zit het eigenlijk met de beoordeling van de integriteit door de IT-auditor in deze innovatieve technologieën? 1.1.2 IT-audit en beoordelingscriteria Het werkveld van de IT-auditor bestaat uit een drietal opdrachtvormen, te weten: 1. ‘De functie of het proces om een bepaald object van onderzoek (subject matter) te onderzoeken, met als doel een conclusie te vormen over één of meer eigenschappen ervan’ (Fijneman, Lindgreen, Veltman en Hang Ho, 2011). In dit geval is er sprake van het geven van ‘assurance’, waaraan strikte vak-voorschriften zijn verbonden. 2. Voor het aspect ‘advisering’ zijn er maar weinig voorschriften. In dit werkveld neemt de IT-auditor een object van onderzoek onder de loep, doet bevindingen, voert analyses uit, brengt aanbevelingen uit of ondersteunt een opdrachtgever om hem ergens mee te helpen. De opdrachtgever wil vooral geholpen worden om het object te laten voldoen aan de gestelde criteria in plaats van daarop beoordeeld te worden.
3. Een derde vorm van opdrachten betreft de overeengekomen specifieke werkzaamheden. In deze opdrachten wordt wel op zoek gegaan naar feitelijke bevindingen, maar worden er geen conclusies aan verbonden. Daarnaast wordt een rapport van dergelijke opdrachten niet wijdverspreid (zoals bij een adviesrapport of een assurance rapport wel het geval kan zijn). In al deze opdrachtvormen is er sprake van een object van onderzoek. In een IT-audit wordt de kwaliteit van dit object beoordeeld ten aanzien van één of meerdere aspecten die van belang kunnen zijn voor de oordeelsvorming. Deze zogenaamde ‘kwaliteitsaspecten’ worden door NOREA – de beroepsorganisatie van IT-auditors – omschreven als ‘de eigenschappen waarover met betrekking tot een object een oordeel wordt uitgesproken’ (Van Biene-Hershey, 1998, p. 47). De zeven kwaliteitsaspecten die NOREA noemt voor het beoordelen van de kwaliteit van een onderzoeksobject zijn: 1. effectiviteit 2. efficiëntie 3. exclusiviteit 4. integriteit 5. controleerbaarheid 6. continuïteit 7. beheersbaarheid NOREA geeft in haar boek ‘IT-auditing aangeduid’ (Van Biene-Hershey, 1998) aan dat deze kwaliteitsaspecten in de praktijk vaak worden gedetailleerd en zodoende meer betekenis krijgen voor een te beoordelen object. Onderzoeker is van mening is dat die detaillering ook in voorliggend onderzoek noodzakelijk is. Om te kunnen oordelen of adviseren over de kwaliteit van informatiesystemen of software producten, biedt het normenkader van ISO/IEC concretere handvatten. In hoofdstuk 3 wordt dieper ingegaan op het werkveld van de IT-auditor. Ook wordt daar ingezoomd op de detaillering van de kwaliteitsaspecten die onderzocht moeten worden voor het beoordelen van en adviseren over geautomatiseerde transactie verwerkende informatiesystemen. Smart contracts zijn in de basis vergelijkbaar met traditionele software en kunnen daarom wellicht worden getoetst tegen normen die gelden voor traditionele software. Daarnaast is er nog geen normenkader ontwikkeld wat specifiek voor de beoordeling van deze nieuwe vorm van software producten gebruikt kan worden. Daarom is onderzoeker van mening dat het gerechtvaardigd is om het ISO/IEC 25010 normenkader te gebruiken voor de beoordeling van de integriteit van smart contracts.
1.2 Probleemstelling en onderzoeksvragen Zoals aangegeven is de wereld van blockchain technology en smart contracts volop in beweging. Onder onze ogen schieten nieuwe varianten op de eerste blockchain technology als paddenstoelen uit de grond. Om te kunnen blijven vertrouwen op deze technologie, is het belangrijk om oog te hebben voor het borgen van de integriteit van de gegevensverwerking. Wanneer hier niet genoeg aandacht aan wordt gegeven, neemt het risico op fouten bij het gebruik van blockchain en smart contracts toe. Dit kan leiden tot niet integere gegevensverwerking, waardoor het vertrouwen in de technologie wellicht onomkeerbaar geschaad wordt. Onderzoeker is van mening dat het borgen van de integriteit van smart contracts daarom de aandacht verdient boven het borgen van de andere NOREA-kwaliteitsaspecten. Wanneer de integriteit namelijk niet gegarandeerd kan worden, heeft een gebruiker of de maatschappij niet zo veel een efficiënt of continu beschikbaar informatiesysteem. De andere zes kwaliteitsaspecten zijn daarmee in de ogen van onderzoeker van secundair belang. Om deze reden richt dit onderzoek zich op het kunnen borgen van NOREA’s deelaspect ‘integriteit’ in smart contracts, waarbij de koppelvlakken met de aanpalende of onderliggende technologie ook in ogenschouw worden genomen. Het doel van dit onderzoek is om vast te stellen hoe een IT-auditor kan oordelen of adviseren over de mate waarin smart contracts voldoen aan de eisen die hieraan vanuit audit-perspectief worden gesteld. De centrale vraag die beantwoord moet worden om bovenstaand doel te kunnen bereiken, is de volgende: Hoe kan een IT-auditor oordelen of adviseren over de mate waarin smart contracts – die gebruik maken van verschillende verschijningsvormen van blockchain of distributed ledger technology – voldoen aan de kwaliteitseisen die de integriteit van deze smart contracts moeten borgen? Voor de beantwoording van deze vraag, moet eerst inzicht worden verkregen in een aantal begrippen, inzichten en problemen die in dit kader van belang zijn. Deze zijn: 1. Wat is blockchain of distributed ledger technology en wat is een smart contract? 2. Wat zijn hun kenmerken en hoe verschillen ze ten opzichte van traditionele transactie verwerkende informatiesystemen? 3. Welke invulling van de kwaliteitseisen volgens ISO/IEC25010 borgen het door NOREA gedefinieerde kwaliteitsaspect ‘integriteit’ in het geval van smart contracts? 4. Hoe beoordeelt een IT-auditor deze eisen in het geval van smart contracts en bijbehorende koppelvlakken?
Door antwoord te krijgen op deze deelvragen, ontstaat er inzicht in de aspecten die ten grondslag liggen aan de centrale vraag. Het ‘hoe’ in de centrale vraag spitst zich toe op: • Op basis van welk normenkader kan een IT-auditor oordelen of adviseren over de integriteit van smart contracts? • Welk onderscheid kan een IT-auditor maken ten aanzien van smart contracts als onderzoeksobject door rekening te houden met: o De diverse ‘lagen’ waaruit de blockchain- of distributed ledger technology bestaat. o De diverse vormen waarin de blockchain- of distributed ledger technology kan verschijnen. o De kenmerken van smart contracts. o De koppelvlakken die een smart contract kan hebben met andere systemen of onderdelen van de distributed ledger technology voor het kunnen uitvoeren van een transactie. De beantwoording van de centrale vraag geeft expliciet geen antwoord op de vraag welke stappen een IT-auditor moet doorlopen of welke onderzoeksmethodiek een IT-auditor moet hanteren om de integriteit van smart contracts te beoordelen. 1.3 Werkwijze en onderzoeksmethode Nederland is één van de landen waarin de overheid en daaraan gelieerde instanties actief onderzoek doen naar de impact van blockchain en distributed ledger technology en smart contracts op bestaande organisaties, de rol van de overheid en toezichthouders. Er is echter nog geen uitgekristalliseerd beeld van al deze ontwikkelingen en de gevolgen die zij hebben op onze economie en samenleving omdat de meeste initiatieven nog in de onderzoeksfase zitten. Er wordt veel geschreven over Bitcoin, blockchain, distributed ledger technology en smart contracts, maar niet alle documenten hebben dezelfde kwaliteit en geven niet in alle gevallen een getrouw beeld van de werkelijkheid. Om deze reden zal – voor de beantwoording van de (deel-)vragen – gebruik gemaakt worden van diverse literatuurbronnen. Geput wordt uit publicaties uit het onderwijs en onderwijs gelieerde instellingen zoals TNO, de Dutch Digital Delta en de Dutch Blockchain Coalition. Ook wordt gekeken naar publicaties van individuele grondleggers van smart contracts, de blockchain- en distributed ledger technology. Daarnaast wordt geput uit de meer ‘gevestigde’ vakliteratuur komend van NOREA, publicaties van advies- en accountantskantoren en algemene literatuur over Governance, Risk Management en Compliancy (GRC). Voor de onderzoeksmethodologie wordt gebruik gemaakt van de literatuur over ‘Het ontwerpen van een onderzoek’ (Verschuren en Doorewaard, 2000).
1.3.1 Onderzoeksmethode en gegevensverzameling Het bestuderen van deze verschillende bronnen leidt tot het theoretisch kader waarop het praktijkonderzoek rust. Volgens Verschuren en Doorewaard (2000, p. 147-191) zijn er verschillende onderzoeksstrategieën die binnen het praktijkonderzoek uitgevoerd kunnen worden, te weten: • Het survey-onderzoek • Het experiment • De casestudy • De gefundeerde theoriebenadering • Het bureauonderzoek In voorliggend onderzoek wordt gebruik gemaakt van de casestudy. Deze onderzoeksvorm kenmerkt zich volgens Verschuren en Doorewaard door een arbeidsintensieve aanpak, waarbij van een klein aantal geselecteerde onderzoekseenheden kwalitatieve gegevens wordt verzameld op basis van een open waarneming. Onderzoeker wil vanuit verschillende perspectieven een algemeen kwalitatief beeld schetsen van hoe IT-auditors zich een oordeel kunnen vormen of adviseren over de mate waarin de integriteit van smart contracts is geborgd. De verschillende perspectieven van waaruit gekeken wordt, zijn: • advies- en/of auditorganisaties • gebruikersorganisaties • programmeurs • de wetenschap In dit onderzoek is een klein aantal onderzoekseenheden (de ‘cases’) kwalitatief onderzocht. Zo is gepoogd de benodigde diepgang – behorend bij een casestudy – te bereiken. Concreet betekent dit dat de eerste twee deelvragen voornamelijk op basis van literatuur over blockchain, distributed ledger technologie en smart contracts zijn beantwoord. Hiervoor zijn (semi-) wetenschappelijke publicaties van universiteiten en overheid gelieerde instanties zoals TNO en de Dutch Blockchain Coalition gebruikt. Ook zijn publicaties van adviesorganisaties en grondleggers van deze technologie ter hand genomen. De basis voor de beantwoording van de derde deelvraag wordt gevormd door vakliteratuur van NOREA en de International Organization for Standardization (ISO) en de International Electrotechnical Commission (IEC). Onderzoeker heeft deze twee bronnen gecombineerd tot een – voor dit onderzoek relevant – normenkader. De validiteit en toepasbaarheid van dit normenkader is getoetst in het praktijkonderdeel van dit onderzoek.
De vierde deelvraag wordt in dit onderzoek beantwoord op basis van het voorgestelde normenkader. In de interviews is de toepasbaarheid van dit normenkader getoetst. Daarnaast is ingegaan op de risico’s en maatregelen die de respondenten in de praktijk signaleren ten aanzien van de karakteristieken in dit normenkader. In dit onderzoek is op deze manier gepoogd om de centrale vraag zo holistisch mogelijk te beantwoorden en tot algemeen geldende uitspraken te komen die vanuit al deze perspectieven ondersteund worden. In dit onderzoek is ook brontriangulatie toegepast. Naast de documentatiestudie zijn semigestructureerde interviews op basis van open vragen uitgevoerd. Ook het bekijken van de code van smart contracts zelf en toelichting daarop door een programmeur, heeft bijgedragen aan zowel de methodetriangulatie als aan brontriangulatie. Door deze manier van dataverzameling, het gebruik van verschillende perspectieven en de uitkomsten hiervan te vergelijken met elkaar, is een integraal beeld verkregen. 1.3.2 Afbakening onderzoek Er zijn uiteenlopende publicaties over blockchain, distributed ledger technology, smart contracts en alles wat daaraan gelieerd is. Partijen proberen als eerste het ‘gat in de markt’ te vinden en elkaar te overtroeven met standpunten en proposities. Deels hoort dat bij het ontginnen van woeste grond, maar het geeft tegelijkertijd veel ruis. In een wereld die zo nieuw en in beweging is, is het verstandig om koers te bepalen en koers te houden. Dit onderzoek is daarom zodanig afgebakend dat er in beginsel alleen gekeken is naar de kwaliteitseisen die gesteld worden aan het borgen van de integriteit van smart contracts. Tegelijkertijd heeft onderzoeker de ogen niet gesloten voor de interactie met technologieën die zich op de grens met de smart contracts bevinden. Zoals beschreven in dit hoofdstuk zijn er verschillende kwaliteitsaspecten te onderkennen, die ook nog eens op verschillende manieren uitgelegd en/of vertaald worden. In deze fase van volwassenheid van de techniek bepaalt het borgen van de integriteit grotendeels hoe succesvol het concept van DLT en smart contracts zal worden in de toekomst. De overige kwaliteitsaspecten zijn ook belangrijk, maar in deze fase van secundair belang. Alleen wanneer onderwerpen randvoorwaardelijk zijn voor het borgen van de integriteit, zijn ze meegenomen in dit onderzoek. De overweging die de onderzoeker hierbij gemaakt heeft, is om na te gaan welk aspect uiteindelijk het meest relevant is om de integriteit van de smart contracts te borgen. Dat vergt een continue afweging van de relevantie van informatie voor het beantwoorden van de centrale vraag.
Ook is er kort ingegaan op blockchain-, distributed ledger technology en smart contracts. Onderzoeker is van mening dat het grootste deel van de te beoordelen logica in smart contracts zit. Hierop in hoofdstuk 2 dieper ingegaan. Voor de afbakening van dit afstudeeronderzoek betekent dit dat er hoofdzakelijk gekeken is naar de beoordeling van smart contracts. De distributed ledger technology waarop zo’n smart contract draait, is in mindere mate van belang. Echter, daar waar er specifieke kenmerken van deze technologie zijn, die van belang zijn voor het beantwoorden van de centrale vraag of deelvragen, zijn ook deze in ogenschouw genomen. 1.4 Opbouw scriptie In voorliggende scriptie is gepoogd de lezer een gestructureerd overzicht te geven van de onderzoeksdoelstelling en de beantwoording van de centrale vraag en deelvragen. Volgend op dit eerste hoofdstuk, waarin de doelstelling en afbakening van het onderzoek zijn verwoord, wordt in hoofdstuk 2 een beschrijving gegeven van wat blockchain-, distributed ledger technology en smart contracts zijn en welke kenmerken zij hebben. Ook wordt in hoofdstuk 2 aangegeven welke verschillen en overeenkomsten smart contracts vertonen met traditionele transactie verwerkende informatiesystemen. In hoofdstuk 3 treft de lezer een beschrijving en mapping van de kwaliteitsaspecten van NOREA op de eisen volgens ISO/IEC 25010. Gezien de afbakening van dit onderzoek, ligt hierin de focus op het aspect integriteit, zoals dat door NOREA is beschreven. In hoofdstuk 4 wordt een verbinding gemaakt tussen de geselecteerde karakteristieken ten aanzien van integriteit en de nieuwe wereld van distributed ledger technology en smart contracts. Deze verbinding vormt de basis voor de guidelines voor de interviews waarmee het empirisch materiaal verzameld is. Daaropvolgend geeft hoofdstuk 5 een beschrijving van de bevindingen in deze interviews. In de laatste hoofdstukken beschrijft onderzoeker de conclusies van het onderzoek en worden aanbevelingen gedaan. Er wordt expliciet stilgestaan bij de beantwoording van centrale vraag en doelstelling van dit onderzoek.
2 DLT en Smart contracts
2.1 Inleiding In het eerste hoofdstuk is een algemene introductie gegeven in de wereld van blockchain, distributed ledger technology en smart contracts. Hoewel de scope van dit afstudeeronderzoek zich in principe beperkt tot smart contracts, kan dit niet los worden gezien van de daarmee samenhangende technologie. Een smart contract zonder de infrastructuur – via welke het smart contract wordt ontsloten – levert namelijk eigenlijk geen operationeel geheel op. Daarom wordt er in deze scriptie óók ingegaan op de verschillende vormen van blockchain- en distributed ledger technology. Zo wordt duidelijk welke verschijningsvormen er zijn en op welke wijze deze mogelijkerwijs impact hebben op de integriteit van smart contracts. Dit zijn de basisinzichten die voor een IT-auditor van belang zijn om over deze technologie te kunnen oordelen of adviseren. In dit hoofdstuk wordt achtereenvolgens aandacht besteed aan de ontwikkeling die de blockchain technology doormaakt, welke verschijningsvormen er te onderscheiden zijn en wat er zo bijzonder is aan smart contracts. Het hoofdstuk wordt afgesloten met een samenvatting en conclusie. 2.2 Blockchain 1.0 en DLT De implementatie van het peer-to-peer electronic cash system, zoals Satoshi Nakamoto (2008) beschreef, wordt gezien als de allereerste implementatie van de zogenaamde blockchain technology. Hoewel Nakamoto de term ‘blockchain’ niet als zodanig noemt in zijn document, omschrijft hij de technologie wel als een opeenvolging van blokken (blocks) die op chronologische wijze in een keten (chain) met elkaar verbonden zijn. Deze technologie wordt gebruikt voor het doen en bijhouden van transacties met de cryptocurrency genaamd Bitcoin. Omdat dit de allereerste toepassing van blockchain technology is, wordt dit wel gezien als blockchain 1.0 (Swan, 2015, p.1). In het eerste decennium van het bestaan van de blockchain technology zijn er verschillende ontwikkelingen geweest in de technologie zelf, maar ook op het gebied van toepassing van de technologie. Maar wat is blockchain of blockchain technology nu eigenlijk? De Smart Contract Werkgroep van de Dutch Blockchain Coalition (2017, p. 12) ziet blockchain als: …een verzamelnaam van technologieën die tot doel hebben om verspreid (op verschillende computers of servers) opgeslagen gegevens via een netwerk te synchroniseren, zodat deze gelijk blijven. Hierbij wordt gebruik gemaaktvan een consensus protocol om de integriteit van de inhoud van de gegevens te garanderen, cryptografie speelt daarbij een grote rol. De crux van blockchain is dat synchronisatie peer-to-peer plaatsvindt, hetgeen inhoudt dat geen van de computers het voor het zeggen heeft in het netwerk. Het innovatieteam van Pels Rijcken geeft aan dat blockchain slechts een voorbeeld is van een DLT (2017, p. 3). Zij verwoorden dit als volgt: Wat de blockchaintechniek wel uniek maakt, is dat steeds een set van transacties wordt samengevoegd in een block. Ieder block wordt voorzien van een unieke code (header). In deze header wordt verwezen naar de header van het vorige block. Als gevolg daarvan worden alle blocken aan elkaar gekoppeld en ontstaat een chain; de blockchain. Tapscott en Tapscott (2016, p. 6) geven aan dat blockchains zijn gebaseerd op Nakamoto’s Bitcoin model, ook wel eerder blockchain 1.0 genoemd. Zij omschrijven blockchain technology als volgt: … like a global spreadsheet or ledger, which leverages the resources of a large peer-to-peer bitcoin network to verify and approve each bitcoin transaction. Each blockchain, like the one that uses bitcoin, is distributed: it runs on computers provided by volunteers around the world; there is no central database to hack. The blockchain is public: anyone can view it at any time because it resides on the network, not within a single institution charged with auditing transactions and keeping records. And the blockchain is encrypted: it uses heavy-duty encryption involving public and private keys (rather like the two-key system to access a safety deposit box) to maintain virtual security. … Every ten minutes, like the heartbeat of the bitcoin network, all the transactions conducted are verified, cleared, and stored in a block which is linked to the preceding block, thereby creating a chain. Each block must refer to the preceding block to be valid. This structure permanently timestamps and stores exchanges of value, preventing anyone from altering the ledger. If you wanted to steal a bitcoin, you’d have to rewrite the coin’s entire history on the blockchain in broad daylight. That’s practically impossible. So the blockchain is a distributed ledger representing a network consensus of every transaction that has ever occurred. Wat deze omschrijvingen van blockchain(-technology) met elkaar gemeen hebben, is dat er sprake is van het gedecentraliseerd opslaan en bijhouden van de transacties. De blokken – die op basis van deze transacties worden gevormd – worden chronologisch
aan elkaar gekoppeld. Daarnaast is er sprake van het gebruik van cryptografie voor de identificatie en authenticatie van de deelnemers en voor het valideren van transacties en het bouwen van een blok. 2.2.1 Blockchain 1.0 ontrafeld Satoshi Nakamoto omschreef in zijn ‘oprichtingspaper’ voor Bitcoin (Nakamoto, 2008) op welke wijze en onder welke voorwaarden een transactie in Bitcoin tussen 2 partijen tot stand moest gaan komen. Hij beschreef hierin onder andere de volgende uitgangspunten: • Alle transacties zijn zichtbaar voor iedereen. Zo weet iedereen wat de ‘waarheid’ is. • Voor het initiëren van een transactie moeten partijen gebruik maken van een private en een public key. Hiermee moeten deze partijen zich identificeren. Omdat deze keys alleen bekend gemaakt worden in de vorm van een hashcode (een cryptografische handtekening), is de identiteit van de betrokken partijen niet makkelijk te achterhalen. Hierdoor wordt gesproken van pseudonimiteit van de betrokkenen (in plaats van anonimiteit). • Om het moment van transactie en de validatie daarvan aan te tonen, wordt er gebruik gemaakt van een timestamp. Hiermee wordt de volgordelijkheid van transacties en de daarmee gevulde blokken vastgelegd. • Nodes zijn alle aangesloten computers de samen het decentrale netwerk (het distributed ledger) van de blockchain vormen. • Er wordt gebruik gemaakt van het principe van Proof of Work. Met behulp van een algoritme wordt een unieke hashcode berekend. Hiermee worden alle transacties in één blok en het blok in z’n geheel gevalideerd. • Voor het uitvoeren van deze berekeningen, kan iedere node zich aanbieden als miner. Een miner stelt computercapaciteit beschikbaar waarmee blokken met nieuwe transacties gemiddeld iedere 10 minuten berekend worden. De miner ontvangt een vergoeding voor het uitvoeren van deze berekening. Het doen van goede berekeningen wordt op deze manier beloond. • Wanneer er consensus is over het gevalideerde blok, betekent dit dat meer dan 50% van alle nodes heeft bevestigd dat het gevalideerde blok correct is. Dit blok wordt vervolgens door alle nodes toegevoegd aan de keten. • Nodes gebruiken altijd de langste keten als de correcte keten en zien deze langste keten als de waarheid. Iedereen kan toegang krijgen tot de Bitcoin blockchain en alle transacties die er ooit gevalideerd zijn bekijken. Daarnaast heeft iedere deelnemer aan deze blockchain rechten om een nieuw blok te valideren en toe te voegen aan de blockchain. Doordat er
geen differentiatie is aangebracht in rechten, wordt de Bitcoin blockchain gezien als public en permissionless (Bauerle, z.j.). 2.2.1.1 DLT-stack Toen de blockchain technology volop in de ‘innovation trigger’-fase van de hype cycle van Gartner (Panetta, 2017, 3e alinea) zat, ontstonden allerlei nieuwe cryptocurrencies zoals Litecoin en Dogecoin. Deze zogenaamde ‘alt-coins’ maakten gebruik van het open source protocol van Nakamoto of borduurden erop voort. Hierdoor kwam er meer bekendheid met het gebruiken van cryptocurrency, maar ontstond er ook veel verwarring over de terminologie. William Mougayar (2016, 1e alinea) omschrijft dit in zijn blog als volgt: “Like any new buzzword, the more a term gets popular, the more it spreads around. The more it will get used, but also misused and abused. It will mean a lot of different things to different people”. Dit gebeurt vaker bij nieuwe ontwikkelingen die als een ‘hype’ worden gezien. Partijen springen er bovenop om zich te onderscheiden met kennis die een andere partij nog niet heeft. De begripsverwarring komt ook voort uit het feit dat de technologie gebruikt wordt om erop door te ontwikkelen, waardoor er meerdere verschijningsvormen ontstaan (Swan, 2015, p. ix). Het is daarom verstandig om een eenduidig beeld te schetsen en de verschillende lagen, waaruit de blockchain technology is opgebouwd, uit elkaar te rafelen. De blockchain – of liever – de distributed ledger zelf is de ‘opslag-laag’ in de vorm van een grootboek. Hierin worden alle transacties die ooit zijn uitgevoerd met een bepaalde ‘asset’ chronologisch vastgelegd (Swan, 2015, p. x). Deze transacties worden samengevoegd in een blok, dat wordt gekoppeld aan het voorgaande blok met transacties. Het complete grootboek bestaat uit alle blokken met alle transacties. Via het Internet worden nieuwe blokken met transacties gedistribueerd aan alle deelnemers aan deze specifieke blockchain. De deelnemers kunnen het nieuwe blok valideren en toevoegen aan hun eigen kopie van het grootboek. Zo beschikt iedere deelnemer – node genoemd – over een exacte kopie van het volledige grootboek. Dit verklaart de terminologie distributed ledger. Omdat het grootboek gedecentraliseerd is, is het niet meer nodig dat een vertrouwde derde partij dit grootboek centraal bijhoudt en verantwoordelijk is voor het betrouwbaar, actueel en compleet houden van de gegevens. Om transacties te kunnen verwerken en te kunnen opslaan in het distributed ledger, wordt er gebruik gemaakt van een protocol. In de Bitcoin blockchain wordt dit Script genoemd. Dit specifieke protocol bestaat uit verschillende instructies waarmee de werking van de blockchain is geprogrammeerd (Seijas, Thompson & McAdams, 2017, p. 5).
De distributed ledger en het protocol samen worden gebruikt om de transacties van iets van waarde (een ‘asset’) te realiseren en op te slaan. In blockchain 1.0 is dat ‘iets van waarde’ de zogenaamde Bitcoin. De eerste Bitcoin werd gemined op 3 januari 2009 en was daarmee de eerste de toepassing of ‘applicatie’ van de onderliggende lagen. Deze ‘blockchain technology-stack’ of eigenlijk liever ‘Distributed Ledger Technology-stack’ (Swan, 2015, p. 10) kan als volgt worden gevisualiseerd: Figuur 1: Distributed Ledger Technology-stack 2.2.2 Andere verschijningsvormen In lijn met de hype cycle van Gartner nam de interesse in blockchain technology na 2009 sterk toe en is de technologie verder ontwikkeld (Panetta, 2017). ‘Blockchain-puriteinen’ lijken Nakamoto’s blockchain protocol te beschouwen als de enige echte blockchain verschijningsvorm. Echter, deze verschijning met de meest brede vorm van toegankelijkheid, volledige openheid van transacties en volledige gelijkheid van rechten – de public permissionless DLT – is niet voor alle toepassingen of soorten organisaties geschikt. Omdat de broncode openbaar is, hebben verschillende consortia zoals de Ethereum Foundation, R3, Ripple en Hyperledger/The Linux Foundation deze gebruikt om blockchain technology breder toepasbaar te maken. De basisgedachte van het decentraal opslaan en bijhouden van alle transacties, blijft echter overeind. Maar, er zijn ook verschillen. Begin 2018 zitten de verschillen met name zitten in de volgende aspecten: • Is er sprake van het geven van bepaalde bevoegdheden of niet (permissioned versus non-permissioned of permissionless)? • Is er sprake van het publiek inzichtelijk zijn van alle transacties of niet (public versus private)? • Is het updaten van het ‘ledger’ (obv rechten en het consensusmodel) volledig gedecentraliseerd of is er een mengvorm van centralisatie en decentralisatie? Distributed Ledger Protocol Applicatie
De mate waarin aan deze verschillende ‘knoppen’ gedraaid wordt, bepaalt de verschijningsvorm. 2.2.2.1 Public permissioned ledgers Door het handhaven van het publieke karakter, is de ledger – en daarmee alle transacties – inzichtelijk voor alle betrokkenen. Echter, in een public permissioned ledger zijn aan geïdentificeerde deelnemers specifieke schrijfrechten toegekend. Deze worden met behulp van een access control layer per gebruiker toegekend in de protocollaag (Smart Contract Werkgroep, 2017, p. 15). In deze vorm vervalt het principe van pseudonimiteit. Een deelnemer moet tenslotte – om schrijfrechten te kunnen krijgen – uniek geïdentificeerd worden. Zo kan een deelnemer geautoriseerd worden om transacties te initiëren en/of om ze te mogen valideren. Door de introductie van permissioning (het geven van meer rechten aan bepaalde deelnemers/nodes) wordt een verschil ten opzichte van de public permissionless verschijningsvorm geïntroduceerd. Er ontstaat een ongelijke verdeling van rechten en daarmee van macht en van verantwoordelijkheid. Dit leidt tot een governance vraagstuk: wie mag wat onder welke voorwaarden? Bijkomend kan het consensusprincipe onder druk komen te staan. Wanneer de schrijfrechten voor het valideren en toevoegen van gevalideerde transacties niet meer aan de meerderheid van de nodes wordt overgelaten, kan de waarheid eenvoudiger gemanipuleerd worden. 2.2.2.2 Private permissioned DLT Wanneer er – naast schrijfrechten voor gespecificeerde deelnemers – ook leesrechten per persoon worden toegekend, is er sprake van een private permissioned DLT. De DLT is alleen toegankelijk en te lezen voor bepaalde vooraf gedefinieerde gebruikers. Het kunnen uitvoeren en/of valideren van transacties, is wederom voorbehouden aan een groep vooraf gedefinieerde gebruikers. Ook in deze vorm vervalt het principe van de pseudonimiteit en moet er voldoende aandacht zijn voor het consensusprincipe om de distributed ledger integer te houden. Onderzoeker is van mening dat deze verschijningsvorm goed toepasbaar is wanneer er in het ledger gegevens worden opgeslagen die niet voor iedereen toegankelijk mogen zijn. Vanwege onze ‘oude’ denkwijze, maar ook vanwege de huidige manier van verantwoording afleggen en/of toezicht houden, past deze vorm bij een groot aantal bedrijfsmodellen in onze huidige samenleving.
2.2.2.3 ‘Old school’ Een extreme mate van permissioning van een DLT leidt tot de welbekende gecentraliseerde vorm van ledgers. In deze situatie zijn we min of meer ‘terug bij af’. De schrijfrechten voor het bijwerken van de transacties is in dit geval belegd bij één partij. De overige deelnemers kunnen alleen maar vaststellen of het overzicht van transacties nog overeenkomt met hun kopie, maar ze hebben geen schrijfrechten om transacties toe te voegen. Onderzoeker is van mening dat er in dit geval eigenlijk geen sprake is van DLT. In onderstaande figuur zijn de verschillende verschijningsvormen weergegeven: Centralised DLT Public/Private permissioned DLT Public permissionless DLT Figuur 2: Weergave verschillende verschijningsvormen DLT (https://www.uitlegblockchain.nl/rchain-synereo-blockchain/) 2.2.2.4 Kanttekeningen Opgemerkt dient te worden dat een DLT in de vorm van private permissionless niet bestaat. Wanneer je partijen exclusief toegang wil geven tot het distributed ledger, is er sowieso sprake van permissioning. Deze combinatie is dus onmogelijk. Verder wordt opgemerkt dat niet alle aanbieders van blockchain- of distributed ledger technology voorzien in het maken van blokken om de transacties in te bundelen. Wanneer de transacties individueel worden gevalideerd en opgeslagen, is er naar de mening van onderzoeker sprake van distributed ledger technology. Voor de leesbaarheid is in het vervolg van deze scriptie de term Distributed Ledger Technology
(DLT) gebruikt, tenzij het expliciet om de technologie gaat die gebruik maakt van het principe van creëren van blokken met transacties, zoals dat bij Bitcoin het geval is. In dat geval wordt (alleen) de term blockchain technology gebruikt. 2.3 Blockchain 2.0: smart contracts Na de introductie van Bitcoin en de daarop volgende altcoins, ontstond de behoefte om ook transacties uit te kunnen voeren voor andere eigendommen of zaken van waarde op basis van het DLT-principe. Daarnaast wilde men graag aanvullende of specifieke voorwaarden kunnen stellen aan het uitvoeren van een transactie. De basisgedachte van deze vervolgontwikkeling was dat “the decentralized transaction ledger functionality of the blockchain could be used to register, confirm, and transfer all manner of contracts and property” (Swan, 2015, p. 10). Hiermee werd blockchain 2.0 geboren: De introductie van ‘smart contracts’ waarin met behulp van programmacode voorwaarden worden gesteld aan het kunnen uitvoeren van transacties. 2.3.1 Smart contracts Bij de opzet van de Bitcoin en onderliggende blockchain had Nakamoto in zijn protocol al rekening gehouden met het principe van voorwaarden stellen aan het uitvoeren van een transactie (Swan, 2015, p. 9). Op pagina 21 verwoordt Swan dit als: “Nakamoto envisioned not just sending money from point A to point B, but having programmable money and a full feature set to enable it”. Hertig (z.j.) geeft hiervoor in haar blog de volgende beschrijving: It’s worth noting that bitcoin was the first to support basic smart contract in the sense that the network can transfer value from one person to another. The network of nodes will only validate transactions if certain conditions are met. Daarnaast is het bijzonder dat Nick Szabo al lang voor de eerste implementatie van blockchain sprak over smart contracts. Szabo voorzag in 1994 namelijk de mogelijkheid om papieren contracten zodanig te programmeren dat een (trans)actie alleen uitgevoerd werd wanneer er aan een vooraf vastgestelde voorwaarde was voldaan. Op dat moment was er echter nog geen technologie beschikbaar waarmee deze programmatuur aangeboden kon worden (Mougayar, 2016 en Arntz, 2017). De Ethereum Foundation bracht in 2015 een protocol voor DLT op de markt in combinatie met smart contracts. Zij werden daarmee de eerste aanbieder van de zogenaamde blockchain 2.0.
Hoewel de term smart contracts doet vermoeden dat er sprake is van een intelligent contract, is het eigenlijk niets anders dan een stuk software dat draait op distributed ledger technology. Het kan worden gebruikt om transacties uit te voeren, maar ook om data af te schermen. Met een smart contract kan bijvoorbeeld worden geregeld dat een arts wel toegang heeft tot de medische geschiedenis van een patiënt, maar niet tot de financiële gegevens van dezelfde patiënt (Arntz, 2017). De software wordt getriggerd door externe data (welke door externe bronnen aangeleverd kan worden) of door een andere actie. Deze trigger leidt – indien aan de juiste voorwaarden is voldaan – tot het aanpassen van data of het starten van een andere (trans-)actie (Mougayar, 2016). De Smart Contract Werkgroep van de Dutch Blockchain Coalition (2017, p. 12) omschrijft een smart contract als “… een deterministisch computerprogramma dat wordt gerepliceerd en uitgevoerd op een blockchain en (daardoor) niet per definitie onder controle is van één partij”. 2.3.2 Kenmerken smart contracts Zoals gezien wordt DLT in verschillende verschijningsvormen aangeboden. Sommige aanbieders van deze DLT bieden deze aan in combinatie met smart contracts. Ondanks deze verschillende verschijningsvormen, zijn de basiskenmerken van de smart contracts zelf grotendeels hetzelfde. Hieronder zijn de belangrijkste genoemd. Smart contracts zijn deterministisch. Een smart contract kan alleen maar doen wat het geprogrammeerd is om te doen (Catchlove, 2017, p. 8). Dat betekent dat de output van de programmatuur – op basis van dezelfde beginwaarde en dezelfde input – altijd hetzelfde is. De werking is daardoor volledig voorspelbaar (Smart Contract Werkgroep, 2017, p. 18). De code van de smart contracts is – net zoals de DLT waarop het draait – gedistribueerd opgeslagen op alle nodes die de DLT vormen (Swan, 2015, p. 16). Dit betekent dat alle deelnemers aan die DLT de code kunnen inzien, kunnen zien wat ze gaan doen en er daardoor op vertrouwen (Everts, 2017, 3e alinea). Hierdoor vervalt de noodzaak om gebruik te maken van een vertrouwde derde instantie, zoals bijvoorbeeld een notaris (Verslype, 2017, 1e alinea). Smart contracts zijn reactief. Een smart contract reageert op een trigger die de programmatuur in werking stelt. Omgekeerd houdt dit in dat een smart contract dus niets doet, tenzij het een bericht of transactie ontvangt, waarmee de code wordt geactiveerd. Wanneer het smart contract vaststelt dat er aan de gestelde voorwaarde(n) is voldaan, voert het de geprogrammeerde (trans-)actie uit (Smart Contract Werkgroep, 2017, p. 19).
Daarnaast zijn smart contracts – in de basis – niet muteerbaar. Als het contract eenmaal is gedistribueerd op de DLT, is de code niet meer (zomaar) te veranderen of te manipuleren. (Everts, 2017, 3e alinea). Afhankelijk van de verschijningsvorm van de DLT en de daarin gehanteerde consensusvorm, kan het smart contract alleen worden aangepast als de meerderheid van de nodes consensus bereikt over de aanpassing en deze als de ‘nieuwe waarheid’ accepteert. Een smart contract voert de code autonoom uit en de uitvoering kan niet worden tegengehouden (Smart Contract Werkgroep, 2017, p. 22). Het kan dus zelfstandig – zonder accordering door een derde partij – wijzigingen aanbrengen in de ledger (Everts, 2007, 3e alinea). Swan (2015, p. 16) noemt dit het door Lessig geïntroduceerde principe ‘Code is Law’ om aan te geven dat software gedrag of een actie afdwingt: het is een wetmatigheid. Als laatste kenmerk wordt hier genoemd dat een smart contract kan bestaan uit meerdere (kleine) smart contracts. Door meerdere smart contracts te combineren, kan deze een specifieke applicatie bieden (Mougayar, 2016, 2e alinea). 2.3.2.1 Oracles Ondanks hun autonomie hebben smart contracts interactie met de buitenwereld nodig om in werking te treden. Hiervoor kunnen ze gebruik maken van bronnen of input van buiten de DLT. Deze input kan leiden tot het starten van een (trans-)actie, bijvoorbeeld de bevestiging van een notaris van de overdracht van een huis van eigenaar A naar eigenaar B. Een andere variant is dat er gebruik gemaakt wordt van één of meerdere vooraf vastgestelde vertrouwde bronnen die geautomatiseerd brongegevens aanleveren voor het vaststellen of aan de voorwaarden voor een (trans-)actie is voldaan. Hierbij kan gedacht worden aan de brongegevens van het KNMI om vast te stellen hoeveel regen er gevallen is in de afgelopen week op een bepaalde plek. Op basis van deze gegevens heeft een boer wellicht recht op uitkering van een vergoeding omdat zijn gewassen vernietigd zijn geraakt door de regenval. Vooraf is namelijk de voorwaarde geprogrammeerd dat als de regenval op een bepaalde plek een grenswaarde overstijgt, de boer automatisch recht heeft op uitbetaling van een vergoeding. In beide gevallen wordt er gebruik gemaakt van zogenaamde ‘oracles’. Een oracle kan een partij of technische bron zijn in de vorm van een database of een persoon die deze rol expliciet toegewezen heeft gekregen. Deze oracle is voor het smart contract de ‘bron van waarheid’ (Smart Contract Werkgroep, 2017, p. 18).
2.3.3 Voordelen en nadelen van het gebruik van smart contracts Aan de toepassing van smart contracts kleven voor- en nadelen. In de vele use cases die er momenteel zijn, wordt het potentieel overbodig worden van een vertrouwde derde partij als het grootste voordeel beschouwd. Er is geen gevestigde derde partij meer nodig voor het initiëren en uitvoeren van (trans-)acties omdat deze in het smart contract zijn geprogrammeerd. Zowel de code hiervoor als de transacties zijn gedistribueerd vastgelegd in de DLT en inzichtelijk voor alle betrokkenen. Hierdoor is er geen noodzaak meer voor een derde partij (Tjong Tjin Tai, 2017, p178). Een ander vaak genoemd voordeel is dat smart contracts meestal efficiënter en minder foutgevoelig zijn. In het geval van traditionele contracten moeten de betrokken partijen zelf de in het contract vastgelegde afspraken implementeren. Dat kost volgens Verslype (2016, 1e alinea) extra tijd, energie en geld en vergroot tevens de kans op fouten. Een smart contract geeft een grotere kans op een snelle uitvoering van de (trans-) actie doordat de acties geprogrammeerd zijn. Catchlove (2017, p. 9) noemt dit kenmerk ‘performance focussed’. Doordat de verwerking van transacties geautomatiseerd verloopt en ‘near real time’ worden opgeslagen in de DLT, is de informatie met dezelfde snelheid beschikbaar bij alle betrokkenen. Met name ten opzichte van de verwerking van transacties die traditioneel gezien over vele schijven lopen of meerdere ‘middle men’ nodig hebben om de transactie te verwerken, is hier een grote tijdswinst te behalen (Arntz, 2017, 8e alinea). Door de (trans-)acties te programmeren, is de kans op fraude kleiner. Catchlove (2017, p. 13) zegt hierover dat “should a breach occur, mechanisms can be programmed into the smart contracts [beforehand] to provide express remedies for the innocent party”. Dit kan door een ‘nooduitgang’ te programmeren. Bijvoorbeeld wanneer er binnen een bepaald tijdsbestek transacties worden uitgevoerd, die buiten de benchmark vallen, kan dat smart contract (tijdelijk) bevroren worden. Een ander groot voordeel is dat een smart contract een hogere mate van zekerheid kan geven over het uitvoeren van dat wat er in het smart contract is vastgelegd. Issues zoals een menselijke fout of een misvatting zijn tot een minimum beperkt (Catchlove, 2017, p. 15). Helaas kan er – bijvoorbeeld wanneer het smart contract niet volledig of juist is geprogrammeerd – ook een fout optreden. Het smart contract wordt dan wellicht wel juist uitgevoerd, alleen wordt niet het juiste uitgevoerd. Dit was het geval bij de inmiddels bekende ‘DAO-hack’. In deze hack werd als gevolg van het niet expliciet uitsluiten van een mogelijkheid in de code (die voor een specifieke functie juist van
toepassing was) zo’n 3,6 miljoen Ether weggesluisd. Deze cryptocurrency vertegenwoordigde op dat moment zo’n €55 miljoen. Helaas kleven er ook nadelen aan het toepassen van smart contracts. Hieronder is een aantal nadelen beschreven. Voor het programmeren van smart contracts wordt er gebruik gemaakt van een programmeertaal zoals ‘Solidity’ of ‘GO’. Vaak wordt deze code alleen in gecompileerde vorm gepubliceerd op de DLT. Een nadeel hiervan is dat deze gecompileerde code niet leesbaar is voor mensen (Smart Contract Werkgroep, 2017, p. 23). Dit kan afbreuk doen aan het vertrouwen in het smart contract. Ze kunnen echter ook in een gecodificeerde vorm van een traditioneel contract of in een mengvorm (computercode in combinatie met taal uit traditionele contracten) verschijnen (Catchlove, 2017, p. 6). In dat geval is de kans op afbreuk aan het vertrouwen een stuk kleiner. Een ander nadeel van het programmeerbaar zijn van smart contracts is dat een programmeur kennis moet hebben van de programmeertaal, de bedrijfsprocessen en van de juridische- of risicokant. Een mogelijkheid om deze kenniskloof te overbruggen is dat deze disciplines zeer nauw met elkaar samenwerken. Eind 2017 zijn er niet zoveel non-IT-mensen die bijvoorbeeld de programmeertaal Solidity beheersen. Daarnaast ontbreekt bij de IT-mensen die deze taal wel machtig zijn weer vaak de benodigde business of juridische kennis of ervaring in risk management. Het tekort aan deze (multidisciplinaire) kennis is zorgelijk voor de mate van ‘in control’ zijn. De ‘autonomie-medaille’ kent ook een keerzijde. Een smart contract gaat, wanneer het eenmaal getriggerd is, door met uitvoeren tot dat het een andere geprogrammeerde voorwaarde ‘tegenkomt’. In dergelijke voorwaarde wordt bijvoorbeeld gesteld dat de uitvoering van het smart contract beëindigd moet worden, als aan die voorwaarde wordt voldaan. Wanneer er dus fouten in het smart contract geprogrammeerd zitten, zal de uitvoering ervan gewoon doorgaan. Menselijk ingrijpen is in deze gevallen de enige optie, waarbij er consensus zal moeten zijn over (de noodzaak) van dit ingrijpen. In public permissionless netwerken is het snel verkrijgen van deze consensus lastiger dan in de meestal wat kleinere private permissioned netwerken. In deze laatste verschijningsvorm ken je alle deelnemers namelijk en kun je ze dus rechtstreeks en sneller benaderen om tot consensus te komen. Een laatste nadeel wat hier genoemd wordt, is dat er voor de communicatie op de verschillende protocolniveaus kennis moet zijn van meerdere soorten programmeertalen. Ook zijn nog niet alle smart contracts ontwikkeltools volledig door-ontwikkeld en zijn er op dit moment nog niet zo veel ‘best practices’ of ‘ontologie- of
taxonomiestandaarden’ (Smart Contract Werkgroep, 2017, p. 48 en 56). Dit compliceert de ontwikkeling van smart contracts. 2.4 Een vergelijk met traditionele transactie verwerkende informatiesystemen Wat is er nu zo bijzonder aan DLT en smart contracts? Traditionele informatiesystemen zijn ten slotte ook gelaagd opgebouwd en kennen ook hun uitdagingen in het programmeren van software, het autorisatieproces, het uitwisselen van data binnen de lagen van de infrastructuur, de manier waarop databases integer gehouden moeten worden of transacties op een juiste manier uitgevoerd, verwerkt en opgeslagen moeten worden. Wat dat betreft niets nieuws. Wat DLT en smart contracts echter wèl bijzonder maakt is dat er processen en (trans-) acties geprogrammeerd worden, waarvan we tot een paar jaar geleden nooit gedacht hadden dat die te automatiseren waren. Een hele ‘gevestigde orde’ van vertrouwde derde partijen ziet haar bestaansrecht op haar grondvesten schudden. De huidige wetgeving voorziet niet in deze nieuwe wereld en toezichthouders, wetgevers, beoordelaars en uitvoerders vragen zich af wat hun rol is in het geheel. De gedachte van het gedecentraliseerd of gedistribueerd opslaan van alle transacties, het protocol en de software die deze transacties mogelijk maken, is ongekend. Er wordt vertrouwen gecreëerd in een netwerk van partijen die elkaar niet (hoeven te) vertrouwen. De omschrijving ‘disruptieve technologie’ is hier daarom absoluut van toepassing. Ondanks de overeenkomsten is er een enorm verschil met de traditionele manier van (ver-)werken waarbij een centrale partij bepaalt wat de waarheid is. De belangrijkste verschillen vinden hun oorsprong in het loslaten van de centraal vastgestelde en beheerde ‘master copy’ in het geval van een traditionele database. In de DLT wordt het valideren en verwerken van de transacties – zoals al eerder aangegeven – door een aantal of alle nodes in de DLT uitgevoerd. Doordat zij samen bepalen wat de waarheid is, wordt de betrouwbaarheid van de gegevens door de deelnemers samen bepaald. Als gevolg van dit principe zijn volgens Bauerle (z.j.) de volgende verschillen te onderkennen tussen de traditionele omgeving en de DLT-omgevingen: 1. Door het decentraliseren van de ‘control’, worden de risico’s van gecentraliseerde control geëlimineerd. Hierbij richt hij zich vooral op het risico van corruptie of verwijderen van gegevens. Door de vaststelling van de waarheid te decentraliseren en ervoor te zorgen dat de aangesloten partijen deze waarheid zelf vaststellen,
valideren en bijwerken, verdwijnt de ‘single point of failure’ en de ‘single point of control’. 2. Wanneer er geen single point of control is, wordt ook het risico op een effectieve hack verkleind. Een hack op één of een aantal nodes veroorzaakt nog geen hack op het geheel. Pas wanneer het merendeel van de validerende partijen tegelijkertijd wordt gehacked, kan een hack effectief zijn en mogelijkerwijs de historie van de transacties of de code van een smart contract wijzigen. 3. In een traditionele database wordt de informatie bijgehouden die op dat moment de ‘stand van zaken’ weergeeft. Alle transacties zijn geconsolideerd en geven de huidige situatie weer. De transacties die tot deze huidige stand van zaken hebben geleid, zijn alleen maar te deduceren wanneer je alle versies van de database zou bewaren. Een andere optie is om alle transacties - die leiden tot een update van de stand van zaken - ook apart op zou slaan. De DLT daarentegen is juist een ledger van – in de basis – alleen de transacties. In dit geval zou je de huidige stand van zaken moeten deduceren of juist ook expliciet op moeten slaan. Juist aan het bijhouden en inzichtelijk houden van alle transacties ontleent de DLT zijn betrouwbaarheid. 4. Aanhangers van DLT beweren dat de verwerking van transacties met behulp van smart contracts vele malen sneller is dan in de traditionele omgevingen. Dat moet echter in het licht van het grotere geheel worden gezien. Het is inderdaad waar dat een verwerking en validatie van bijvoorbeeld ‘cross-border-betalingen’ sneller gaat dan via de conventionele weg. Dit gaat met smart contracts op een DLT in een kwestie van minuten in plaats van dagen. Echter, er kunnen met de huidige DLT veel minder individuele transacties per minuut worden uitgevoerd, waardoor het juist weer langer kan duren voordat een individuele transactie ‘aan de beurt is’ om verwerkt te worden. Daarnaast is het stroomverbruik voor de verwerking van transacties – wanneer gebruik gemaakt wordt van het mining principe op basis van de ‘Proof of Work’ methode voor de validatie van transacties en blokken – extreem hoog. In een tijd waarin klimaatbewustzijn hoog op de wereldagenda staat, is het moeilijk uitlegbaar om deze techniek te verdedigen. 5. De verschijningsvormen van DLT in combinatie met smart contracts hebben verschillende manieren om de toegang tot de gegevens te beperken zodat de gegevens (deels) vertrouwelijk blijven. Dit houdt in dat er veel aandacht moet worden besteed – net zoals in traditionele omgevingen – aan het inrichten en actueel houden van rechten en autorisaties om deze vertrouwelijkheid te borgen. Het limiteren van de toegang tot de gegevens of het versleutelen van de gegevens vergt veel (cryptografische) maatregelen, met bijbehorende belasting van de benodigde
rekenkracht om dit te realiseren. Wanneer het doel dus is om vertrouwelijkheid van de gegevens te waarborgen, kun je je afvragen of een DLT hiervoor wel het juiste middel is. 2.5 Samenvatting en conclusie De blockchain(-technology) heeft de afgelopen tien jaar flink wat ontwikkelingen doorgemaakt. De technologie is geëvolueerd van een peer-to-peer netwerk voor de transactie van cryptocurrencies naar een nieuwe technologie waarmee vele business toepassingen uitgeprobeerd worden. Ondanks de verschillende DLT-verschijningsvormen en hun additionele kenmerken, blijft een aantal basisprincipes overeind. Transacties worden decentraal gevalideerd met cryptografische berekeningen en op basis van consensus bijgehouden in een ‘distributed ledger’. Het vertrouwen in de gegevens wordt ontleend aan het feit dat alle deelnemers inzicht hebben in de waarheid en deze waarheid zelf kunnen valideren. Geen van de betrokkenen kan de waarheid aanpassen, zonder dat dit volledig inzichtelijk is voor alle andere betrokkenen. Vertrouwen op een derde (centrale) partij is hiermee overbodig gemaakt. Door op de technologie van blockchain 1.0 voort te bouwen, zijn er verschillende verschijningsvormen. Hierbij kan in de basis aan drie ‘knoppen’ gedraaid worden: • Is er sprake van het geven van bepaalde bevoegdheden of niet (permissioned versus non-permissioned of permissionless)? • Is er sprake van het publiek inzichtelijk zijn van alle transacties of niet (public versus private)? • Is het updaten van het ‘ledger’ (obv rechten en het consensusmodel) volledig gedecentraliseerd of is er een mengvorm van centralisatie en decentralisatie? Vervolgens is er aan deze DLT als ‘basislaag’ een extra stuk logica toegevoegd. Deze logica wordt geboden door smart contracts. Dit was de geboorte van blockchain 2.0. Een smart contract bestaat uit kleine stukjes programmacode waarin voorwaarden worden gesteld waaronder een transactie wordt uitgevoerd. Doordat ook de code van de smart contracts gedistribueerd wordt ter validatie en acceptatie door alle nodes, bepalen zij samen op basis van het consensusmodel of het smart contract toegepast kan worden. Het smart contract wordt vervolgens opgeslagen en gebruikt door alle nodes om (trans-)acties mee te verwerken. Hierdoor is wederom iedere node in staat om zelf vast te stellen wat de output is van een transactie, alvorens deze vast te leggen in het distributed ledger waarmee de kracht van de gedeelde waarheid overeind blijft. De ontwikkelingen blijven maar doorgaan en gaan sneller dan bij te houden is. Er wordt al gesproken over blockchain 3.0, waarin nieuwe bedrijfsspecifieke toepassingen, test
tooling en consensusmodellen worden ontwikkeld. Waar deze ontwikkelingen naartoe gaan, kunnen we nu nog niet overzien. Ook vanuit het perspectief van de IT-auditor zijn er vele vragen. Eén van deze vragen is hoe een IT-auditor de integriteit van smart contracts kan beoordelen of daarover kan adviseren. In het volgende hoofdstuk wordt een voorstel gedaan voor een normenkader dat een IT-auditor hiervoor zou kunnen hanteren.
3 Beoordeling
3.1 Inleiding Het werkveld van IT-auditors is zeer divers. Veltman (Fijneman, Roos Lindgreen, Veltman & Hang Ho, 2011, p. 78) geeft aan dat “IT-auditing tot doel [heeft] belanghebbenden te helpen met de toepassing van informatietechnologie”. De term auditing in bredere zin definieert hij als “de functie of het proces om een bepaald object van onderzoek (subject matter) te onderzoeken, met als doel een conclusie te vormen over één of meer eigenschappen ervan”. Doordat het object van onderzoek te maken heeft met informatietechnologie, wordt er dus gesproken over IT-auditing. IT-auditing kan zich echter – naast het vormen van een oordeel of conclusie – ook richten op het geven van advies, waarbij er niet per definitie een oordeel wordt geveld. In dit geval wordt er onderzoek gedaan naar een onderzoeksobject en naar de eigenschappen die dit onderzoeksobject heeft. De IT-auditor doet in dit onderzoek bevindingen en analyseert deze. Op basis hiervan kan hij of zij advies geven of aanbevelingen doen aan de belanghebbenden bijvoorbeeld over de mate waarin het object van onderzoek voldoet aan de daaraan gestelde eisen. Een laatste vorm van IT-auditing is de opdracht tot het verrichten van overeengekomen specifieke werkzaamheden. In deze opdrachtvorm kan een IT-auditor bijvoorbeeld als consultant optreden. In ieder geval zal de IT-auditor ook in deze opdrachtvorm een object onderzoeken en hiervan feitelijke bevindingen en eventuele aanbevelingen doen. Kenmerkend voor deze opdrachtvorm is dat er alleen gerapporteerd wordt over de feitelijke bevindingen en dat dit rapport alleen verstrekt wordt aan de opdrachtgever (Fijneman, Roos Lindgreen, Veltman & Hang Ho, 2011, p. 78-87). Wanneer een IT-auditor op zoek gaat naar bevindingen ten aanzien van eigenschappen van het object van onderzoek, moet er vooraf overeenstemming zijn over de eisen waaraan het object van onderzoek moet voldoen. Op deze manier krijgen opdrachtgever en IT-auditor een gemeenschappelijk beeld van de scope en reikwijdte van het onderzoek. Vaak wordt er – in het kader van een IT-audit – onderzoek gedaan naar het kwaliteitsaspect wat in de ‘volksmond’ omschreven wordt als de betrouwbaarheid van het informatiesysteem (of een onderdeel daarvan). Helaas is er in de literatuur geen eenduidig beeld over wat er onder betrouwbaarheid wordt gevat. Vanuit de oorspronkelijk Engelse vakliteratuur wordt ‘reliability’ naar het Nederlands vertaald als betrouwbaarheid. Toch dekt deze vertaling niet helemaal de lading. Vanuit de wereld van de accountancy duidt de term betrouwbaarheid op juistheid, tijdigheid en volledigheid van de gegevens. In de IT heeft de term betrouwbaarheid vooral te makenmet beschikbaarheid of herstelbaarheid van de IT-omgeving (Van Gils en Basten, 1999). Ook wordt met betrouwbaarheid in het kader van IT-audits ten behoeve van de accountantscontrole gedoeld op het Engelse woord ‘integrity’ als aanduiding voor dit kwaliteitsaspect. Saillant detail is dat NOREA in haar omschrijving niet spreekt van betrouwbaarheid als één van de onderscheidende kwaliteitsaspecten. Daarom moet altijd expliciet helder worden gemaakt wat er onder het te onderzoeken kwaliteitsaspect wordt verstaan. Hoe is dit te vertalen in concrete kwaliteitseisen, welke normen gelden er voor deze eisen en tot welke toetsingscriteria leiden deze eisen en normen gezamenlijk. Voor dit afstudeeronderzoek is ook zo’n specificering noodzakelijk. In het vervolg van dit hoofdstuk wordt daarom eerst beschreven welke kwaliteitsaspecten volgens NOREA onderzocht kunnen worden in het opzetten en uitvoeren van een IT-audit. Vervolgens gaat paragraaf 3.3 in op de meer concrete kwaliteitseisen die volgens ISO/IEC gesteld worden aan een software product. Paragraaf 3.4 geeft het verband weer tussen de kwaliteitsaspecten volgens NOREA en de kwaliteitseisen volgens ISO/IEC, waarbij wordt ingezoomd op kwaliteitsaspect integriteit. In de laatste paragraaf treft de lezer de samenvatting en conclusies van dit hoofdstuk aan. 3.2 Kwaliteitsaspecten volgens NOREA Zoals in de inleiding van dit hoofdstuk beschreven, zijn er vele invullingen van de kwaliteitsaspecten. De ‘bril’ waardoor naar deze aspecten wordt gekeken, bepaalt de specifieke invulling ervan. Is er bijvoorbeeld sprake van een financiële audit of van een IT-audit. Daarnaast zijn ze afhankelijk van de taal waarin gekeken wordt naar een IT-audit en de branche waarin het object van onderzoek zich bevindt. Voorliggend afstudeeronderzoek wordt uitgevoerd in het kader van de studie IT-audit. Om deze reden is er voor de beschrijving van de kwaliteitsaspecten gebruik gemaakt van de kwaliteitsaspecten zoals die door de Nederlandse beroepsorganisatie NOREA zijn gedefinieerd. In het NOREA geschrift No. 1 genaamd ‘IT-auditing aangeduid’ (Van Biene-Hershey et al., 1998, p. 47-51) heeft NOREA de volgende zeven kwaliteitsaspecten gedefinieerd: 1. Effectiviteit 2. Efficiëntie 3. Exclusiviteit 4. Integriteit 5. Controleerbaarheid 6. Continuïteit 7. Beheersbaarheid
