Betalingsverkeer Virtuele munten
Een analyse van een normenkader voor het betalingsverkeer van crypto grafische valuta
Nummer: 2044 13-07-2015
Auteur Jeroen Kleijn, MSc
Begeleider Dr. Abbas Shahim, RE (VU)
Voorwoord Deze scriptie is tot stand gekomen in het kader van de Postgraduate IT-audit, Compliance & Advisory opleiding aan de Vrije Universiteit te Amsterdam. Door mijn grote interesse in financiële markten en virtuele munten kwam ik op het idee om dit te combineren tot een geschikt scriptie onderwerp. Graag zou ik Dr. Abbas Shahim, RE (VU) willen bedanken voor zijn medewerking tijdens het scriptietraject en de vele sparring sessies die we over dit onderwerp hebben gehad.
I
Inhoudsopgave VOORWOORD .................................................................................................................................. I LIJST VAN FIGUREN ...................................................................................................................... III INLEIDING ........................................................................................................................................ 1 1.1 1.2 1.2.1 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 2.
RELEVANTIE ............................................................................................................................................ 1 DOELSTELLING ........................................................................................................................................ 1 Deelvragen ........................................................................................................................................ 1 ONDERZOEK BESCHRIJVING .................................................................................................................... 2 Methode ........................................................................................................................................... 2 Scope ................................................................................................................................................ 3 Randvoorwaarden ........................................................................................................................... 3 Planning ........................................................................................................................................... 3 Indeling ............................................................................................................................................ 3
RISICOPROFIEL BITCOIN ....................................................................................................... 4 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2
3
WAT IS DE BITCOIN? .............................................................................................................................. 4 Transactie ........................................................................................................................................ 5 Blockchain ....................................................................................................................................... 6 Mining .............................................................................................................................................. 7 RISICO IDENTIFICATIE ............................................................................................................................ 8 Strategische risico’s ......................................................................................................................... 8 Tactische risico’s ............................................................................................................................10 Operationele risico’s........................................................................................................................11 WAARDE MIDDELEN.............................................................................................................................. 12 Betalingsverkeer fiat geld ............................................................................................................... 12 Vergelijking geld met bitcoin ......................................................................................................... 13
ANALYSE TOEPASBAARHEID SOC2 RICHTLIJN .................................................................... 14 3.1
TRUST PRINCIPLES ................................................................................................................................. 14 3.1.1 Security ........................................................................................................................................... 14 3.1.2 Availability ...................................................................................................................................... 14 3.1.3 Processing Integrity ....................................................................................................................... 15 3.1.4 Confidentiality ................................................................................................................................ 15 3.1.5 Privacy .............................................................................................................................................16 3.2 RISICO ANALYSE ....................................................................................................................................16 3.2.1 Strategische risico’s ........................................................................................................................ 18 3.2.2 Tactische risico’s ............................................................................................................................19 3.2.3 Operationele risico’s.......................................................................................................................19 3.3 OPSTELLEN VAN GESCHIKT NORMENKADER .......................................................................................... 21 3.4 VALIDATIE ............................................................................................................................................ 21 4. CONCLUSIE ................................................................................................................................. 22 4.1 4.2 4.3 4.4
BEANTWOORDING DEELVRAGEN .......................................................................................................... 22 BEANTWOORDING HOOFDVRAAG ........................................................................................................ 23 REFLECTIE ............................................................................................................................................ 25 NADER ONDERZOEK ............................................................................................................................. 25
BIBLIOGRAFIE ............................................................................................................................... 26 II
BIJLAGEN ........................................................................................................................................28 APPENDIX A: ANALYSE TOEPASBAARHEID SOC2 PRINCIPLES OP GEÏDENTIFICEERDE RISICO’S ........................... 28 APPENDIX B: ANALYSE NORMENKADER SOC2 .................................................................................................. 29
Lijst van figuren Figuur 1: Stappenplan onderzoek ........................................................................................................................ 2 Figuur 2: Onderzoeksmethode (Yin, 2013) ......................................................................................................... 3 Figuur 3: Blockchain (proof-of-work schakels) (Nakamoto, 2013) .................................................................. 5 Figuur 4: Bitcoin code .......................................................................................................................................... 5 Figuur 5: Voorbeeld van een bitcoin wallet (online portefeuille).................................................................... 6 Figuur 6: Koers Bitcoin/USD ............................................................................................................................... 9 Figuur 7: Betalingsverkeer SWIFT netwerk ...................................................................................................... 13 Figuur 8: Stappenplan FOCUS risicoanalyse (DNB, 2012) ............................................................................... 17 Figuur 9: Raamwerk Beveiliging Web applicaties (Nationaal Cyber Security Centrum, 2010) .................. 20
III
Inleiding Op 28 februari 2014 vraagt Mt.Gox, op dat moment de grootste bitcoin beurs ter wereld, faillissement aan bij de rechtbank van Tokio. Het bedrijf was 850.000 bitcoins met een waarde van ongeveer 300 miljoen euro kwijt geraakt. Deze schade zorgde ervoor dat het bedrijf afstevende op faillissement. Mt.Gox was op het hoogtepunt goed voor 76 procent van alle dagelijkse bitcoin transacties (Wat is bitcoin?, 2014). Hoe die bitcoins zijn kwijtgeraakt, is onduidelijk. Er gaan geruchten dat Mt. Gox zelf de bitcoins heeft weggesluisd, maar misschien zijn de bitcoins buitgemaakt bij een hack die al in 2011 werd gepleegd. Twee maanden laten, in mei 2014, verbood China de bitcoin. Het land was bezorgd over de munt die een risico zou vormen voor de financiële stabiliteit van het land en voor de controle van de overheid over kapitaal. De Chinese autoriteiten beschouwden de bitcoin als een instrument om langs digitale weg Chinees kapitaal uit te voeren, iets wat normaal gesproken streng gereguleerd is. Volgens The Economist was China verantwoordelijk voor meer dan de helft van ‘s werelds bitcoinhandel.
1.1
Relevantie
De bitcoin bestaat uit een gecompliceerde software die open source, 100% transparant en volledig decentraal werkt. De discussie over de bitcoin is nuttig, want die gaat over de basis van de waarde van geld: vertrouwen. De digitale valuta is vrijwel anoniem en niet gekoppeld aan een centrale bank of overheid. Bitcoin haalt de macht, controle en vertrouwensfunctie weg bij banken, en vervangt deze door wiskundige principes en cryptografie. De grote vraag is of de bitcoin geaccepteerd wordt als een betaal- en waarde middel. Net als bij aandelen wordt de waarde van de bitcoin bepaald door de vraag. Deze vraag is gebaseerd op het vertrouwen van de consument in de bitcoin. Maar is de bitcoin eigenlijk te vertrouwen?
1.2
Doelstelling
Het doel van dit onderzoek is na te gaan of bitcoin exchange en wallet websites (online portefeuille) behoefte hebben aan zekerheid. Hierbij betreft de verwachtte uitkomst een raamwerk van beheersmaatregelen dat wordt gebruikt als basis om zekerheid te bieden aan de integriteit, volledigheid en continuïteit van de twee entiteiten (exchange en wallet websites) binnen het betalingsverkeer van virtuele munten. De hoofdvraag welke is onderzocht is de volgende: Op welke gebieden kan zekerheid worden gegeven aan de exchange en wallet websites binnen het betalingsverkeer van virtuele munten? 1.2.1 Deelvragen Om deze hoofdvraag te kunnen beantwoorden zijn de karakteristieken van de bitcoin onderzocht (1: Situatie). Aan de hand van deze kenmerken zijn de risico’s van de bitcoin in kaart worden gebracht (2: Complicatie). Ten slotte is gezocht naar een geschikt normenkader om de gesignaleerde risico’s te mitigeren (3: Eindproduct).
1
1
• Situatie • Beschrijving van bitcoin
2
• Complicatie • Beschrijving van de risico's in betalingsverkeer van bitcoin
3
• Eindproduct • Normenkader voor het verschaffen van zekerheid
Figuur 1: Stappenplan onderzoek
Tijdens het onderzoek wordt antwoord gegeven op de volgende deelvragen:
Wat zijn de karakteristieken van de bitcoin? Wat zijn de risico’s van het bitcoin betalingsverkeer? Welk raamwerk kan worden gebruikt als basis om zekerheid te verschaffen aan exchange en wallet websites in het betalingsverkeer van virtuele munten?
1.3 Onderzoek beschrijving 1.3.1 Methode Voor de uitvoering van het onderzoek is gebruik gemaakt van de onderzoeksmethode van Robert K. Yin. In zijn boek ‘Case study research, design and methods’ gaat hij uit van een lineaire en iteratieve aanpak waarbij hij het onderzoek opdeelt in verschillende fases (zie figuur 2). Yin definieert zijn onderzoeksmethode als empirisch onderzoek dat een bestaande onderzoekseenheid (in dit geval de bitcoin) binnen haar context onderzoekt (Yin, 2013). In de ‘Plan’ fase betreft een inventariserende fase. In deze fase zijn de onderzoeksvragen opgesteld en is de onderzoeksmethode gekozen. Tevens is deze fase een literatuuronderzoek uitgevoerd naar de kenmerken van virtueel betalingsverkeer. Deze uitkomst is in de volgende fases gebruikt. Ook de ‘Design’ fase is inventariserend van aard. In deze fase is een onderzoek gedefinieerd en een onderzoeksmethode gekozen. Middels verschillende gesprekken met experts op het gebied van financiële markten is inzicht verkregen in de bestaande risico’s. In de ‘Prepare’ fase is er een risico identificatie methode geselecteerd waarmee de voorbereidingen voor de analyse zijn getroffen. Middels deze methode zijn de risico’s van het bitcoin betalingsverkeer geanalyseerd en ingedeeld in strategische, tactische en operationele risico’s. In de ‘Collect’ fase was het doel het inventariseren en verzamelen bestaande Assurance oplossingen omtrent het bieden van vertrouwen in virtueel betalingsverkeer. In deze fase zijn de trust principles van de SOC2 richtlijn beschreven. Daarbij is gekeken naar de kenmerken van het principle. In de ‘Analyze’ fase is een detailanalyse uitgevoerd op het SOC2 normenkader en getoetst of deze toepasbaar zijn op de gesignaleerde risico’s. Als uitkomst wordt een normenkader opgesteld wat de binnen de exchange en wallet websites in het betalingsverkeer aanwezige risico’s mitigeert.
2
In de ‘Share’ fase is gekeken naar de uiteindelijke toepasbaarheid van het opgestelde normenkader. Het normenkader is besproken met betrokken personen binnen IT Audit praktijk waarbij is gekeken naar de herkenbaarheid van het ontwikkelde normenkader.
Figuur 2: Onderzoeksmethode (Yin, 2013)
1.3.2 Scope Dit onderzoek richtte zich op vertrouwen in het bitcoin betalingsverkeer. De afbakening en scope van de opdracht omvat het bitcoin betalingsverkeer en de bijbehorende risico’s. Het SOC2 normenkader kan een essentiële bijdrage leveren aan het mitigeren van deze risico’s en het bieden van zekerheid. 1.3.3 Randvoorwaarden Het onderzoek is afhankelijk van verschillende randvoorwaarden. Tijdens het onderzoek zijn een aantal ervaringen opgedaan, die mogelijk nuttig zijn om als randvoorwaarden mee te nemen bij het lezen van deze scriptie. In de uitwerking van het onderzoek is de auteur ervan uit gegaan dat de lezer kennis heeft van de bitcoin, het IT Audit vakgebied en de SOC2 richtlijn. 1.3.4 Planning De opdrachtuitvoering bestond uit vier fasen, ieder met een vooraf gedefinieerde doorlooptijd, namelijk:
Fase 1 ‘Plan & Design’, oktober 2014. De doorlooptijd van deze fase was 1 maand; Fase 2 ‘Prepare & Collect’, oktober 2014. De doorlooptijd van deze fase was 4 maanden; Fase 3 ‘Analyze’, januari 2015. De doorlooptijd van deze fase was 2 maanden; Fase 4 ‘Share’, is gestart nadat de resultaten uit het onderzoek zijn verkregen. Het conceptrapport is opgeleverd in maart 2015 waarna afstemming heeft plaatsgevonden. De doorlooptijd van deze fase was een maand; Finale Scriptie is op 16 mei 2015 ingediend.
1.3.5 Indeling In deze scriptie zijn de karakteristieken van de bitcoin beschreven in hoofdstuk 2. Aan de hand van deze kenmerken zijn de risico’s van de het virtuele betalingsverkeer in kaart gebracht. Als resultaat van hoofdstuk 2 is een overzicht gegeven van de aanwezige risico’s in het Bitcoin betalingsverkeer. Vervolgens is onderzocht of zekerheid aan exchange en wallet websites in het betalingsverkeer kan worden geboden. Door middel van een analyse van het SOC2 normenkader is in hoofdstuk 3 gekeken of
3
de gesignaleerde risico’s kunnen worden afgedekt. Tenslotte is er in hoofdstuk 4 antwoord gegeven op de deelvragen en hoofdvraag.
2. Risicoprofiel bitcoin “Bitcoin is an exciting innovation that has the potential to greatly improve human welfare and jump-start beneficial and potentially revolutionary developments in payments, communications, and business” (Brito & Castillo, 2013).
2.1 Wat is de bitcoin? Een virtuele valuta is een vorm van niet-gereguleerd digitaal geld dat kan fungeren als betaalmiddel. Een belangrijk kenmerk is dat het geld niet wordt uitgegeven of gegarandeerd door een centrale bank. Virtuele valuta zijn er in verschillende vormen, bijvoorbeeld valuta binnen online gaming omgevingen en sociale netwerken (Second Life, World of Warcraft). De 'Bitcoin' heeft gezorgd voor een nieuwe generatie virtuele valuta, vaak ook wel aangeduid als crypto valuta. Deze gedecentraliseerde, elektronische munteenheid is in 2009 ontwikkeld door de persoon die schuilgaat achter het pseudoniem Satoshi Nakamoto. In zijn artikel “Bitcoin: a Peer-to-Peer electronic cash system” beschrijft Nakamoto zijn alternatief voor het reguliere betalingsverkeer: “Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model” (Nakamoto, 2013). In tegenstelling tot de meeste munteenheden hangt de werking van Bitcoin niet af van een centrale instelling, maar van een gedistribueerde database. Om te voorzien in de nodige beveiliging, zoals de garantie dat Bitcoins alleen eenmalig kunnen worden uitgegeven door de persoon die er eigenaar van is, maakt de door Nakamoto ontworpen software gebruik van cryptografie. De bitcoin is een van de eerste munten waarbij gebruik wordt gemaakt van cryptografie. Nakamoto heeft zijn ontwerp gebaseerd op het idee van cryptograaf Wei Dai, die al in 1998 voor de eerste keer over een vorm van elektronisch geld had dat niet traceerbaar is en waarvan de eigenaars desgewenst anoniem kunnen blijven. In zijn paper geeft Nakamoto een oplossing voor het probleem van double spending; het risico dat een bitcoin meer dan één keer door eenzelfde persoon kan worden uitgegeven. Het netwerk maakt gebruik van een distributed time server, een logboek dat de transacties bijhoudt en in chronologische volgorde rangschikt, en een modificatie van die gegevens onmogelijk maakt. De integriteit van dit logboek wordt gegarandeerd door de proof-of-work schakels (zie figuur 3). Hoewel het versturen van bitcoins onmiddellijk gebeurt, worden transacties pas als definitief beschouwd na de voltrekking van het clearingproces, een procedure waarbij de bitcoinsoftware (genaamd de bitcoinclient of de client) een bepaalde transactie verschillende malen confirmeert. Hoe meer bevestigingen er zijn, hoe kleiner de kans om slachtoffer te worden van het probleem van double spending. Wanneer het netwerk meer dan vijf bevestigingen heeft gegenereerd, wordt een transactie technisch gezien zelfs onomkeerbaar.
4
Figuur 3: Blockchain (proof-of-work schakels) (Nakamoto, 2013)
Door de crypto keten is het risico op double spending bijna onmogelijk (Twesige, 2015). In theorie is het enkel mogelijk wanneer de hacker de controle bezit over minstens 51% van de rekenkracht van alle computers die het netwerk beschermen. Gezien het aantal deelnemende computer in het netwerk is dit risico klein. In het systeem zit een manier geprogrammeerd dit soort aanvallen detecteert en signaleert. 2.1.1 Transactie Voor een bitcoin transactie zijn twee partijen nodig die de transactie moeten bevestigen. Elke deelnemer in het bitcoin netwerk beschikt over een wallet (online portefeuille) die cryptografische sleutelparen bevat. De zichtbare bitcoin adressen zijn afgeleid van de publieke sleutels van elke gebruiker, die op hun beurt functioneren als afzenders of ontvangers van alle bitcoin betalingen. Voor elke publieke sleutel bestaat één corresponderende private sleutel, zonder welke een gebruiker geen enkele betaling vanuit zijn wallet kan uitvoeren. De publieke adressen bevatten niet de minste informatie over de eigenaars van de wallets. Ze bestaan uit een combinatie van 33 geheel willekeurig gekozen letters en cijfers (zie figuur 4).
Figuur 4: Bitcoin code
Bitcoin gebruikers kunnen ook meerdere adressen beheren. Het creëren van een nieuw adres is het genereren van een nieuw sleutelpaar (publieke en private sleutel), wat zonder tussenkomst van enig knooppunt in het netwerk gebeurt. Gebruikers die volledig anoniem willen blijven, kunnen daarmee voor elke transactie een nieuw adres aanmaken.
5
De gegevens waarmee je de controle over je bitcoins uitoefent, kunnen worden opgeslagen in een digitale portefeuille, de zogenaamde wallet. Daarnaast zijn er ook online wallets waar je de bitcoins kan bewaren (zie figuur 5). De eigenaar kan ook fysiek de informatie bewaren door de code te onthouden of op te schrijven. Met die gegevens kunnen bitcoins vervolgens via het internet worden overgedragen aan iedereen die over een bitcoin adres beschikt.
Figuur 5: Voorbeeld van een bitcoin wallet (online portefeuille)
Wanneer gebruiker A bitcoins verstuurt naar gebruiker B, dan doet gebruiker A afstand van zijn bitcoins door ze toe te voegen aan het publieke adres van gebruiker B en de daaruit resulterende combinatie te ondertekenen door middel van zijn eigen private sleutel. Dankzij het gebruik van asymmetrische cryptografie is het echter onmogelijk de private sleutel uit de handtekening af te leiden. Deze informatie wordt vervolgens als nieuwe transactie naar het hele p2p-netwerk verstuurd. Voordat de transactie door het netwerk wordt geaccepteerd, zullen de overige knooppunten zowel het aantal bitcoins dat betrokken is bij de transactie verifiëren, alsook de authenticiteit van de crypto grafische handtekeningen. 2.1.2 Blockchain Geen enkele naar het netwerk verzonden transactie is onmiddellijk ‘officieel’. De transactie moet daarvoor eerst worden opgenomen in het collectief bijgehouden logboek van alle bitcoin transacties: de blockchain. Dit is het grootboek van alle bitcoin transacties. Deze keten van transactieblokken is het werk van de bitcoin miners, dit zijn de computers in het netwerk die de bitcoin software hebben geïnstalleerd en via het internet met elkaar in verbinding staan (Wat is bitcoin?, 2014). Elke computer in het bitcoin netwerk (een zogenaamd knooppunt of node) verzamelt alle onbevestigde transacties in een soort archief (het ‘kandidaat-blok’) (Twesige, 2015). Dit archief bevat verwijzingen zowel naar de nog niet bevestigde transacties als naar het laatst gevalideerde blok waar die computer weet van heeft. Wat daarna gebeurt, is dat de verschillende knooppunten elkaar gaan beconcurreren in de zoektocht naar een hash (een willekeurige code) in dit blok. Ze doen dit door middel van het zogenaamde trial-and-error proces, wat heel wat rekenkracht vergt. De computer die de hash uiteindelijk ontdekt, en daarmee de code van het blok dus kraakt, stuurt deze naar alle overige knooppunten in het netwerk door. Alvorens ze te bevestigen, controleren ook zij de oplossing, en voegen ze het betreffende blok ten slotte aan de blockchain toe. Hoewel geen enkele bitcoin gebruiker ertoe gedwongen wordt zijn identiteit vrij te geven, wordt elke transactie die ooit werd uitgevoerd, opgeslagen in de blockchain. Die database, die voor iedereen 6
toegankelijk is en bij alle knooppunten is opgeslagen, bevat de volledige eigendomsoorsprong van alle bitcoins (of fracties ervan) vanaf het ontstaan van Bitcoin tot en met vandaag. Iemand die dezelfde bitcoins meer dan één keer zou willen uitgeven (double spending) zal op die manier onmiddellijk door het netwerk gedetecteerd worden, dat de tweede, ongeldige transactie prompt zal weigeren Een belangrijke eigenschap van de blockchain is de volledig transparantie. Iedereen kan op elk moment een historische transactie opzoeken. Heel wat diensten bieden dan ook real-time monitoring aan zodat je alle transacties die plaatsvinden ook in real-time kan volgen. 2.1.3 Mining Het bitcoin netwerk creëert en verspreidt ongeveer zes keer per uur een lot met nieuwe bitcoins. Zo’n lot wordt telkens willekeurig toegekend aan een van de bitcoin miners. Het genereren van bitcoins staat bekend als minen. Hoe meer rekenkracht je computer aan het netwerk bijdraagt in verhouding tot de rekenkracht van alle andere computers samen, hoe hoger de kans dat je een lot bitcoins wordt toegewezen. De eerste node die het crypto grafisch probleem van het kandidaat-blok oplost, ontvangt het nieuwe lot bitcoins. De miners kunnen zich via het internet echter ook verenigen en een ‘mining pool’ vormen. De aangesloten miners komen in dat geval overeen de verkregen bitcoins gelijk onder elkaar te verdelen. Een lot bevat nooit meer dan 50 bitcoins. Naarmate de tijd vordert, wordt de beloning voor de miners (het aantal bitcoins per lot) bovendien steeds kleiner, zodat de toename van de geldhoeveelheid perfect voorspelbaar is en uiteindelijk nihil wordt. Nooit zullen er meer dan 21 miljoen bitcoins bestaan. Om te garanderen dat er om de tien minuten een lot bitcoins vrijkomt, bepaalt het bitcoin protocol dat de moeilijkheidsgraad van het op te lossen probleem elke twee weken opnieuw aan de totale rekenkracht van het netwerk wordt aangepast (Wat is bitcoin?, 2014). Vandaag is het ontrafelen van het crypto grafisch raadsel van een kandidaat-blok reeds dermate moeilijk, dat het voor gewone pc-gebruikers al lang niet meer mogelijk is om bitcoins te ontvangen. Omdat de knooppunten in het netwerk niet verplicht zijn om transacties in de blocks die zij genereren op te nemen, kunnen de bitcoin afzenders er geheel vrijwillig voor kiezen een bepaalde transactiekost te betalen. Door dit te doen worden de miners van het netwerk niet alleen gemotiveerd, maar wordt de transactie ook versneld. Bitcoin miners ontvangen steeds het totaal van de vergoedingen voor alle transacties in de blokken die zij hebben opgelost. Deze tarieven zijn slechts een fractie van de verstuurde hoeveelheid bitcoins, zeker als je ze vergelijkt met die van om het even welk ander betalingssysteem. Bij een transactie van 100 bitcoins kan het zijn dat de software een tarief van amper 0,005 bitcoins voorstelt. Wanneer met verloop van tijd de beloning per blok kleiner wordt, zullen transactiekosten een belangrijkere rol gaan spelen. De reden daarvoor is immers dat die voor de miners dan de belangrijkste stimulans zullen gaan worden, aangezien het grootste deel van hun inkomsten niet langer uit het minen, maar uit het totaal aan transactievergoedingen zal komen (Twesige, 2015).
7
2.2 Risico identificatie Binnen het bitcoin betalingsverkeer zijn verschillende risico’s aanwezig. Binnen deze paragraaf zijn de risico’s uiteen gezet. Voor het beschrijven van de risico’s maken we gebruik van het Handboek Risicomanagement van Deloitte. Het biedt organisaties handvatten om een risicomanagement systeem op te zetten en zich richt op het identificeren en kwantificeren van risico’s en het bepalen van activiteiten die de kans van optreden en/of de gevolgen van risico’s beheersbaar houdt. Deloitte ziet risicomanagement als een proces van een systematische analyse van de risico’s waaraan een organisatie bloot staat (Deloitte, 2009). Daarbij horen de verbeteringen als gevolg van het aanpassen van de maatregelen. In het handboek luidt de werkdefinitie van risico als volgt: Risico: de kans op een gebeurtenis met een effect op het behalen van je doelstellingen
In dit handboek maakt Deloitte onderscheid tussen strategische -, tactische – en operationele risico’s. Strategische risico’s zijn risico’s die direct de doelstelling van de organsatie in gevaar kunnen brengen. Dit kan zowel interne als externe oorzaken hebben (Deloitte, 2009). Beheersing van de risico’s vereist een koerswijziging of een wijziging van de doelstellingen. De risico’s zijn dus in het hoogste orgaan binnen een instelling belegd. Tactische risico’s zijn afdeling overstijgende risico’s. Dit betreft bijvoorbeeld het niet voldoen aan wet en regelgeving door een bedrijf. Operationele risico’s zijn risico’s die dagelijks voorkomen. Dit zijn bijvoorbeeld risico’s omtrent het dagelijks beheer van IT systemen. Naast de hierboven beschreven indeling is ook gekeken naar oorzaak- en gevolg categoriën. Door het categoriseren van de oorzaken is het mogelijk om de risico’s met dezelfde oorzaak gezamenlijk te beheersen. In deze paragraaf zijn de risicos geidentificeerd aan de hand van literatuurstudie en gesprek met experts op het gebied van financiele markten, Financial Audit en Risicomanagement. Nadat de risico’s in deze paragraaf zijn geidentificeerd zullen de risico’s vervolgens worden analyseerd in paragraaf 3.2. 2.2.1
Strategische risico’s
Het risico dat het imago van bitcoin schade oploopt vanwege problemen met de volatiliteit. (A01)
Door gebruik te maken van de Bitcoin als waardemiddel loopt de consument het risico om geld te verliezen. Dit heeft verschillende oorzaken. Eén van de belangrijkste risico’s is de hoge volatiliteit van de koers. Het gebruik van een product ontwikkelt zich aan de hand van een bepaalde fasen. In zijn boek Diffusion of Innovations introduceert Rogers de adoptiecurve. Rogers definieert zijn Diffusion of Innovation theorie “[..]as the process by which an innovation is communicated through certain channels over time among the members of a social system”. De adoptie van een product is te visualiseren in een zogenaamde bell curve. De verspreiding van nieuwe ideeën en kennis kent volgens de diffusietheorie van Rogers een algemeen patroon en daarbij wordt de klassieke indeling van vijf adoptiegroepen gebruikt: innovators, early adopters, early majority, late majority en laggards (Rogers, 2003). Deze indeling vormt een fasering en tijdslijn in die verspreiding en de groepsgrootte past grofweg in de bekende normaalverdeling. Elk van de adoptiegroepen bevat zijn eigen karakteristieken. Maar in welke fase zit de Bitcoin nu? De Bitcoin kenmerkt zich als een nieuws gedreven adoptie. Hoe meer er over de Bitcoin wordt gesproken in de media hoe meer mensen deel zullen nemen aan de munt. Dit zorgt voor schaarste en daarmee beperkte liquiditeit.
8
Wanneer de prijzen dalen, stellen mensen hun aankopen uit. En als mensen aankopen uitstellen heeft dit gevolgen voor de investeringen van bedrijven. Dit zorgt weer voor het inzakken van de economie en de toename van faillissementen. Dit maakt mensen bang om meer geld te lenen en de bank om geld uit te lenen. Met als resultaat dat prijzen dalen. Deze beschreven kettingreactie is samengevat de reden waardoor de mondiale economie in de Grote Depressie terecht kwam maar ook de situatie waarin onze huidige economie zich sinds 2008 in verkeerd. Het nadeel aan de Bitcoin is dat de munt aan deflatie onderhevig is. In het ontwerp van de bitcoin is een vooraf bepaald aantal bitcoins gesteld dat alleen zal groeien tegen een laag tarief tot 2040 en daarna zal stoppen. Deze kunstmatige schaarste betekent dat de waarde van een bitcoin aanzienlijk moet gaan stijgen. En daar zit nou precies het probleem van de bitcoin. De volatiliteit van de munt is van een uitzonderlijk hoog niveau (zie figuur 6). Als punt van vergelijking, daalden de prijzen ongeveer 10 procent per jaar tijdens de ergste van de Grote Depressie.
Figuur 6: Koers Bitcoin/USD
Een bitcoin gebruiker dient zich daarom van bewust te zijn dat dat de waarde van virtuele valuta zeer volatiel is waarbij de waarde gemakkelijk kan dalen als stijgen (EBA - Opinion on virtual currencies, 2013). Mocht de populariteit van een virtuele valuta naar beneden gaan, bijvoorbeeld als een andere virtuele valuta steeds populairder wordt, dan is het heel goed mogelijk dat de waarde van de munt daalt. Voor de bitcoin kan derhalve niet worden gegarandeerd dat de waarde van de virtuele valuta stabiel blijft. Daarmee komen we op een belangrijk punt: het kenmerk van een gedecentraliseerde munt kan daarmee een nadeel zijn voor de koers. In het ontwerp van de bitcoin is rekening gehouden met een zelf regulerende munt. Door het ontbreken een centrale macht (bijvoorbeeld de ECB) kunnen geen maatregelen worden getroffen om de koers om inflatie in de hand te houden. Daarbij is er geen garantie voor prijsstabiliteit. Het risico dat het imago van bitcoin schade oploopt vanwege het beperkte gebruik als betaalmiddel (A02) Door het grenzeloze, fraudebestendige karakter en de lage tarieven is de bitcoin een aantrekkelijke betalingsmethode voor consumenten en bedrijven. Sinds de introductie van de bitcoin zijn er steeds meer plaatsen waar de bitcoin wordt geaccepteerd als een geldig betaalmiddel. In Nederland is het mogelijk om via thuisbezorgd.nl eten te bestellen, terwijl via Expedia het mogelijk is om een hotel te boeken. De UATP (Universial Air Travel Plan, een betalingsnetwerk van vliegtuigmaatschappijen zoals
9
British Airways en Lufthansa) heeft in februari 2015 een contract afgesloten met Bitnet (Rosenberg, 2015). Bitnet zal de toekomstige betalingen via bitcoins gaan verzorgen. De acceptatie van virtuele valuta voor de winkels wordt ook niet permanent gegarandeerd. Dit is gebaseerd op basis van vertrouwen in de munt waarbij die kan ophouden op elk moment en zonder opzegtermijn. 2.2.2
Tactische risico’s
Het risico dat de bitcoin niet voldoet aan wet- en regelgeving zoals de geldende regelgeving voor betalingsverkeer (compliance). (B01) Geanonimiseerde betalingen hebben in het verleden grote problemen opgeleverd voor de integriteit van ons financiële stelsel. De ontwikkelingen in het betalingsverkeer gaan snel: er zijn nieuwe bedrijven, nieuwe producten en ook betalen van en naar het buitenland gaat steeds eenvoudiger. Bij het gebruik van virtuele valuta als betaalmiddel wordt de gebruiker niet beschermd door de EU wetgeving (EBA - Opinion on virtual currencies, 2013). De bitcoin wordt door de WFT niet als elektronisch geld gezien. Daarbij is er geen sprake van een vangnetregeling, het depositogarantiestelsel. Ongeautoriseerde of onjuiste incasso's vanaf digitale portemonnee kunnen daarom niet worden teruggedraaid. Het hierboven beschreven risico (B01) is daarmee een gegeven en inherent aan de eigenschappen van de bitcoin. Het risico dat de bitcoin wordt misbruikt door criminele activiteiten. (B02)
De bitcoin is een geschikt middel voor het witwassen van geld of financiering van terrorisme. De Bitcoin is door zijn internationale karakter en het ontbreken van een centraal aanspreekpunt geschikt om anoniem transacties uit te voeren. Transacties in virtuele valuta's zijn openbaar, maar de eigenaars en de ontvangers van deze transacties niet. Daarmee zorgt de bitcoin voor een virtuele valuta met een hoge mate van anonimiteit. Het is dus mogelijk dat het virtuele valuta-netwerk zal worden gebruikt voor transacties in verband met criminele activiteiten, of voor het witwassen van geld. Dit misbruik kan mogelijke gevolgen hebben voor de gebruiker. Bijvoorbeeld wanneer wetshandhavingsinstanties besluiten uitwisselingsplatformen te sluiten. Of wanneer alle rekeningen op een online wallet door de instantie worden bevroren voor verder onderzoek. Innovatieve betaalwijzen als de bitcoin hebben dankzij internet een internationaal bereik en zijn sterk technologisch gedreven. Maar de betaalinstellingen zijn nog onvoldoende toegerust om witwassen met deze producten tegen te gaan of ongebruikelijke transacties te herkennen en te melden. Onlangs is in Nederland een crimineel gearresteerd die met prepaid cards grondstoffen voor drugs had gekocht in China. Zo zijn er meer voorbeelden bekend van criminelen die de zwakke plekken in nieuwe betaalmethodes misbruikten. Dat kan doordat de betaalinstellingen onvoldoende anti-witwas checks hebben ingebouwd om misbruik te herkennen en aan te pakken (DNB, 2012). De Nederlandsche Bank (DNB) benadrukt daarom het belang van voldoende checks op witwassen en terrorismefinanciering (AML/CTF). Daarnaast moeten betaalinstellingen een risico gebaseerde cliëntacceptatieprocedure hebben, zodat zij voldoende kennis verzamelen van de klant en zijn activiteiten. Tot slot verwacht DNB dat betaalinstellingen invulling geven aan hun wettelijke plicht om ongebruikelijke transacties te melden bij de Financial Intelligence Unit (FIU). Ook dit punt is tegenstrijdig met het anonieme karakter van de bitcoin. Het risico (B02) is daarmee een gegeven en inherent aan de eigenschappen van de bitcoin. 10
Het risico dat het betalingsverkeer met bitcoin zorgt voor een onvolledige belastingaangifte. (B03)
De gebruiker dient ervan bewust te zijn dat het houden van virtuele valuta fiscale gevolgen, zoals omzetbelasting, kan hebben (EBA - Opinion on virtual currencies, 2013). De eigenaar dient zelf te overwegen of belastingverplichtingen in zijn of haar land van toepassing zijn bij het gebruik van virtuele valuta. Het verschil in wet- en regelgeving per rechtsgebied kan de gebruiker blootstellen aan extra complexiteit, juridische kwesties en dubbele belastingheffing. 2.2.3
Operationele risico’s
Een ander groot risico wat de Bitcoin bezitter loopt is dat zijn of haar munten verliest of worden gestolen. De cijferreeks die toegang geeft tot de munt wordt door gebruikers fysiek of digitaal opgeslagen. Hierdoor zijn de gebruikers onderhevig aan diefstal (EBA - Opinion on virtual currencies, 2013). Wanneer iemand anders de cijfercombinatie in zijn bezit krijgt heeft hij of zij toegang tot de hoeveelheid bitcoins die de cijfercombinatie vertegenwoordigd. Het is dus voor de gebruiker van groot belang dat de integriteit en continuïteit van de cijfercombinatie is geborgd. Het risico dat de integriteit en beschikbaarheid van de online wallets niet kan worden gegarandeerd. (C01)
Bitcoins kunnen van andere gebruikers worden gekocht of via een uitwisselingsplatform. Deze platforms zijn veelal ongereguleerd. In een aantal gevallen zijn deze exchange sites slachtoffer geweest van hacking door derden. Van alle bitcoin aanbieders is 7% slachtoffer geweest van een DDoS aanval waarvan Mt.Gox 29 keer. Daarbij zijn bitcoin gerelateerde diensten significant vaker slachtoffer dan andere service providers (Vasek et al., 2013). Volgens de EBA kan de consument permanent significante hoeveelheden verliezen van op deze platforms bewaarde geld (EBA - Opinion on virtual currencies, 2013). De gebruiker moet bewust zijn van deze gevaren. Bijvoorbeeld het feit dat de uitwisseling platforms niet hoeven te voldoen aan een minimum controle standaarden op het gebieden van IT beheersing. Daarmee is er geen inzicht in de getroffen beheersmaatregelen die ervoor zouden moeten zorgen dat de integriteit en continuïteit van de opgeslagen bitcoins geborgd is. Het risico dat de integriteit en beschikbaarheid van het exchange platform niet kan worden gegarandeerd. (C02)
Zodra je virtuele valuta hebt gekocht worden deze opgeslagen in een 'digitale portemonnee', op een computer, laptop of smartphone. Digitale portefeuilles hebben een publieke sleutel en een persoonlijke sleutel of het wachtwoord die de gebruiker toelaat om ze te openen. Echter zijn deze digitale portefeuilles niet ongevoelig voor hackers. Net als bij conventionele portefeuilles kan geld worden gestolen uit de portemonnee. Er zijn gevallen bekend van consumenten waarvan meer dan USD 1.000.000 aan virtuele munten zijn gestolen. Wanneer de gebruiker de sleutel van de virtuele valuta verliest heeft de gebruiker geen toegang meer tot zijn of haar bitcoins. Er zijn geen centrale bureaus die wachtwoorden of uitgifte vervanging regelen.
11
2.3 Waarde middelen Om de bitcoin in het perspectief te plaatsen wordt in deze paragraaf een uiteenzetting gedaan van de kenmerken van fiat geld. De kenmerken van dit waarde middel is vergeleken met die van de bitcoin. Daarbij is gekeken welke risico’s en bestaande beheersmaatregelen er al reeds van toepassing zijn. 2.3.1 Betalingsverkeer fiat geld Voor de introductie van geld ruilde men objecten. De transactie bestond uit het uitwisselen van objecten waarbij zelfstandig de waarde ervan werd bepaald. (Boonstra, 2013) Later werd goud als algemeen ruilmiddel gebruikt. Hoeveelheden goud werden gesmolten naar munten. De waarde van een munt was de waarde van de hoeveelheid metaal waaruit hij bestond. Het muntstempel garandeerde dat de munt inderdaad een zeker gewicht aan het betrokken metaal bevatte, zodat weging en controle van het gehalte niet nodig was. Het geld zoals wij nu kennen bevat geen goud of zilver. In zijn boek “Geld speelt (G)een rol. Over de waarde, schepping en vernietiging van geld” geeft Wim Boonstra (chief economist van de Rabobank, Utrecht, en bijzonder hoogleraar Economische en monetaire politiek aan de Vrije Universiteit, Amsterdam) de volgende definitie: “Geld is datgene wat binnen een samenleving algemeen wordt geaccepteerd als ruilmiddel, rekeneenheid en vermogensobject (dat laatste wordt ook wel aangeduid als oppotmiddel)” (Boonstra, 2013). Boonstra beschrijft geld als een afspraak in de samenleving waarbij de waarde wordt gevormd door vertrouwen. “Uiteindelijk is geld, ongeacht de verschijningsvorm, boven alles een afspraak, een belofte van algemene acceptatie binnen een samenleving.” Oorspronkelijk stond op een bankbiljet dat het biljet inwisselbaar was tegen een vaste hoeveelheid goud of zilver, de intrinsieke waarde. De hoeveelheid was afhankelijk van de op het biljet opgedrukte waarde. Een biljet was daarmee inwisselbaar tegen goud of zilver aan toonder en het was niet meer noodzakelijk om het biljet tegen ‘geld’ te verkopen. En in tegenstelling tot obligaties en ander schuldpapier konden deze biljetten te allen tijde ingewisseld worden tegen goud of zilver. Het woord inwisselbaar houdt wel een garantie in op hoeveelheid en te allen tijde. Verkopen daarentegen is afhankelijk van verkrijgbaarheid en marktprijs. In de loop der jaren heeft geld zich dus ontwikkeld naar fiduciair geld; de waarde wordt niet ontleent aan de materie waaruit het gemaakt is maar aan het vertrouwen dat er goederen en diensten mee gekocht kunnen worden. Veelal denken mensen bij 'echt geld' aan briefjes en munten. In werkelijkheid betreft dit maar een klein deel en bestaan bijna alle euro's alleen digitaal. Meer dan 99% van alle euro's in omloop, bestaan enkel als getallen in de computer van een bank. Een euro of dollar kan daarom zowel fysiek als virtueel worden gestolen. Als er nieuwe euro's of dollars worden gecreëerd, worden er geen nieuwe munten geslagen of briefjes gedrukt, maar wordt het saldo van de uitstaande geldvoorraad verhoogt. Door het elektronisch betalen (bijvoorbeeld middel iDeal, creditcard of PayPal) wordt een mutatie uitgevoerd en geld van de ene naar de andere rekening overboekt. Voor het betalingsverkeer maken banken gebruik van het SWIFT netwerk (zie figuur 7). Dit is een carrier voor berichtenverkeer tussen banken. SWIFT bestaat uit SWIFT Gateway (communicatie en security) en SWIFT Alliance (berichtenmodule). SWIFT controleert tevens de transacties op geldigheid. Het uitvoeren van de transactie (middels SWIFT) besteden banken veelal uit aan een payment processor als Equens.
12
Figuur 7: Betalingsverkeer SWIFT netwerk
Bedrijven zoals PayPal, iDeal of Mastercard rekenen een bepaalde opslag om de transactie te beschermen. Dit bedrag is inclusief verantwoording voor bescherming tegen fraude en om voor eventualiteiten zoals klantenservice terugboekingen. Betalingen binnen Nederlandse banken vallen onder de Wet op het financieel toezicht (Wft). Dit regelt het toezicht op financiële instellingen in Nederland. Een belangrijk ander kenmerk van ons hedendaagse monetaire stelsel is dat het wordt gereguleerd door het stelsel van centrale banken. Zij verzorgen de centrale uitgifte van geld en zien er op toe dat inflatie binnen de perken blijft. Daarbij verplichten de centrale banken de deelnemers te voldoen aan wet- en regelgeving. Binnen Nederland wordt toezicht op de Wet Financieel Toezicht en de Bankwet uitgevoerd door DNB. De DNB voert daarbij prudentieel toezicht uit, gericht op de soliditeit van financiële ondernemingen en het bijdragen aan de stabiliteit van de financiële sector. De Wft bevat de in Basel II opgenomen risicogebieden; Governance-, financiële-, juridisch en integriteit-, en operationele en IT-risico’s. 2.3.2 Vergelijking geld met bitcoin Wanneer we de bitcoin vergelijken met geld zijn er een aantal verschillen. Het grootste verschil tussen de bitcoin en andere valuta is dat de bitcoin niet wordt beheerd, uitgegeven, bestuurd of anderszins onder de macht of controle valt van een bank, bedrijf, of overheid. De bitcoin is daarnaast ook niet gebonden aan een bepaald land of regio, maar wereldwijd toepasbaar. Een andere groot verschil is dat, ten opzichte van de meeste andere valuta, de bitcoin niet onbeperkt kan worden 'gedrukt'. Er is een beperkte hoeveelheid bitcoins wereldwijd. Het totaal aantal bitcoins zal nooit meer dan 21 miljoen zal bedragen. Dit aantal wordt bepaald door een geometrische reeks. Zodra de limiet van 21 miljoen bitcoins nadert, zal de bitcoin economie naar alle waarschijnlijkheid in deflatie gaan. Een aantasting van de koopkracht van de bitcoin via manipulatie van de hoeveelheid in omloop zijnde bitcoins, wordt daardoor onmogelijk gemaakt. Dat wil zeggen dat, naarmate het proces vordert, de koopkracht van elke bitcoin geleidelijk aan zal toenemen om uiteindelijk te stabiliseren. Door het gebruik van cryptografie is een bitcoin transactie vele malen veiliger dan een transactie tussen traditionele bankrekeningen. Daarnaast is de bitcoin broncode volledig transparant. Deze broncode is zodanig ontworpen dat eventuele tekortkomingen (‘gaten’) in de toekomst kunnen worden gedicht met een verbetering om zo de veiligheid van het systeem te garanderen.
13
Bitcoin heeft ook andere voordelen ten opzichte van de overheid uitgegeven fiat valuta. De kosten voor transactieverwerking zijn aanzienlijk lager dan die van credit card bedrijven. Bitcoin transacties zijn, in tegenstelling tot credit card transacties, niet omkeerbaar en worden niet beschermd door een instantie. Verschillende start-up bedrijven zijn momenteel methoden aan het ontwikkelen om meer bescherming aan particulieren te bieden en zo de transacties te beschermen. Daarnaast rekenen bedrijven zoals Western Union of MoneyGram een opslag voor overschrijvingen. Het overschrijven van rijke- naar ontwikkelingslanden wordt door de bitcoin vergemakkelijkt. De bitcoin client stuurt elke transactie naar het dichtstbijzijnde knooppunt waarna het over het netwerk wordt verspreid. Ongeldige transacties zullen worden afgewezen door de andere gebruikers in het netwerk. Het uitvoeren van een transactie is gratis, echter zal de transactie worden versneld als de gebruiker de transacties vergoed. De ‘miners’ zullen daardoor de transactie voorrang geven, wat de afwikkeling van de transactie zal versnellen.
3 Analyse toepasbaarheid SOC2 richtlijn Om te toetsen of de hierboven beschreven risico’s binnen het bitcoin betalingsverkeer kunnen worden gemitigeerd is een analyse uitgevoerd. Tijdens deze analyse is gekeken of er middels een raamwerk van IT controledoelstellingen de risico’s kunnen worden afgedekt. De fundering van het raamwerk bestaat uit de bestaande SOC2 controle standaarden. Als eerste wordt een uiteenzetting gedaan van de zoals in het SOC2 raamwerk beschreven trust principles. Vervolgens wordt gekeken of door middel van de trust principles een geschikt raamwerk kan worden opgesteld om de geformuleerde risico’s af te dekken.
3.1
Trust principles
Waar in Nederland de internationale ISAE3402 standaard wordt gebruikt door de NBA en NOREA heeft de Amerikaanse organisatie van beroep auditors (AICPA) een nieuwe standaard opgesteld: Service Organization Control (SOC). De SOC is onder andere gebaseerd op de ISAE3402 en SSAE16 standaard maar is in 3 verschillende vormen verkrijgbaar met elk zijn eigen toepasbaarheid (AICPA, 2010). Voor onze analyse van risico’s omtrent het bitcoin betalingsverkeer richten wij ons op de SOC2 richtlijn. Dit bevat een vaste scope van gedefinieerde beheersingsdoelstellingen met betrekking tot security, confidentiality, availability, processing en privacy. Dit maakt deze standaard breed toepasbaar voor IT gerelateerde processen. In deze paragraaf zullen de principles uiteen worden gezet. 3.1.1 Security Het Security-principle helpt ervoor te zorgen dat het systeem beveiligd is tegen ongeautoriseerde toegang, gebruik of aanpassing. Het beperken van toegang tot het systeem biedt bescherming tegen mogelijk misbruik van het systeem, diefstal van middelen, verkeerd gebruik van software, en oneigenlijke toegang tot, of gebruik, wijzigen, vernietigen of openbaar maken van informatie (Beek, 2014). Belangrijke elementen voor de bescherming van het systeem zijn het op basis van relevante behoeften toestaan van geautoriseerde toegang en het voorkomen van ongeautoriseerde toegang tot het systeem in alle andere gevallen. De Security-criteria zijn relatief consistent met de vereisten uit andere beveiligingsraamwerken zoals ISO 27002. Wanneer de serviceorganisatie al een beveiligingsprogramma heeft op basis van een standaard zoals ISO 27002, of wanneer zij in het verleden al een SOC 1-rapport heeft opgesteld, kunnen veel van de criteria al door de serviceorganisatie zijn uitgewerkt. 3.1.2 Availability Beschikbaarheid bouwt voort op de criteria uit het Security-principle. Availability verwijst naar de toegankelijkheid van het systeem, producten of diensten zoals opgenomen in een contract, service level 14
agreement of andere overeenkomsten. Opgemerkt dient te worden dat deze doelstelling geen minimaal acceptabel prestatieniveau voor de beschikbaarheid van de installatie beschrijft (Beek, 2014). Het minimale prestatieniveau wordt tussen de serviceorganisatie en de gebruikersorganisatie vastgesteld door middel van onderlinge toezeggingen in het contract of de service level overeenkomst. 3.1.3 Processing Integrity De doelstelling Processing Integrity heeft betrekking op de volledigheid, geldigheid, juistheid, tijdigheid en de autorisatie van systeemverwerking (Beek, 2014): • • • •
• •
Integriteit van verwerking ontstaat wanneer een systeem zijn beoogde functie op een onaangetaste manier kan uitvoeren, vrij van ongeoorloofde of onbedoelde manipulatie; Volledigheid duidt erop dat zonder uitzondering alle transacties worden verwerkt dan wel alle diensten worden verricht; Geldigheid betekent dat transacties en diensten niet meer dan eenmaal worden verwerkt en dat zij in overeenstemming zijn met de zakelijke waarden en verwachtingen; Juistheid betekent dat belangrijke informatie in verband met de ingediende transactie accuraat blijft gedurende de verwerking van de transactie en dat de transactie of de dienst wordt verwerkt of uitgevoerd zoals bedoeld; Tijdigheid van de dienstverlening of de levering van goederen gaat over de context van de toezeggingen die gedaan zijn met betrekking tot de levering van de diensten of goederen; Autorisatie betekent dat de verwerking wordt uitgevoerd in overeenstemming met de vereiste goedkeuringen en rechten die zijn vastgelegd in het beleid met betrekking tot de systeemverwerking.
Een risico dat verbonden is aan de integriteit van systeemverwerking is dat gegevens al fouten bevatten voordat zij door het systeem worden verwerkt. In deze gevallen kunnen data ongeldig, onjuist of anderszins ongeschikt zijn hoewel de systeemverwerking integer is. Ter voorkoming van misinterpretaties moet het rapport duidelijk aangeven welke integriteitsverantwoordelijkheden buiten de scope vallen. Bijvoorbeeld in een paragraaf ‘gebruikers verantwoordelijkheden’ (Beek, 2014). 3.1.4 Confidentiality Het principle Confidentiality verwijst naar het vermogen van het systeem om de als vertrouwelijk aangemerkte informatie te beschermen zoals vastgelegd of als overeengekomen in het contract tussen serviceorganisatie en de gebruikersorganisatie. In tegenstelling tot persoonlijke informatie, die is gedefinieerd in plaatselijk geldende wettelijke regelgeving, is er geen algemeen erkende definitie voor vertrouwelijke informatie. Welke informatie als vertrouwelijk wordt gedefinieerd moet door de organisatie zelf worden bepaald (Beek, 2014). Om zaken te kunnen doen wisselen zakenpartners informatie uit. Zakenpartners willen dat dit op een vertrouwelijke manier gebeurt. De informatie die zij verstrekken mag alleen beschikbaar zijn voor personen die de informatie nodig hebben om de transactie te voltooien of om eventuele vragen over de transactieverwerking te kunnen beantwoorden. Deze eis leidt ertoe dat deze informatie als vertrouwelijk wordt geclassificeerd. Voorbeelden van vertrouwelijke informatie zijn transactiegegevens, technische tekeningen, bedrijfsplannen, bancaire informatie, intellectuele eigendom, informatie over beschikbare voorraden, bied- of laatprijzen, prijslijsten, juridische documenten, klantlijsten en opbrengsten per klant en per branche. Welke informatie beschouwd wordt als vertrouwelijk kan van organisatie tot organisatie sterk verschillen en wordt bepaald door contractuele afspraken of regelgeving. Het is belangrijk om te weten 15
welke informatie in het systeem als vertrouwelijk wordt gezien en op basis waarvan, indien noodzakelijk, toegang tot deze data wordt verstrekt. Op basis daarvan kan worden bepaald waarop de vertrouwelijkheidscriteria betrekking moeten hebben. 3.1.5 Privacy Het Privacy principle richt zich op de bescherming van persoonlijke informatie die organisaties kunnen verzamelen over hun klanten, medewerkers of andere personen. De TSP verwijzen voor het Privacyprinciple naar de GAPP van het AICPA (AICPA, 2010). GAPP biedt een raamwerk voor complexe privacy-eisen. Privacy is in GAPP gedefinieerd als de rechten en plichten van individuen en organisaties met betrekking tot het verzamelen, gebruiken, bewaren, openbaar maken en vernietigen van persoonlijke informatie. GAPP is een Amerikaans raamwerk en is niet van toepassing voor Nederland. Nederlandse privacy regels zijn gebaseerd op Europese wet- en regelgeving en worden uitgegeven door het College Bescherming Persoonsgegevens. Zij corresponderen niet met het Amerikaanse GAPP-raamwerk. De in de TSP opgenomen privacy criteria zijn daardoor van beperkte waarde voor gebruik in Nederland en de overige landen in de EU.
3.2
Risico analyse
In paragraaf 2.2 is een risico identificatie uitgevoerd op het crypto grafische betalingsverkeer. Resultaat hiervan is een lijst met omschreven risico’s. Deze risico’s zijn opgedeeld in drie deelgebieden: strategische risico’s, tactische risico’s en operationele risico’s. Vervolgens zijn voor elke laag voorbeelden van risico’s beschreven die van toepassing zouden kunnen zijn op de bitcoin dienst. Om meer inzicht in de risico’s te krijgen en om te kijken of de trust principles de risico’s kunnen mitigeren zijn de risico’s geanalyseerd (zie Appendix A). Om de subjectiviteit van de inschatting van een risico te beperken is het gebruik van een degelijke risicoanalyse methode van belang. Met het gebruik van een adequate methode kan de subjectiviteit van de inschatting van een risico worden beperkt en onderbouwd. Voor het analyseren van de geïdentificeerde risico’s wordt in deze scriptie gebruik gemaakt van de FOCUS risicoanalysemethode. Op basis van de risicoanalysemethode FOCUS houdt DNB van iedere onder haar toezicht staande onderneming systematisch een risicoprofiel bij (DNB, 2012). Risicoanalyse wordt door DNB gebruikt om inzicht te krijgen in de risico's die samenhangen met de activiteiten die een onderneming uitvoert en de mate waarin deze een potentiële bedreiging kunnen vormen voor de toezichtdoelstellingen. Door de risico's en de beheersing te scoren worden risico's, beheersing, activiteiten en instellingen onderling gerangschikt, waarmee input wordt geleverd voor een zo efficiënt mogelijke allocatie van schaarse toezichtcapaciteit.
16
Figuur 8: Stappenplan FOCUS risicoanalyse (DNB, 2012)
Door middel van de FOCUS risicoanalyse methode kunnen de IT risico’s van een instelling in beeld worden gebracht. Daarom is de methode geschikt voor het analyseren van de risico’s omtrent het betalingsverkeer van virtuele munten. Binnen de methode wordt uitgegaan van de 4 A’s van Westerman (DNB, 2012):
Availability: Beschikbaarheid van het informatiesysteem; Access: Toegang tot informatie is beperkt tot geautoriseerde personen; Accuracy: Juistheid, tijdigheid en volledigheid van informatie; Agility: Het doorvoeren van veranderingen middels acceptabele kosten.
Binnen de FOCUS methode worden de 4 A’s beoordeeld aan de hand van scenario’s. Bij elk scenario wordt gekeken naar de volgende stappen: 1) IT gerelateerd gebeurtenis; 2) Impact; 3) Relevante COBIT beheersmaatregelen om het risico te mitigeren. In deze scriptie is onderzocht of de SOC2 richtlijn kan helpen de risico’s in het virtuele betalingsverkeer te mitigeren. Derhalve wordt er bij stap 3 niet gekeken naar relevante COBIT beheersmaatregelen maar naar de SOC trust principles. Per voorbeeld wordt, aan de hand van de trust principles en de FOCUS methode, bepaald of het risico kan worden afgedekt door middel van een SOC2 normenkader. Omdat niet alle risico’s beheerst hoeven worden is er gekeken naar de kansen en gevolgen van de verschillende risico’s. Om de risico’s te mitigeren dienen beheersmaatregelen te worden geïmplementeerd. Beheersmaatregelen kunnen gericht zijn op de oorzaken of op de gevolgen van een gebeurtenis. Een maatregel op de oorzaak zorgt voor het verminderen van de kans dat een gebeurtenis optreedt. Aan de hand van het FOCUS stappenplan zijn de geïdentificeerde risico’s beoordeeld met gebruik van de volgende stappen (zie figuur 8): Risico identificatie (1), Risico beoordeling (2), Risico mitigatie (3).
17
3.2.1
Strategische risico’s
Identificatie Tijdens de risico identificatie zijn de volgende strategische risico’s reeds geïdentificeerd: (1) Imagorisico: Het risico dat het imago van bitcoin schade oploopt vanwege problemen met de volatiliteit (A01); (2) Imagorisico: Het risico dat het imago van bitcoin schade oploopt vanwege het beperkte gebruik als betaalmiddel (A02). Beoordeling Beide risico’s zijn reputatie risico’s en hebben te maken met de 3 A’s: availability, access en accuracy. Wanneer een derde partij (in dit geval exchange website of online wallet) door de gebruiker als vertrouwelijk wordt gezien zal deze eerder overgaan tot het gebruik van de geleverde dienst. (Changsu, Wang, Namchul, & Ki-Soo, 2010). Het is dus van belang voor de bitcoin om de hierboven beschreven risico’s te mitigeren. Deze risico’s zijn afhankelijk van verschillende factoren en vormen de publieke opinie over de bitcoin. Wanneer de bitcoin als vertrouwelijk wordt gezien zal de munt door meer mensen worden gebruikt als betaalmiddel. Het wordt algemeen aangenomen dat een goede beveiliging het vertrouwen van de consument verbetert en uiteindelijk zal toenemen in het gebruik van de bitcoin. De perceptie van de beveiliging van het bitcoin betalingsverkeer is daarmee een belangrijke factor in de ontwikkeling van het product. Door middel van een SOC2 normenkader kan inzicht worden gegeven in de beschikbaarheid en integriteit van de exchange platforms en online wallets. Dit kan er voor zorgen dat de gebruiker meer vertrouwen krijgt in het betalingsverkeer van de bitcoin wat kan leiden tot een stabielere koers en wijdere acceptatie. Mitigatie Aan de hand van de hierboven beschreven risicoanalyse kunnen we stellen dat meerdere trust principles bij kunnen dragen in het vertrouwen in de munt en daarmee het reputatierisico van de bitcoin kunnen mitigeren. De risico’s kunnen worden afgedekt door de principles Security, Availability en Processing integrity. Door de veiligheid van het betalingsverkeer te garanderen tegen ongeautoriseerde (fysieke en logische) toegang kan zekerheid worden gegeven dat de door de consument gebruikte bitcoins adequaat zijn beveiligd. Het tweede belangrijke trust principle is Availability. Door de consument de beschikbaarheid van het betalingsverkeer en daarmee de toegang tot de opgeslagen munten te garanderen, is de gebruiker minder wantrouwig voor koersdalingen. Bij mogelijke koersdaling kan de gebruiker toegang krijgen tot zijn of haar munten en deze direct verhandelen. In hoofdstuk 2.1 is de bitcoin beschreven als een cryptografische valuta waarbij de werking niet afhankelijk is van een centrale instelling maar van een gedistribueerde database. Deze blockchain technologie is zeer complex maar heeft als belangrijkste eigenschap dat het modificatie van gegevens onmogelijk maakt. Om deze eigenschap te verifiëren is het principle Processing integrity van belang. Hiermee kan worden getoetst of de gegevensverwerking compleet, accuraat, tijdig en geautoriseerd verloopt.
18
3.2.2
Tactische risico’s
Identificatie Tijdens de risico identificatie zijn de volgende tactische risico’s reeds geïdentificeerd: (3) Compliance risico: Het risico dat de bitcoin niet voldoet aan wet- en regelgeving zoals de geldende regelgeving voor betalingsverkeer (B01); (4) Compliance risico: Het risico dat de bitcoin wordt misbruikt door criminele activiteiten (B02); (5) Compliance risico: Het risico dat het betalingsverkeer met bitcoins zorgt voor een onvolledige belastingaangifte (B03). Beoordeling De 3 hierboven beschreven risico’s zijn compliance, integriteit en reputatie risico’s. Ze hebben impact op de 3 A’s: availability, access en accuracy. In Nederland ziet DNB toe op de beheerste bedrijfsvoeren en uitbesteding van financiële instellingen. De effectiviteit van de organisatie inrichting, procedures en maatregelen wordt intern onafhankelijk getoetst. De financiële onderneming voorziet erin dat de gesignaleerde tekortkoming worden opgeheven. Daarbij wordt ook gekeken op de naleving van wettelijke regels en interne regels. Wanneer de bitcoin niet voldoet aan de geldende wet- en regelgeving voor betalingsverkeer is dat een belemmering in de stap naar een geaccepteerd betaalmiddel. Wanneer de bitcoin wordt misbruikt door criminele activiteiten en onvolledige belastingaangifte schaadt dit de reputatie van de munt. Zolang de bitcoin een anoniem karakter blijft houden blijft de munt een geschikt middel voor het witwassen van geld of financiering van terrorisme. Daarnaast heeft de belastingdienst, door het gebrek aan transparantie, geen zicht op de mogelijk te heffen omzetbelasting op bitcoin eigenaren. Mitigatie Het compliance risico kan worden afgedekt door de principles Security, Availability en Processing Integrity. Door het afgeven van een SOC2 Assurance rapport kan een exchange platform of online wallet aantonen dat zij in control zijn over de processen in scope. Met een Assurance verklaring kan aan instanties als DNB en de klant zekerheid worden gegeven over de getroffen interne beheersmaatregelen en daarmee de integriteit en beschikbaarheid de gegevensverwerking. De twee risico’s omtrent het misbruik van de bitcoin kunnen niet door het normenkader worden afgedekt. Beide risico’s hebben te maken met het anonieme karakter van de bitcoin gebruiker. Dit is een grondbeginsel van de munt en zit daarmee ook verweven in het technische ontwerp. Het SOC2 normenkader kan zich daardoor niet richten op de transparantie van de bitcoin gebruiker. Het kan wel helpen de online wallets en exchange platforms transparanter te maken. 3.2.3
Operationele risico’s
Identificatie Tijdens de risico identificatie zijn de volgende operationele risico’s reeds geïdentificeerd: (6) Beveiligingsrisico: Het risico dat de integriteit en beschikbaarheid van de online wallets niet kan worden gegarandeerd (C01); (7) Beveiligingsrisico: Het risico dat de integriteit en beschikbaarheid van het exchange platform niet kan worden gegarandeerd (C02).
19
Beoordeling De geïdentificeerde operationele risico’s zijn afhankelijk van een adequate risicobeheersing van de IT diensten rondom de bitcoin. Ze hebben impact op de 3 A’s: Availability, Access en Accuracy. Om de hierboven beschreven risico’s uiteen te zetten is, op basis van het raamwerk Beveiliging Web applicaties van het NCSC (Nationaal Cyber Security Centrum, 2010), een categorisering aangebracht van de mogelijke onderliggende risico’s (zie figuur 9).
Figuur 9: Raamwerk Beveiliging Web applicaties (Nationaal Cyber Security Centrum, 2010)
1. 2. 3.
4. 5. 6.
Netwerkbeveiliging: Dit is een beschikbaarheidsrisico. Het risico dat het netwerk overbelast raakt en de beschikbaarheid van de applicatie in gevaar komt; Platformbeveiliging: Dit is een beschikbaarheidsrisico. Het risico dat de beschikbaarheid van de applicatie in gevaar komt door het niet installeren van patches; Applicatiebeveiliging: Voor het beschrijven van dit risico wordt gebruik gemaakt van de OWASP top 10. OWASP, een non-profit organisatie met als doel het verbeteren beveiliging van web applicaties, maakt jaarlijks een top-10 van de grootste bedreigingen voor web applicaties(Nationaal Cyber Security Centrum, 2010); Injection; Cross Site Scripting (XSS); Broken Authentication and Session Management; Insecure Direct Object References; Cross Site Request Forgery (CSRF); Security Misconfiguration; Failure to Restrict URL Access; Unvalidated Redirects and Forwards; Insecure Cryptographic Storage; Insufficient Transport Layer Protection. Identiteitsbeheer: Het risico dat een gebruiker verkeerd wordt geïdentificeerd door de applicatie; Toegangsbeheer: Het risico dat onbevoegden zich toegang kunnen verschaffen tot gegevens van anderen; Vertrouwelijkheid en onweerlegbaarheid: Dit betreft 2 verschillende risico’s. Allereerst een vertrouwelijkheidsrisico. Het risico dat de gegevens door onbevoegden kunnen worden ingezien. Daarnaast een aansprakelijkheidsrisico. Het risico dat het niet onweerlegbaar is wie welke acties heeft uitgevoerd binnen de applicatie.
20
Mitigatie Voor deze risico’s is het SOC2 normenkader een geschikt middel om de getroffen beheermaatregelen te toetsen. Door het toetsten van de trust principles kan inzicht worden gekregen in de getroffen beheersmaatregelen van het IT diensten van de bitcoin. Door middel van de principles Security en Availability kunnen de netwerk-, platform- en applicatiebeveiliging en de beschikbaarheid van de diensten worden getoetst op de effectiviteit van de beheersmaatregelen.
3.3
Opstellen van geschikt normenkader
Voor een consistente structuur van SOC2 Assurance rapportages heeft de AICPA een set van criteria gedefinieerd voor elk principle (AICPA, 2010). Deze criteria zijn beheersingsdoelstellingen die gebruikt worden voor presentatie en toelichting; criteria zijn ook de doelstellingen die gebruikt worden om het te beheersen proces te evalueren of te meten. Aan elk van de criteria moet door de serviceorganisatie worden voldaan door een beheersingsmaatregel of set van beheersingsmaatregelen. De keuze voor de beheersingsmaatregelen per criterium, de formulering ervan en de vaststelling van het aantal zijn de verantwoordelijkheid van het management van de serviceorganisatie en afhankelijk van factoren zoals managementstijl, filosofie, grootte en branche. De AICPA heeft de criteria voorzien van een illustratieve lijst van risico’s en beheersingsmaatregelen die voor de serviceorganisatie als voorbeeld kunnen dienen. Wanneer een principle is geselecteerd voor de scope van het SOC-rapport, dan moet aan alle criteria voor dat principle worden voldaan door middel van effectieve beheersingsmaatregelen bij de serviceorganisatie. Als een criterium niet van toepassing is, moet dit worden vermeld in de systeembeschrijving (bijvoorbeeld door op te nemen waarom dit criterium niet geschikt is voor het systeem). Door middel van een fit/gap analyse van de criteria van de trust principles is gekeken waarin de SOC2 normen kunnen helpen de gesignaleerde risico’s af te dekken (zie Appendix B). Wanneer een risico kan worden afgedekt middels de SOC2 normen is gekeken of een ander model (COSO, COBIT) beheersmaatregelen biedt om de openstaande risico’s te mitigeren. Deze analyse is vastgelegd in Appendix B. Uit de analyse van het SOC2 normenkader kunnen we concluderen dat de in paragraaf 4.2 beschreven risico’s met de voorgedefinieerde beheersmaatregelen kunnen worden afgedekt. Derhalve hoeft het normenkader niet te worden aangevuld met andere beheersmaatregelen.
3.4
Validatie
In de ‘Share’ fase is gekeken naar de uiteindelijke toepasbaarheid van het opgestelde normenkader. Om de uitkomst van de analyse te valideren is het normenkader besproken met betrokken personen binnen IT Audit praktijk waarbij is gekeken naar de herkenbaarheid van het ontwikkelde normenkader. Deze afstemming had de vorm van een validatie van het normenkader. Dit geeft antwoord op de derde deelvraag: Welk raamwerk kan worden gebruikt als basis om zekerheid te verschaffen aan exchange en wallet websites in het betalingsverkeer van virtuele munten? Tijdens deze validatie is gesproken met experts op het gebied van financiële markten en de SOC2 richtlijn. Dit betreffen meerdere collega’s uit het IT audit vakgebied. Aan de hand van de verkregen feedback uit deze ‘Share’ fase zijn er aanpassingen gemaakt op de toepasbaarheid van de trust principles. Het SOC2 normenkader wordt gezien als een middel om de getroffen beheersmaatregelen te toetsen. Echter betreft het normenkader gestandaardiseerde criteria die mogelijk niet aansluiten op de behoefte van de klant én de inrichting van de organisatie. Het advies is daarom voorafgaand aan een opdracht te onderzoeken of het SOC2 normenkader voldoende aansluit op het uiteindelijke doel: voldoende inzicht krijgen in de interne controleomgeving van de bitcoin 21
dienst. Indien het SOC2 normenkader niet toepasbaar is kan men besluiten om een alternatieve Assurance standaard (bijvoorbeeld de ISAE3402) te hanteren.
4. Conclusie Per onderzocht aspect zijn de deelvragen beantwoord op basis van waarnemingen en bevindingen. In dit hoofdstuk zijn de antwoorden op de deelvragen geaggregeert om zo tot onze conclusie te komen op de hoofdvraag van ons onderzoek. Tevens is hierbij aandacht besteed aan de relevantie en consequenties van de onderzoeksuitkomsten voor het IT-audit vakgebied.
4.1
Beantwoording deelvragen
In deze paragraaf zijn de antwoorden opgenomen op de deelvragen zoals deze zijn geformuleerd in hoofdstuk Deelvraag 1: Wat is de bitcoin? Deelvraag 2: Wat zijn de risico’s van het bitcoin betalingsverkeer? Het gebruiken van de bitcoin als betaalmiddel brengt voor de gebruiker verschillende risico’s met zich mee. In hoofdstuk 2 van deze scriptie zijn de risico’s uiteengezet. De risico’s zijn opgedeeld in drie deelgebieden: strategische risico’s, tactische risico’s en operationele risico’s. Binnen het bitcoin betalingsverkeer zijn er op elk van deze niveaus risico’s aanwezig. De strategische risico’s bepalen de uiteindelijke toekomst van de bitcoin. Een munt die dagelijks extreem van waarde kan veranderen zal niet snel worden geaccepteerd als betaalmiddel. Doordat de consument de bitcoin een beperkt aantal plekken als betaalmiddel kan gebruiken zorgt er voor dat minder mensen de bitcoin als een betaalmiddel zullen gaan zien. Zo blijft de bitcoin in deze vicieuze cirkel. Een van de belangrijkste kenmerken van de bitcoin is de anonimiteit. Vanuit het oogpunt van tactische risico’s kunnen we stellen dat de bitcoin nadeel kan ondervinden van deze anonimiteit wanneer het als betaalmiddel wordt geaccepteerd. Het risico bestaat dat het gebruik van bitcoin als vermogen niet voldoet aan wet- en regelgeving. Er is daarmee een compliance risico. De bitcoin kan worden gebruikt voor criminele activiteiten en het gebrek aan transparantie zorgt voor problemen bij de belastingaangifte. Voor een gebruiker van de bitcoin is het van belang dat de integriteit en beschikbaarheid van de online wallets en exchange platforms kan worden gegarandeerd. De opgeslagen bitcoins moeten veilig worden bewaard en worden beveiligd tegen derden. Daarnaast dient de bitcoin bezitten te allen tijde te beschikken over de bitcoin. Bij mogelijke koerswijzigingen kan de gebruiker daarbij direct zijn bitcoin inwisselen voor fiat geld en vice versa. De meerderheid van de risico’s zijn vergelijkbaar met de risico’s in het fiat betalingsverkeer. Ook in het reguliere betaalproces kan het geld van de consument worden gestolen door bijvoorbeeld een cyber attack op de bank. Een groot verschil met de exchanges en wallets van de bitcoin is dat deze banken (uitgifte plaatsen) zijn onderworpen aan een set van regels en controles. Elke bank staat onder toezicht van een nationale bank en wordt periodiek getoetst of zij wel aan bepaalde regels en eisen voldoen. Op deze manier wordt de veiligheid van de door de consument opgeslagen geld gegarandeerd. Deelvraag 3: Welk raamwerk kan worden gebruikt als basis om zekerheid te verschaffen aan exchange en wallet websites in het betalingsverkeer van virtuele munten?
22
In hoofdstuk 3 is gekeken of het AICPA SOC2 normenkader de gesignaleerde risico’s rondom exchange en wallet websites in het betalingsverkeer kan mitigeren. Tijdens de analyse is geconcludeerd dat niet alle risico’s kunnen worden afgedekt. Het normenkader is enkel van toepassing op bepaalde schakels in de gehele keten van het bitcoin betalingsverkeer, namelijk de exchange en wallet diensten. We kunnen concluderen dat de SOC2 richtlijn is gericht op operationele risico’s binnen deze diensten maar geen zekerheid aan de gehele keten kan geven. Het normenkader kan helpen de operationele risico’s rondom de integriteit en beschikbaarheid van de exchange diensten en wallets te mitigeren. Het implementeren van de controls rondom de trust principles Security, Availability, Processing Integrity en Confidentiality kan er voor zorgen dat er redelijke mate van zekerheid kan worden gekregen over de beschikbaarheid en integriteit van de bitcoin binnen exchange en wallet diensten. Daarmee hebben ze impact op de strategische risico’s. Een belangrijke beperking in de toepasbaarheid van het normenkader is het anonieme karakter van de bitcoin gebruiker. Dit is een grondbeginsel van de munt en zit daarmee ook verweven in het technische ontwerp. Het principle privacy is daarmee niet van toepassing; het SOC2 normenkader kan zich niet richten op de transparantie van de bitcoin gebruiker. Het kan wel helpen de online wallets en exchange platforms transparanter te maken.
4.2
Beantwoording hoofdvraag
De hoofdvraag die centraal staat in dit onderzoek is de volgende: Op welke gebieden kan zekerheid worden gegeven aan de exchange en wallet websites binnen het betalingsverkeer van virtuele munten? Sinds de introductie van de bitcoin wordt de munt vooral gebruikt als speculatie instrument. De bitcoin heeft nog geen belangrijke rol als betaalmiddel gespeeld en is daarmee hooguit een aanvulling op fiat geld. Dat neemt niet weg dat sommigen in een korte tijd een fortuin hebben verdiend door op het juiste moment in- en uit te stappen waarbij anderen hebben forse verliezen geleden door mee te doen met de hype. En dat is voor speculanten aantrekkelijk. Op basis van de geformuleerde antwoorden op de onderzochte deelvragen komen wij tot de conclusie dat het AICPA SOC2 raamwerk bij kan dragen aan de adoptie van de bitcoin. Hier zijn drie condities voor benodigd. Allereerst heeft de munt behoefte aan vertrouwen. De bitcoin wordt gekenmerkt door volatiliteit, complexiteit, operationele issues. Daarnaast wordt de gebruiker niet beschermd door een centrale instelling. Een tweede conditie is stabiliteit. Volatiliteit moet worden ingeperkt. De koers blijft heel instabiel, wat schadelijk is voor het noodzakelijke vertrouwen in een betaalmiddel. Pas na deze stabiliteit zullen er meer mensen en winkels gebruik gaan maken van de bitcoin. Een derde punt is acceptatie. De bitcoin is onderhevig aan een beperkte acceptatie van winkels. Daarnaast wordt de bitcoin ook niet door financiële instellingen geaccepteerd. Het SOC2 normenkader kan bijdragen aan het mitigeren van de operationele risico’s. Door middel van het implementeren en het uitvoeren van een readiness assessment van de SOC2 trust principles en bijbehorende criteria kan zekerheid worden verkregen over integriteit en de beschikbaarheid van exchange websites en online wallets. Dit is een drie-stappenplan waarbij allereerst de trust principles worden geselecteerd en de criteria worden geïmplementeerd in de IT organisatie. Tijdens een readiness assessment kunnen de getroffen beheersmaatregelen worden getoetst en de tekortkomingen worden blootgelegd. Tijdens het remediation proces kunnen de tekortkomingen worden opgevolgd waarna de finale audit uitgevoerd kan worden.
23
Door zekerheid te bieden op de principles van Security en Availability kan de beschikbaarheid en integriteit van de bitcoin dienst worden aangegeven. Het Security-principle helpt ervoor te zorgen dat het systeem beveiligd is tegen ongeautoriseerde toegang en biedt daarmee bescherming tot tegen mogelijk misbruik van het systeem, diefstal van middelen, verkeerd gebruik van software, en oneigenlijke toegang tot, of gebruik, wijzigen, vernietigen of openbaar maken van informatie. Availability verwijst naar de toegankelijkheid van het systeem, producten of diensten zoals opgenomen in een contract, service level agreement of andere overeenkomsten. Dit geeft de gebruiker vertrouwen in de beschikbaarheid van de geleverde dienst. De doelstelling Processing Integrity heeft betrekking op de volledigheid, geldigheid, juistheid, tijdigheid en de autorisatie van systeemverwerking. Het principle Privacy botst met één van de belangrijkste karakteristieken uit het bitcoin ontwerp. Het anonieme karakter van de bitcoin gebruiker is een grondbeginsel van de munt en zit daarmee ook verweven in het technische ontwerp. Het SOC2 normenkader is daarmee niet toepasbaar om de getroffen beheersmaatregelen in het kader van privacy in kaart te brengen. Een belangrijke beperking van het gebruik van de trust principles criteria is het generieke karakter ervan. De beheersmaatregelen bestaan uit generieke criteria en zijn daarom niet specifiek toepasbaar op het wisseldiensten van virtuele munten. Daarmee kunnen we concluderen dat het SOC2 normenkader te generiek is om een oordeel te kunnen vellen over de getroffen beheersmaatregelen van een organisatie. Wel kan het als basis dienen voor de wijze van IT huishouding. In januari 2015 heeft bitcoin-beheerder Elliptic een ISAE3402 Assurance rapportage ontvangen van KPMG (Accountant.nl, 2015). Met de Assurance rapportage wil Elliptic laten zien dat de bitcoins van klanten veilig zijn bij het bedrijf. ISAE 3402 is een internationale standaard voor procesbeheersing. In Nederland is dit veel gebruikt door financiële bedrijven die delen van hun kernactiviteiten hebben uitbesteed. Via een ISAE 3402 Assurance rapporage laten zij zien dat zij de uitbestede processen toch beheersen en dermate veilig zijn. Tijdens het onderzoek heeft KPMG onderzoek gedaan naar financieel toezicht, compliance en andere processen die te maken hebben met veiligheid. "KPMG's accreditation is an important milestone", aldus bestuursvoorzitter James Smith van Elliptic. "It demonstrates to our customers that we have the rigorous internal processes and controls expected of any traditional financial services provider." Een kritische noot hierbij is dat, in tegenstelling tot SOC2, bij een ISAE3402 normenkader geen voor gedefinieerd normenkader van toepassing is. Het is dus van belang om de feitelijke inhoud van de rapportage te analyseren voordat kan worden bepaald of Elliptic zijn processen goed op orde heeft. Concluderend kunnen we stellen dat de bitcoin technologie een kansrijke toekomst voor zich heeft maar dat de munt als geaccepteerd betaalmiddel gevaar loopt op verschillende niveaus. Het SOC2 normenkader kan, zowel op strategisch, tactisch als operationeel niveau, helpen deze risico’s te mitigeren. Door middel van het normenkader kan inzicht worden gegeven in de beschikbaarheid en integriteit van de exchange platforms en online wallets. Transparantie in de getroffen beheersmaatregelen kan ervoor zorgen dat de gebruiker meer vertrouwen krijgt in het betalingsverkeer van de bitcoin, wat kan leiden tot een stabielere koers en wijdere acceptatie. Daarnaast kan het beschikken over een SOC2 normenkader ook transparantie bieden aan toezichthoudende instanties als DNB. Wanneer de bitcoin niet voldoet aan de geldende wet- en regelgeving voor betalingsverkeer is dat namelijk een belemmering in de stap naar een accepteert betaalmiddel. Door deze risico’s af te dekken kan meer vertrouwen worden gegeven in de integriteit en beschikbaarheid van de bitcoin diensten. Een andere manier is om de bitcoin diensten onder te brengen bij gevestigde financiële instellingen. Jon Matonis, executive director van de bitcoin foundation stelt dat:
24
“There was no reason that the major banks couldn’t tap into the growing demand for the peer-topeer crypto-currency. [..] There are opportunities for the banks to become Bitcoin exchanges or to set-up trusted e-wallets. There is no reason these need to be run by teenagers in their basements. There is no history of trust and this somewhere banks certainly have an advantage. The trust business is the banking business” (Accountant.nl, 2015).
Doordat banken al aan toezicht zijn onderworpen dienen zij te voldoen aan minimale standaarden op het gebied van de trust principles. Daarnaast is de techniek van de blockchain een interessante toevoeging op het huidige betalingsverkeer. De Zwitserse bank UBS doet onderzoek hoe de technologie achter bitcoins ingezet kan worden voor het aanbieden van financiële diensten.
4.3
Reflectie
Tijdens de afrondende fase werd de schrijver verrast door het bericht dat KPMG een Assurance verklaring op een bitcoin dienst heeft afgegeven. Dit benadrukt de relevantie en de actualiteit van het onderwerp. Na mijn literatuurstudie en gesprekken met medewerkers van DNB en Deloitte ben steeds meer gefascineerd geraakt van het onderwerp. De bitcoin is een fantastische uitvinding waarbij ik verwacht dat de bitcoin en/of de achterliggende technologie een belangrijke toekomstige rol gaat spelen in ons betalingsverkeer. De technologie biedt zoveel voordelen dat ook grote bedrijven als IBM en UBS onderzoek doen naar de toepasbaarheid van de blockchain.
4.4
Nader onderzoek
Een belangrijke vraag die overblijft, is hoe we het anonieme karakter van de bitcoin kunnen rijmen met de behoefte naar transparantie van de toezichthouder. Op dit moment is, vanwege de anonimiteit, de bitcoin het ideale betaalmiddel voor criminelen. Daarnaast heeft de belastingdienst geen zicht op het vermogen in virtuele munten. Dit vraagstuk kan een obstakel vormen in de toekomstige acceptatie en volwassenheid van de munt. Het is daarom interessant om een aanvullend onderzoek uit te voeren wat antwoord geeft op de vraag hoe de bitcoin zijn anonieme karakter kan behouden maar toch kan voldoen aan de (betalingsverkeer) eisen van de centrale banken.
25
Bibliografie Accountant.nl. (2015, januari 21). KPMG accrediteert Engels bitcoin-beheerder. Opgehaald van Accountant.nl: http://www.accountant.nl/Accountant/Nieuws/KPMG+accrediteert+Engelse+bitcoinbeheerder. aspx AICPA. (2010, November). Service Organization Controls: Management Risks by Obtaining a Service Auditor's report. New York, NY, United States of America. Beek, J. v. (2014). Assurance rapporten voor IT-service organisaties . Praktijkgids 5, 40. Boonstra, W. (2013). Geld speelt (G)een rol. Over de waarde, schepping en vernietiging van geld. Amsterdam: VU uitgeverij. Changsu, K., Wang, T., Namchul, S., & Ki-Soo, K. (2010). An empirical study of customers’ perceptions of security and trust in e-payment systems. Electronic Commerce Research and Applications, 8495. Deloitte. (2009). Risicomanagement: meer dan de som der delen. Utrecht: MCBD. DNB. (2012, April). DNB.nl. Opgehaald van FOCUS! de vernieuwde toezichtaanpak van DNB: http://www.dnb.nl/binaries/Focus_tcm46-271614.pdf EBA - Opinion on virtual currencies. (2013, December 13). Opgehaald van European banking authority: https://www.eba.europa.eu/ ISACA. (2007). COBIT framework 4.1. ISACA. (2009). The Risk IT Framework. Illinois. ISACA. (2014). ITAF Information Technology Assurance Framework. Illinois. ISO. (2009). ISO 31000:2009 - Risk Management: Principles and Guidelines. Moore, T., & Christin, N. (2013). Beware of the Middleman: Empirical Analysis of Bitcoin-Exchange Risk. Financial Cryptografy and Data Security, 25-33. Nakamoto, S. (2013). Bitcoin: A peer-to-peer Electronic Cash System. www.bitcoin.org, 9. Opgehaald van Bitcoin: Open source P2P money: www.bitcoin.org Nationaal Cyber Security Centrum. (2010). Raamwerk Beveiliging voor Webapplicaties. Den Haag: Ministerie van Veiligheid en Justitie. Nederlands Adviesbureau Risicomanagement. (2013, oktober). Handboek Risicomanagement. Nederland. NOREA. (2002). Studierapport 3: Raamwerk voor ontwikkeling normenstelsels en standaarden. Nederlandse Orde van Register EDP-Auditors. Rael, R. (2009). Recession-Proof Risk Management Strategies: A primer for Business and Industry. Smart Risk Management: A Guide to Identifying and Reducing Everyday Business Risks. Rogers, E. M. (2003). Diffusion of innovations. New York: Free Press.
26
Rosenberg, S. (2015, January 13). There is a blockchain for that. Opgehaald van Blockchannel: https://medium.com/blockchannel Siemerink, L. (2007). De overeenkomst van Internet Service Providers met consumenten. Kluwer. Twesige, R. L. (2015, januari). Bitcoin: A simple explanation of Bitcoin and Block Chain technology. Opgehaald van www.academia.edu: https://www.academia.edu/9986472/Bitcoin_A_simple_explanation_of_Bitcoin_and_Block_Ch ain_technology Vasek, M., Thornton, M., & Moore, T. (2013). Empirical Analysis of Denial-of-Service Attacks in the Bitcoin Ecosystem. Financial Cryptograpghy and Data Security, 57-71. Wat is bitcoin? (2014). Opgehaald van de Bitcoin: http://debitcoin.org/wat-is-bitcoin/ Yin, R. K. (2013). Case study research: design and methods. Thousand Oaks: SAGE Publications.
27
Bijlagen Appendix A: Analyse toepasbaarheid SOC2 principles op geïdentificeerde risico’s
A0-1
Het risico dat het imago van bitcoin schade oploopt vanwege problemen met de volatiliteit.
2
A0-2
Het risico dat het imago van bitcoin schade oploopt vanwege het beperkte gebruik als betaalmiddel.
3
B0-1
Het risico dat de bitcoin niet voldoet aan wet- en regelgeving zoals de geldende regelgeving voor betalingsverkeer (compliance).
4
B0-2
Het risico dat de bitcoin wordt misbruikt door criminele activiteiten.
5
B0-3
Het risico dat het betalingsverkeer met bitcoins zorgt voor een onvolledige belastingaangifte.
6
C0-1
Het risico dat de integriteit en beschikbaarheid van de online wallets niet kan worden gegarandeerd.
7
C0-2
Het risico dat de integriteit en beschikbaarheid van het exchange platform niet kan worden gegarandeerd.
Ja
√
√
√
Ja
Ja
√
√
√
√
Ja
√
√
√
√
Ja
√
√
√
√
Nee
Nee
Privacy
1
SOC2
Confidentiality
Beschrijving
Processing Integrity
Norm
Availability
#
Security
De onderstaande analyse is een schematische weergave van de risico analyse zoals beschreven in paragraaf 3.2. Per geïdentificeerd risico is onderzocht welk trust principle van toepassing is.
Appendix B: Analyse Normenkader SOC2 Appendix B: Analyse Normenkader SOC2 De onderstaande analyse is een weergave op de toepasbaarheid van het SOC2 normenkader zoals beschreven in paragraaf 3.3. Per trust principle is gekeken of de voor gedefinieerde controlebeschrijvingen voldoende toepasbaar zijn om de geïdentificeerde risico’s te mitigeren. Norm toepasbaar voor bitcoin normenkader Norm niet toepasbaar voor bitcoin normenkader
Trust Principle
Control Area #
Controle doelstelling
Control #
Control beschrijving
Analyse
Security
S1
S 1.1
The entity’s security policies are established and periodically reviewed and approved by a designated individual or group.
Security
S1
Policies: The entity defines and documents its policies for the security of its system. Policies: The entity defines and documents its policies for the security of its system.
S 1.2
Security
S1
Policies: The entity defines and documents its policies for the security of its system.
S 1.3
The entity’s security policies include, but may not be limited to, the following matters: a. Identifying and documenting the security requirements of authorized users b. Classifying data based on its criticality and sensitivity and that classification is used to define protection requirements, access rights and access restrictions, and retention and destruction requirements c. Assessing risks on a periodic basis d. Preventing unauthorized access e. Adding new users, modifying the access levels of existing users, and removing users who no longer need access f. Assigning responsibility and accountability for system security g. Assigning responsibility and accountability for system changes and maintenance h. Testing, evaluating, and authorizing system components before implementation i. Addressing how complaints and requests relating to security issues are resolved j. Identifying and mitigating security breaches and other incidents k. Providing for training and other resources to support its system security policies l. Providing for the handling of exceptions and situations not specifically addressed in its system security policies m. Providing for the identification of and consistency with applicable laws and regulations, defined commitments, service-level agreements, and other contractual requirements n. Providing for sharing information with third parties Responsibility and accountability for developing and maintaining the entity’s system security policies, and changes and updates to those policies, are assigned.
29
Appendix B: Analyse Normenkader SOC2 Security
S2
Security
S2
Security
S2
Security
S2
Security
S2
Security
S3
Security
S3
Communications: The entity communicates its defined system security policies to responsible parties and authorized users. Communications: The entity communicates its defined system security policies to responsible parties and authorized users. Communications: The entity communicates its defined system security policies to responsible parties and authorized users. Communications: The entity communicates its defined system security policies to responsible parties and authorized users. Communications: The entity communicates its defined system security policies to responsible parties and authorized users. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies.
S 2.1
The entity has prepared an objective description of the system and its boundaries and communicated such description to authorized users.
S 2.2
The security obligations of users and the entity’s security commitments to users are communicated to authorized users.
S 2.3
Responsibility and accountability for the entity’s system security policies and changes and updates to those policies are communicated to entity personnel responsible for implementing them.
S 2.4
The process for informing the entity about breaches of the system security and for submitting complaints is communicated to authorized users.
S 2.5
Changes that may affect system security are communicated to management and users who will be affected
S 3.1
Procedures exist to (1) identify potential threats of disruption to systems operation that would impair system security commitments and (2) assess the risks associated with the identified threats.
S 3.2
Procedures exist to restrict logical access to the defined system including, but not limited to, the following matters: a. Logical access security measures to restrict access to information resources not deemed to be public. b. Identification and authentication of users. c. Registration and authorization of new users. d. The process to make changes and updates to user profiles. e. Distribution of output restricted to authorized users. f. Restriction of access to offline storage, backup data, systems, and media. g. Restriction of access to system configurations, superuser functionality, master passwords, powerful utilities, and security devices (for example, firewalls).
30
Appendix B: Analyse Normenkader SOC2 Security
S3
Security
S3
Security
S3
Security
S3
Security
S3
Security
S3
Security
S3
Security
S3
Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies.
S 3.3
Procedures exist to restrict physical access to the defined system including, but not limited to, facilities, backup media, and other system components such as firewalls, routers, and servers.
S 3.4
Procedures exist to protect against unauthorized access to system resources.
S 3.5
Procedures exist to protect against infection by computer viruses, malicious code, and unauthorized software.
S 3.6
Encryption or other equivalent security techniques are used to protect user authentication information and the corresponding session transmitted over the Internet or other public networks.
S 3.7
Procedures exist to identify, report, and act upon system security breaches and other incidents.
S 3.8
Procedures exist to classify data in accordance with classification policies and periodically monitor and update such classifications as necessary
S 3.9
Procedures exist to provide that issues of noncompliance with security policies are promptly addressed and that corrective measures are taken on a timely basis.
S 3.10
Design, acquisition, implementation, configuration, modification, and management of infrastructure and software are consistent with defined system security policies to enable authorized access and to prevent unauthorized access.
31
Appendix B: Analyse Normenkader SOC2 Security
S3
Security
S3
Security
S3
Security
S3
Security
S4
Security
S4
Security
S4
Availability
A1
Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system security objectives in accordance with its defined policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system security policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system security policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system security policies. Policies: The entity defines and documents its policies for the availability of its system.
S 3.11
Procedures exist to provide that personnel responsible for the design, development, implementation, and operation of systems affecting security have the qualifications and resources to fulfill their responsibilities.
S 3.12
Procedures exist to maintain system components, including configurations consistent with the defined system security policies.
S 3.13
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.
S 3.14
Procedures exist to provide that emergency changes are documented and authorized timely.
S 4.1
The entity’s system security is periodically reviewed and compared with the defined system security policies.
S 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its defined system security policies
S 4.3
Environmental, regulatory, and technological changes are monitored and their effect on system security is assessed on a timely basis and policies are updated for that assessment.
A 1.1
The entity’s system availability and related security policies are established and periodically reviewed and approved by a designated individual or group.
32
Appendix B: Analyse Normenkader SOC2 Availability
A1
Policies: The entity defines and documents its policies for the availability of its system.
A 1.2
The entity’s system availability and related security policies include, but may not be limited to, the following matters: a. Identifying and documenting the system availability and related security requirements of authorized users. b. Classifying data based on its criticality and sensitivity and that classification is used to define protection requirements, access rights and access restrictions, and retention and destruction requirements c. Assessing risks on a periodic basis d. Preventing unauthorized access. e. Adding new users, modifying the access levels of existing users, and removing users who no longer need access. f. Assigning responsibility and accountability for system availability and related security. g. Assigning responsibility and accountability for system changes and maintenance. h. Testing, evaluating, and authorizing system components before implementation. i. Addressing how complaints and requests relating to system availability and related security issues are resolved. j. Identifying and mitigating system availability and related security breaches and other incidents. k. Providing for training and other resources to support its system availability and related security policies. l. Providing for the handling of exceptions and situations not specifically addressed in its system availability and related security policies. m. Providing for the identification of and consistency with, applicable laws and regulations, defined commitments, service-level agreements, and other contractual requirements. n. Recovering and continuing service in accordance with documented customer commitments or other agreements. o. Monitoring system capacity to achieve customer commitments or other agreements regarding availability
Availability
A1
Policies: The entity defines and documents its policies for the availability of its system.
A 1.3
Responsibility and accountability for developing and maintaining the entity’s system availability and related security policies, and changes and updates to those policies, are assigned.
Availability
A2
A 2.1
The entity has prepared an objective description of the system and its boundaries and communicated such description to authorized users
Availability
A2
A 2.2
A2
The availability and related security obligations of users and the entity’s availability and related security commitments to users are communicated to authorized users. Responsibility and accountability for the entity’s system availability and related security policies and changes and updates to those policies are communicated to entity personnel responsible for implementing them.
Availability
Policies: The entity defines and documents its policies for the availability of its system. Policies: The entity defines and documents its policies for the availability of its system. Policies: The entity defines and documents its policies for the availability of its system.
A 2.3
33
Appendix B: Analyse Normenkader SOC2 Availability
A2
Availability
A2
Availability
A3
Availability
A3
Availability
A3
Availability
A3
Availability
A3
Availability
A3
The process for informing the entity about system availability issues and breaches of system security and for submitting complaints is communicated to authorized users. Changes that may affect system availability and system security are communicated to management and users who will be affected.
A 3.1
Procedures exist to (1) identify potential threats of disruptions to systems operation that would impair system availability commitments and (2) assess the risks associated with the identified threats.
A 3.2
Measures to prevent or mitigate threats have been implemented consistent with the risk assessment when commercially practicable.
A 3.3
Procedures exist to provide for backup, offsite storage, restoration, and disaster recovery consistent with the entity’s defined system availability and related security policies
A 3.4
Procedures exist to provide for the integrity of backup data and systems maintained to support the entity’s defined system availability and related security policies
A 3.5
Procedures exist to restrict logical access to the defined system including, but not limited to, the following matters: a. Logical access security measures to restrict access to information resources not deemed to be public. b. Identification and authentication of users. c. Registration and authorization of new users. d. The process to make changes and updates to user profiles. e. Restriction of access to offline storage, backup data, systems and media. f. Restriction of access to system configurations, superuser functionality, master passwords, powerful utilities, and security devices (for example, firewalls).
A 3.6
Procedures exist to restrict physical access to the defined system including, but not limited to, facilities, backup media, and other system components such as firewalls, routers, and servers.
Policies: The entity defines and documents its policies for the availability of its system. Policies: The entity defines and documents its policies for the availability of its system. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies.
A 2.4
Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies.
A 2.5
34
Appendix B: Analyse Normenkader SOC2 Availability
A3
Availability
A3
Availability
A3
Availability
A3
Availability
A3
Availability
A3
Availability
A3
Availability
A3
Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies.
A 3.7
Procedures exist to protect against unauthorized access to system resources.
A 3.8
Procedures exist to protect against infection by computer viruses, malicious codes, and unauthorized software.
A 3.9
Encryption or other equivalent security techniques are used to protect user authentication information and the corresponding session transmitted over the Internet or other public networks.
A 3.10
Procedures exist to identify, report, and act upon system availability issues and related security breaches and other incidents.
A 3.11
Procedures exist to classify data in accordance with classification policies and periodically monitor and update such classifications as necessary.
A 3.12
Procedures exist to provide that issues of noncompliance with system availability and related security policies are promptly addressed and that corrective measures are taken on a timely basis.
A 3.13
Design, acquisition, implementation, configuration, modification, and management of infrastructure and software are consistent with defined system availability and related security policies
A 3.14
Procedures exist to provide that personnel responsible for the design, development, implementation, and operation of systems affecting availability and security have the qualifications and resources to fulfill their responsibilities.
35
Appendix B: Analyse Normenkader SOC2 Availability
A3
Availability
A3
Availability
A3
Availability
A4
Availability
A4
Availability
A4
Processing Integrity
I1
Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system availability objectives in accordance with its defined policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system availability policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system availability policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system availability policies. Policies: The entity defines and documents its policies for the processing integrity of its system.
A 3.15
Procedures exist to maintain system components, including configurations consistent with the defined system availability and related security policies.
A 3.16
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.
A 3.17
Procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval).
A 4.1
The entity’s system availability and security performance is periodically reviewed and compared with the defined system availability and related security policies.
A 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its defined system availability and related security policies.
A 4.3
Environmental, regulatory, and technological changes are monitored, and their effect on system availability and security is assessed on a timely basis; policies are updated for that assessment.
I 1.1
The entity’s processing integrity and related security policies are established and periodically reviewed and approved by a designated individual or group
36
Appendix B: Analyse Normenkader SOC2 Processing Integrity
I1
Policies: The entity defines and documents its policies for the processing integrity of its system.
I 1.2
Processing Integrity
I1
Policies: The entity defines and documents its policies for the processing integrity of its system.
I 1.3
The entity’s system processing integrity and related security policies include, but may not be limited to, the following matters: a. Identifying and documenting the system processing integrity and related security requirements of authorized users b. Classifying data based on their criticality and sensitivity; that classification is used to define protection requirements, access rights and access restrictions, and retention and destruction requirements c. Assessing risks on a periodic basis d. Preventing unauthorized access e. Adding new users, modifying the access levels of existing users, and removing users who no longer need access f. Assigning responsibility and accountability for system processing integrity and related security g. Assigning responsibility and accountability for system changes and maintenance h. Testing, evaluating, and authorizing system components before implementation i. Addressing how complaints and requests relating to system processing integrity and related security issues are resolved j. Identifying and mitigating errors and omissions and other system processing integrity and related security breaches and other incidents k. Providing for training and other resources to support its system processing integrity and related system security policies l. Providing for the handling of exceptions and situations not specifically addressed in its system processing integrity and related system security policies m. Providing for the identification of and consistency with applicable laws and regulations, defined commitments, service-level agreements, and other contractual requirements Responsibility and accountability for developing and maintaining entity’s system processing integrity and related system security policies; changes, updates, and exceptions to those policies are assigned.
37
Appendix B: Analyse Normenkader SOC2 Processing Integrity
I2
Communications: The entity communicates its documented system processing integrity policies to responsible parties and authorized users.
I 2.1
The entity has prepared an objective description of the system and its boundaries and communicated such description to authorized users. If the system is an e-commerce system, additional information provided on its website includes, but may not be limited to, the following matters: a. Descriptive information about the nature of the goods or services that will be provided, including, where appropriate, i. condition of goods (whether they are new, used, or reconditioned). ii. description of services (or service contract). iii. sources of information (where it was obtained and how it was compiled). b. The terms and conditions by which it conducts its e-commerce transactions including, but not limited to, the following matters: i. Time frame for completion of transactions (transaction means fulfillment of orders where goods are being sold and delivery of service where a service is being provided) ii. Time frame and process for informing customers of exceptions to normal processing of orders or service requests iii. Normal method of delivery of goods or services, including customer options, where applicable iv. Payment terms, including customer options, if any v. Electronic settlement practices and related charges to customers vi. How customers may cancel recurring charges, if any vii. Product return policies and limited liability, where applicable c. Where customers can obtain warranty, repair service, and support related to the goods and services purchased on its website. d. Procedures for resolution of issues regarding processing integrity. These may relate to any part of a customer’s e-commerce transaction, including complaints related to the quality of services and products, accuracy, completeness, and the consequences for failure to resolve such complaints.
Processing Integrity
I2
Communications: The entity communicates its documented system processing integrity policies to responsible parties and authorized users.
I 2.2
The processing integrity and related security obligations of users and the entity’s processing integrity and related security commitments to users are communicated to authorized users.
Processing Integrity
I2
Communications: The entity communicates its documented system processing integrity policies to responsible parties and authorized users.
I 2.3
Responsibility and accountability for the entity’s system processing integrity and related security policies, and changes and updates to those policies, are communicated to entity personnel responsible for implementing them.
Processing Integrity
I2
Communications: The entity communicates its documented system processing integrity policies to responsible parties and authorized users.
I 2.4
The process for obtaining support and informing the entity about system processing integrity issues, errors and omissions, and breaches of systems security and for submitting complaints is communicated to authorized users.
38
Appendix B: Analyse Normenkader SOC2 Processing Integrity
I2
Communications: The entity communicates its documented system processing integrity policies to responsible parties and authorized users.
I 2.5
Changes that may affect system processing integrity and system security are communicated to management and users who will be affected.
Processing Integrity
I3
I 3.1
Procedures exist to (1) identify potential threats of disruptions to systems operations that would impair processing integrity commitments and (2) assess the risks associated with the identified threats.
Processing Integrity
I3
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies.
I 3.2
Processing Integrity
I3
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies.
I 3.3
Processing Integrity
I3
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies.
I 3.4
The procedures related to completeness, accuracy, timeliness, and authorization of inputs are consistent with the documented system processing integrity policies. If the system is an e-commerce system, the entity’s procedures include, but may not be limited to, the following matters: a. The entity checks each request or transaction for accuracy and completeness. b. Positive acknowledgment is received from the customer before the transaction is processed. The procedures related to completeness, accuracy, timeliness, and authorization of system processing, including error correction and database management, are consistent with documented system processing integrity policies. If the system is an e-commerce system, the entity’s procedures include, but are not necessarily limited to, the following matters: a. The correct goods are shipped in the correct quantities in the time frame agreed upon, or services and information are provided to the customer as requested. b. Transaction exceptions are promptly communicated to the customer. c. Incoming messages are processed and delivered accurately and completely to the correct IP address. d. Outgoing messages are processed and delivered accurately and completely to the service provider's (SP’s) Internet access point. e. Messages remain intact while in transit within the confines of the SP’s network. The procedures related to completeness, accuracy, timeliness, and authorization of outputs are consistent with the documented system processing integrity policies. If the system is an e-commerce system, the entity’s procedures include, but are not necessarily limited to, the following matters: • The entity displays sales prices and all other costs and fees to the customer before processing the transaction. • Transactions are billed and electronically settled as agreed. • Billing or settlement errors are promptly corrected.
39
Appendix B: Analyse Normenkader SOC2 Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies.
I 3.5
There are procedures to enable tracing of information inputs from their source to their final disposition and vice versa.
I 3.6
Procedures exist to restrict logical access to the defined system including, but not limited to, the following matters: a. Logical access security measures to access information not deemed to be public b. Identification and authentication of authorized users c. Registration and authorization of new users d. The process to make changes and updates to user profiles e. Distribution of output restricted to authorized users f. Restriction of access to offline storage, backup data, systems, and media g. Restriction of access to system configurations, superuser functionality, master passwords, powerful utilities, and security devices (for example, firewalls)
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies.
I 3.7
Procedures exist to restrict physical access to the defined system including, but not limited to, facilities, offline storage media, backup media and systems, and other system components such as firewalls, routers, and servers
I 3.8
Procedures exist to protect against unauthorized access to system resources
I 3.9
Procedures exist to protect against infection by computer viruses, malicious code, and unauthorized software
I 3.10
Encryption or other equivalent security techniques are used to protect user authentication information and the corresponding session transmitted over the Internet or other public networks.
I 3.11
Procedures exist to identify, report, and act upon system processing integrity issues and related security breaches and other incidents.
40
Appendix B: Analyse Normenkader SOC2 Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I3
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies.
I 3.12
Procedures exist to classify data in accordance with classification policies and periodically monitor and update such classifications as necessary
I 3.13
Procedures exist to provide that issues of noncompliance with system processing integrity and related security policies are promptly addressed and that corrective measures are taken on a timely basis.
I 3.14
Design, acquisition, implementation, configuration, modification, and management of infrastructure and software are consistent with defined processing integrity and related security policies.
I 3.15
Procedures exist to provide that personnel responsible for the design, development, implementation, and operation of systems affecting processing integrity and security have qualifications and resources to fulfill their responsibilities.
I 3.16
Procedures exist to maintain system components, including configurations consistent with the defined system processing integrity and related security policies
I 3.17
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.
I 3.18
Procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval).
I 3.19
Procedures exist to protect the system against potential risks (for example, environmental risks, natural disasters, and routine operational errors and omissions) that might impair system processing integrity.
41
Appendix B: Analyse Normenkader SOC2 Processing Integrity
I3
Processing Integrity
I3
Processing Integrity
I4
Processing Integrity
I4
Processing Integrity
I4
Confidentiality
C1
Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system processing integrity objectives in accordance with its defined policies. Monitoring: The entity monitors the system and takes action to maintain compliance with the defined system processing integrity policies. Monitoring: The entity monitors the system and takes action to maintain compliance with the defined system processing integrity policies. Monitoring: The entity monitors the system and takes action to maintain compliance with the defined system processing integrity policies. Policies: The entity defines and documents its policies related to the system protecting confidential information, as committed or agreed.
I 3.20
Procedures exist to provide for restoration and disaster recovery consistent with the entity’s defined processing integrity policies.
I 3.21
Procedures exist to provide for the completeness, accuracy, and timeliness of backup data and systems
I 4.1
System processing integrity and security performance are periodically reviewed and compared with the defined system processing integrity and related security policies.
I 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its defined system processing integrity and related security policies.
I 4.3
Environmental, regulatory, and technological changes are monitored, their impact on system processing integrity and security is assessed on a timely basis, and policies are updated for that assessment
C 1.1
The entity’s system confidentiality and related security policies are established and periodically reviewed and approved by a designated individual or group.
42
Appendix B: Analyse Normenkader SOC2 Confidentiality
C1
Policies: The entity defines and documents its policies related to the system protecting confidential information, as committed or agreed.
C 1.2
Confidentiality
C1
Policies: The entity defines and documents its policies related to the system protecting confidential information, as committed or agreed.
C 1.3
Confidentiality
C2
Communications: The entity communicates its defined policies related to the system’s protection of confidential information to responsible parties and authorized users.
C 2.1
The entity's policies related to the system’s protection of confidential information and security include, but are not limited to, the following matters: a. Identifying and documenting the confidentiality and related security requirements of authorized users b. Classifying data based on its criticality and sensitivity that is used to define protection requirements, access rights and access restrictions, and retention and destruction requirements c. Assessing risk on a periodic basis d. Preventing unauthorized access e. Adding new users, modifying the access levels of existing users, and removing users who no longer need access f. Assigning responsibility and accountability for confidentiality and related security g. Assigning responsibility and accountability for system changes and maintenance h. Testing, evaluating, and authorizing system components before implementation i. Addressing how complaints and requests relating to confidentiality and related security issues are resolved j. Handling confidentiality and related security breaches and other incidents k. Providing for training and other resources to support its system confidentiality and related security policies l. Providing for the handling of exceptions and situations not specifically addressed in its system confidentiality and related security policies m. Providing for the identification of and consistency with, applicable laws and regulations, defined commitments, service-level agreements, and other contractual requirements n. Sharing information with third parties Responsibility and accountability for developing and maintaining the entity’s system confidentiality and related security policies, and changes and updates to those polices, are assigned.
The entity has prepared an objective description of the system and its boundaries and communicated such description to authorized users.
43
Appendix B: Analyse Normenkader SOC2 The system confidentiality and related security obligations of users and the entity’s confidentiality and related security commitments to users are communicated to authorized users before the confidential information is provided. This communication includes, but is not limited to, the following matters: a. How information is designated as confidential and ceases to be confidential. The handling, destruction, maintenance, storage, back-up, and distribution or transmission of confidential information. b. How access to confidential information is authorized and how such authorization is rescinded. c. How confidential information is used. d. How confidential information is shared. e. If information is provided to third parties, disclosures include any limitations on reliance on the third party’s confidentiality practices and controls. Lack of such disclosure indicates that the entity is relying on the third party’s confidentiality practices and controls that meet or exceed those of the entity. f. Practices to comply with applicable laws and regulations addressing confidentiality. Responsibility and accountability for the entity’s system confidentiality and related security policies and changes and updates to those policies are communicated to entity personnel responsible for implementing them.
C 2.4
The process for informing the entity about breaches of confidentiality and system security and for submitting complaints is communicated to authorized users.
C 2.5
Changes that may affect confidentiality and system security are communicated to management and users who will be affected.
C 3.1
Procedures exist to (1) identify potential threats of disruptions to systems operations that would impair system confidentiality commitments and (2) assess the risks associated with the identified threats.
C 3.2
The system procedures related to confidentiality of inputs are consistent with the documented confidentiality policies.
Confidentiality
C2
Communications: The entity communicates its defined policies related to the system’s protection of confidential information to responsible parties and authorized users.
C 2.2
Confidentiality
C2
C 2.3
Confidentiality
C2
Confidentiality
C2
Confidentiality
C3
Confidentiality
C3
Communications: The entity communicates its defined policies related to the system’s protection of confidential information to responsible parties and authorized users. Communications: The entity communicates its defined policies related to the system’s protection of confidential information to responsible parties and authorized users. Communications: The entity communicates its defined policies related to the system’s protection of confidential information to responsible parties and authorized users. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies.
44
Appendix B: Analyse Normenkader SOC2 Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies.
C 3.3
The system procedures related to confidentiality of data processing are consistent with the documented confidentiality policies.
C 3.4
The system procedures related to confidentiality of outputs are consistent with the documented confidentiality policies
C 3.5
The system procedures provide that confidential information is disclosed to parties only in accordance with the entity’s defined confidentiality and related security policies.
C 3.6
The entity has procedures to obtain assurance or representation that the confidentiality policies of third parties to whom information is transferred and upon which the entity relies are in conformity with the entity’s defined system confidentiality and related security policies and that the third party is in compliance with its policies.
C 3.7
In the event that a disclosed confidentiality practice is discontinued or changed to be less restrictive, the entity has procedures to protect confidential information in accordance with the system confidentiality practices in place when such information was received, or obtains customer consent to follow the new confidentiality practice with respect to the customer’s confidential information
45
Appendix B: Analyse Normenkader SOC2 Confidentiality
C3
Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies.
C 3.8
Procedures exist to restrict logical access to the system and the confidential information resources maintained in the system including, but not limited to, the following matters: a. Logical access security measures to restrict access to information resources not deemed to be public b. Identification and authentication of all users. c. Registration and authorization of new users. d. The process to make changes and updates to user profiles. e. Procedures to prevent customers, groups of individuals, or other entities from accessing confidential information other than their own. f. Procedures to limit access to confidential information to only authorized employees based upon their assigned roles and responsibilities. g. Distribution of output containing confidential information restricted to authorized users. h. Restriction of access to offline storage, backup data, systems, and media. i. Restriction of access to system configurations, superuser functionality, master passwords, powerful utilities, and security devices (for example, firewalls).
Confidentiality
C3
C 3.9
Procedures exist to restrict physical access to the defined system including, but not limited to, facilities, backup media, and other system components such as firewalls, routers, and servers.
Confidentiality
C3
C 3.10
Procedures exist to protect against unauthorized access to system resources.
Confidentiality
C3
C 3.11
Procedures exist to protect against infection by computer viruses, malicious code, and unauthorized software.
Confidentiality
C3
C 3.12
Encryption or other equivalent security techniques are used to protect transmissions of user authentication and other confidential information passed over the Internet or other public networks.
Confidentiality
C3
Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies.
C 3.13
Procedures exist to identify, report, and act upon system confidentiality and security breaches and other incidents.
46
Appendix B: Analyse Normenkader SOC2 Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C3
Confidentiality
C4
Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Procedures: The entity placed in operation procedures to achieve its documented system confidentiality objectives in accordance with its defined policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined confidentiality policies.
C 3.14
Procedures exist to provide that system data are classified in accordance with the defined confidentiality and related security policies
C 3.15
Procedures exist to provide that issues of noncompliance with defined confidentiality and related security policies are promptly addressed and that corrective measures are taken on a timely basis.
C 3.16
Design, acquisition, implementation, configuration, modification, and management of infrastructure and software are consistent with defined confidentiality and related security policies.
C 3.17
Procedures exist to help ensure that personnel responsible for the design, development, implementation, and operation of systems affecting confidentiality and security have the qualifications and resources to fulfill their responsibilities
C 3.18
Procedures exist to maintain system components, including configurations consistent with the defined system confidentiality and related security policies
C 3.19
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.
C 3.20
Procedures exist to provide that confidential information is protected during the system development, testing, and change processes in accordance with defined system confidentiality and related security policies
C 4.1
The entity’s system confidentiality and security performance is periodically reviewed and compared with the defined system confidentiality and related security policies.
47
Appendix B: Analyse Normenkader SOC2 C 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its system confidentiality and related security policies.
C 4.3
Environmental, regulatory, and technological changes are monitored, and their impact on system confidentiality and security is assessed on a timely basis. System confidentiality policies and procedures are updated for such changes as required. Privacy Policies The entity defines and documents its privacy policies with respect to the following: a. Notice (See 2.1.0) b. Choice and consent (See 3.1.0) c. Collection (See 4.1.0) d. Use, retention, and disposal (See 5.1.0) e. Access (See 6.1.0) f. Disclosure to third parties (See 7.1.0) g. Security for privacy (See 8.1.0) h. Quality (See 9.1.0) i. Monitoring and enforcement (See 10.1.0)
P 1.1.1
Communication to Internal Personnel Privacy policies and the consequences of noncompliance with such policies are communicated, at least annually, to the entity’s internal personnel responsible for collecting, using, retaining, and disclosing personal information. Changes in privacy policies are communicated to such personnel shortly after the changes are approved
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.1.2
Responsibility and Accountability for Policies Responsibility and accountability are assigned to a person or group for developing, documenting, implementing, enforcing, monitoring, and updating the entity’s privacy policies. The names of such person or group and their responsibilities are communicated to internal personnel.
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.1
Review and Approval Privacy policies and procedures, and changes thereto, are reviewed and approved by management.
Confidentiality
C4
Confidentiality
C4
Privacy
P1
Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
Privacy
P1
Privacy
P1
Monitoring: The entity monitors the system and takes action to maintain compliance with its defined confidentiality policies. Monitoring: The entity monitors the system and takes action to maintain compliance with its defined confidentiality policies. Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.1.0
48
Appendix B: Analyse Normenkader SOC2 Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.10
Changes in Regulatory and Business Requirements For each jurisdiction in which the entity operates, the effect on privacy requirements from changes in the following factors is identified and addressed: • Legal and regulatory • Contracts, including service-level agreements • Industry requirements • Business operations and processes • People, roles, and responsibilities • Technology
Privacy policies and procedures are updated to reflect changes in requirements. Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.2
Consistency of Privacy Policies and Procedures with Laws and Regulations Policies and procedures are reviewed and compared to the requirements of applicable laws and regulations at least annually and whenever changes to such laws and regulations are made. Privacy policies and procedures are revised to conform with the requirements of applicable laws and regulations.
Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.3
Personal Information Identification and Classification The types of personal information and sensitive personal information and the related processes, systems, and third parties involved in the handling of such information are identified. Such information is covered by the entity’s privacy and related security policies and procedures.
Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.4
Risk Assessment A risk assessment process is used to establish a risk baseline and to, at least annually, identify new or changed risks to personal information and to develop and update responses to such risks
Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.5
Consistency of Commitments With Privacy Policies and Procedures Internal personnel or advisers review contracts for consistency with privacy policies and procedures and address any inconsistencies.
49
Appendix B: Analyse Normenkader SOC2 Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.6
Infrastructure and Systems Management The potential privacy impact is assessed when new processes involving personal information are implemented, and when changes are made to such processes (including any such activities outsourced to third parties or contractors), and personal information continues to be protected in accordance with the privacy policies. For this purpose, processes involving personal information include the design, acquisition, development, implementation, configuration, modification and management of the following: • Infrastructure • Systems • Applications • Websites • Procedures • Products and services • Data bases and information repositories • Mobile computing and other similar electronic devices
The use of personal information in process and system test and development is prohibited unless such information is anonymized or otherwise protected in accordance with the entity’s privacy policies and procedures. Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.7
Privacy Incident and Breach Management A documented privacy incident and breach management program has been implemented that includes, but is not limited to, the following: • Procedures for the identification, management, and resolution of privacy incidents and breaches • Defined responsibilities • A process to identify incident severity and determine required actions and escalation procedures • A process for complying with breach laws and regulations, including stakeholders breach notification, if required • An accountability process for employees or third parties responsible for incidents or breaches with remediation, penalties, or discipline as appropriate • A process for periodic review (at least on an annual basis) of actual incidents to identify necessary program updates based on the following: — Incident patterns and root cause — Changes in the internal control environment or external requirements (regulation or legislation) • Periodic testing or walkthrough process (at least on an annual basis) and associated program remediation as needed
Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.8
Qualifications of Internal Personnel The entity establishes qualifications for personnel responsible for protecting the privacy and security of personal information and assigns such responsibilities only to those personnel who meet these qualifications and have received needed training.
50
Appendix B: Analyse Normenkader SOC2 Privacy
P1
Management Principle: The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
P 1.2.9
Privacy Awareness and Training A privacy awareness program about the entity’s privacy policies and related matters, and specific training for selected personnel depending on their roles and responsibilities, are provided.
Privacy
P 10
P 10.1.0
Privacy Policies The entity’s privacy policies address the monitoring and enforcement of privacy policies and procedures.
Privacy
P 10
P 10.1.1
Communication to Individuals Individuals are informed about how to contact the entity with inquiries, complaints and disputes.
Privacy
P 10
P 10.2.1
Inquiry, Complaint, and Dispute Process A process is in place to address inquiries, complaints, and disputes.
Privacy
P 10
P 10.2.2
Dispute Resolution and Recourse Each complaint is addressed, and the resolution is documented and communicated to the individual.
Privacy
P 10
Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes. Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes. Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes. Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes. Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes.
P 10.2.3
Compliance Review Compliance with privacy policies and procedures, commitments and applicable laws, regulations, service-level agreements, and other contracts is reviewed and documented, and the results of such reviews are reported to management. If problems are identified, remediation plans are developed and implemented.
51
Appendix B: Analyse Normenkader SOC2 Privacy
P 10
Privacy
P 10
Privacy
P2
Privacy
P2
Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes. Monitoring and Enforcement Principle: The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy related inquiries, complaints and disputes. Notice Principle: The entity provides notice about its privacy policies and procedures and identifies the purposes for which personal information is collected, used, retained, and disclosed. Notice Principle: The entity provides notice about its privacy policies and procedures and identifies the purposes for which personal information is collected, used, retained, and disclosed.
P 10.2.4
Instances of Noncompliance Instances of noncompliance with privacy policies and procedures are documented and reported and, if needed, corrective and disciplinary measures are taken on a timely basis.
P 10.2.5
Ongoing Monitoring Ongoing procedures are performed for monitoring the effectiveness of controls over personal information, based on a risk assessment [1.2.4], and for taking timely corrective actions where necessary
P 2.1.0
Privacy Policies The entity’s privacy policies address providing notice to individuals.
P 2.1.1
Communication to Individuals Notice is provided to individuals regarding the following privacy policies: a. Purpose for collecting personal information b. Choice and consent (See 3.1.1) c. Collection (See 4.1.1) d. Use, retention, and disposal (See 5.1.1) e. Access (See 6.1.1) f. Disclosure to third parties (See 7.1.1) g. Security for privacy (See 8.1.1) h. Quality (See 9.1.1) i. Monitoring and enforcement (See 10.1.1)
If personal information is collected from sources other than the individual, such sources are described in the notice. Privacy
P2
Notice Principle: The entity provides notice about its privacy policies and procedures and identifies the purposes for which personal information is collected, used, retained, and disclosed.
P 2.2.1
Provision of Notice Notice is provided to the individual about the entity’s privacy policies and procedures (a) at or before the time personal information is collected, or as soon as practical thereafter, (b) at or before the entity changes its privacy policies and procedures, or as soon as practical thereafter, or (c) before personal information is used for new purposes not previously identified.
52
Appendix B: Analyse Normenkader SOC2 Privacy
P2
Privacy
P2
Privacy
P3
Privacy
P3
Privacy
P3
Privacy
P3
Notice Principle: The entity provides notice about its privacy policies and procedures and identifies the purposes for which personal information is collected, used, retained, and disclosed. Notice Principle: The entity provides notice about its privacy policies and procedures and identifies the purposes for which personal information is collected, used, retained, and disclosed. Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information. Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information. Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information. Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information.
P 2.2.2
Entities and Activities Covered An objective description of the entities and activities covered by the privacy policies and procedures is included in the entity’s privacy notice.
P 2.2.3
Clear and Conspicuous The entity’s privacy notice is conspicuous and uses clear language
P 3.1.0
Privacy Policies The entity’s privacy policies address the choices available to individuals and the consent to be obtained.
P 3.1.1
Communication to Individuals Individuals are informed about (a) the choices available to them with respect to the collection, use, and disclosure of personal information, and (b) that implicit or explicit consent is required to collect, use, and disclose personal information, unless a law or regulation specifically requires or allows otherwise.
P 3.1.2
Consequences of Denying or Withdrawing Consent When personal information is collected, individuals are informed of the consequences of refusing to provide personal information or of denying or withdrawing consent to use personal information for purposes identified in the notice.
P 3.2.1
Implicit or Explicit Consent Implicit or explicit consent is obtained from the individual at or before the time personal information is collected or soon after. The individual’s preferences expressed in his or her consent are confirmed and implemented
53
Appendix B: Analyse Normenkader SOC2 Privacy
P3
Privacy
P3
Privacy
P3
Privacy
P4
Privacy
P4
Privacy
P4
Privacy
P4
Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information. Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information. Choice and Consent Principle: The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information. Collection Principle: The entity collects personal information only for the purposes identified in the notice. Collection Principle: The entity collects personal information only for the purposes identified in the notice. Collection Principle: The entity collects personal information only for the purposes identified in the notice.
P 3.2.2
Consent for New Purposes and Uses If information that was previously collected is to be used for purposes not previously identified in the privacy notice, the new purpose is documented, the individual is notified, and implicit or explicit consent is obtained prior to such new use or purpose.
P 3.2.3
Explicit Consent for Sensitive Information Explicit consent is obtained directly from the individual when sensitive personal information is collected, used, or disclosed, unless a law or regulation specifically requires otherwise.
P 3.2.4
Consent for Online Data Transfers To or From an Individual’s Computer or Other Similar Electronic Devices Consent is obtained before personal information is transferred to or from an individual’s computer or other similar device.
P 4.1.0
Privacy Policies The entity’s privacy policies address the collection of personal information.
P 4.1.1
Communication to Individuals Individuals are informed that personal information is collected only for the purposes identified in the notice.
P 4.1.2
Types of Personal Information Collected and Methods of Collection The types of personal information collected and the methods of collection, including the use of cookies or other tracking techniques, are documented and described in the privacy notice.
Collection Principle: The entity collects personal information only for the purposes identified in the notice.
P 4.2.1
Collection Limited to Identified Purpose The collection of personal information is limited to that necessary for the purposes identified in the notice.
54
Appendix B: Analyse Normenkader SOC2 Privacy
P4
Collection Principle: The entity collects personal information only for the purposes identified in the notice.
P 4.2.2
Collection by Fair and Lawful Means Methods of collecting personal information are reviewed by management before they are implemented to confirm that personal information is obtained (a) fairly, without intimidation or deception, and (b) lawfully, adhering to all relevant rules of law, whether derived from statute or common law, relating to the collection of personal information.
Privacy
P4
Collection Principle: The entity collects personal information only for the purposes identified in the notice.
P 4.2.3
Collection From Third Parties Management confirms that third parties from whom personal information is collected (that is, sources other than the individual) are reliable sources that collect information fairly and lawfully.
Privacy
P4
P 4.2.4
Information Developed About Individuals Individuals are informed if the entity develops or acquires additional information about them for its use.
Privacy
P5
P 5.1.1
Privacy Policies The entity’s privacy policies address the use, retention, and disposal of personal information.
Privacy
P5
Collection Principle: The entity collects personal information only for the purposes identified in the notice. Use, Retention, and Disposal Principle: The entity limits the use of personal information to the purposes identified in the notice and for which the individual has provided implicit or explicit consent. The entity retains personal information for only as long as necessary to fulfill the stated purposes or as required by law or regulations and thereafter appropriately disposes of such information. Use, Retention, and Disposal Principle: The entity limits the use of personal information to the purposes identified in the notice and for which the individual has provided implicit or explicit consent. The entity retains personal information for only as long as necessary to fulfill the stated purposes or as required by law or regulations and thereafter appropriately disposes of such information.
P 5.1.2
Communication to Individuals Individuals are informed that personal information is (a) used only for the purposes identified in the notice and only if the individual has provided implicit or explicit consent, unless a law or regulation specifically requires otherwise, (b) retained for no longer than necessary to fulfill the stated purposes, or for a period specifically required by law or regulation, and (c) disposed of in a manner that prevents loss, theft, misuse, or unauthorized access.
55
Appendix B: Analyse Normenkader SOC2 Privacy
P5
Privacy
P5
Privacy
P5
Privacy
P6
Privacy
P6
Use, Retention, and Disposal Principle: The entity limits the use of personal information to the purposes identified in the notice and for which the individual has provided implicit or explicit consent. The entity retains personal information for only as long as necessary to fulfill the stated purposes or as required by law or regulations and thereafter appropriately disposes of such information. Use, Retention, and Disposal Principle: The entity limits the use of personal information to the purposes identified in the notice and for which the individual has provided implicit or explicit consent. The entity retains personal information for only as long as necessary to fulfill the stated purposes or as required by law or regulations and thereafter appropriately disposes of such information. Use, Retention, and Disposal Principle: The entity limits the use of personal information to the purposes identified in the notice and for which the individual has provided implicit or explicit consent. The entity retains personal information for only as long as necessary to fulfill the stated purposes or as required by law or regulations and thereafter appropriately disposes of such information. Access Principle: The entity provides individuals with access to their personal information for review and update. Access Principle: The entity provides individuals with access to their personal
P 5.2.1
Use of Personal Information Personal information is used only for the purposes identified in the notice and only if the individual has provided implicit or explicit consent, unless a law or regulation specifically requires otherwise.
P 5.2.2
Retention of Personal Information Personal information is retained for no longer than necessary to fulfill the stated purposes unless a law or regulation specifically requires otherwise.
P 5.2.3
Disposal, Destruction and Redaction of Personal Information Personal information no longer retained is anonymized, disposed of, or destroyed in a manner that prevents loss, theft, misuse, or unauthorized access.
P 6.1.0
Privacy Policies The entity’s privacy policies address providing individuals with access to their personal information
P 6.1.1
Communication to Individuals Individuals are informed about how they may obtain access to their personal information to review, update, and correct that information.
56
Appendix B: Analyse Normenkader SOC2 information for review and update.
Access Principle: The entity provides individuals with access to their personal information for review and update. Access Principle: The entity provides individuals with access to their personal information for review and update. Access Principle: The entity provides individuals with access to their personal information for review and update. Access Principle: The entity provides individuals with access to their personal information for review and update.
P 6.2.1
Access by Individuals to Their Personal Information Individuals are able to determine whether the entity maintains personal information about them and, upon request, may obtain access to their personal information
P 6.2.2
Confirmation of an Individual’s Identity The identity of individuals who request access to their personal information is authenticated before they are given access to that information.
P 6.2.3
Understandable Personal Information, Time Frame, and Cost Personal information is provided to the individual in an understandable form, in a reasonable timeframe, and at a reasonable cost, if any
P 6.2.4
Denial of Access Individuals are informed, in writing, of the reason a request for access to their personal information was denied, the source of the entity’s legal right to deny such access, if applicable, and the individual’s right, if any, to challenge such denial, as specifically permitted or required by law or regulation+B70:B91
P6
Access Principle: The entity provides individuals with access to their personal information for review and update.
P 6.2.5
Updating or Correcting Personal Information Individuals are able to update or correct personal information held by the entity. If practical and economically feasible to do so, the entity provides such updated or corrected information to third parties that previously were provided with the individual’s personal information.
Privacy
P6
P 6.2.6
Statement of Disagreement Individuals are informed, in writing, about the reason a request for correction of personal information was denied, and how they may appeal
Privacy
P7
Access Principle: The entity provides individuals with access to their personal information for review and update. Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual.
P 7.1.0
Privacy Policies The entity’s privacy policies address the disclosure of personal information to third party.
Privacy
P6
Privacy
P6
Privacy
P6
Privacy
P6
Privacy
57
Appendix B: Analyse Normenkader SOC2 Privacy
P7
Privacy
P7
Privacy
P7
Privacy
P7
Privacy
P7
Privacy
P7
Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual. Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual. Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual. Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual.
P 7.1.1
Communication to Individuals Individuals are informed that personal information is disclosed to third parties only for the purposes identified in the notice and for which the individual has provided implicit or explicit consent unless a law or regulation specifically allows or requires otherwise.
P 7.1.2
Communication to Third Parties Privacy policies or other specific instructions or requirements for handling personal information are communicated to third parties to whom personal information is disclosed.
P 7.2.1
Disclosure of Personal Information Personal information is disclosed to third parties only for the purposes described in the notice, and for which the individual has provided implicit or explicit consent, unless a law or regulation specifically requires or allows otherwise.
P 7.2.2
Protection of Personal Information Personal information is disclosed only to third parties who have agreements with the entity to protect personal information in a manner consistent with the relevant aspects of the entity’s privacy policies or other specific instructions or requirements. The entity has procedures in place to evaluate that the third parties have effective controls to meet the terms of the agreement, instructions, or requirements.
Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual. Disclosure to Third Parties Principle: The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual.
P 7.2.3
New Purposes and Uses Personal information is disclosed to third parties for new purposes or uses only with the prior implicit or explicit consent of the individual.
P 7.2.4
Misuse of Personal Information by a Third Party The entity takes remedial action in response to misuse of personal information by a third party to whom the entity has transferred such information.
58
Appendix B: Analyse Normenkader SOC2 Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.1.0
Privacy Policies The entity’s privacy policies (including any relevant security policies), address the security of personal information.
Privacy
P8
P 8.1.1
Communication to Individuals Individuals are informed that precautions are taken to protect personal information.
Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical). Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.1.2
Information Security Program A security program has been developed, documented, approved, and implemented that includes administrative, technical, and physical safeguards to protect personal information from loss, misuse, unauthorized access, disclosure, alteration, and destruction. The security program should address, but not be limited to, the following areas1 insofar as they relate to the security of personal information: a. Risk assessment and treatment [1.2.4] b. Security policy [8.1.0] c. Organization of information security [sections 1, 7, and 10] d. Asset management [section 1] e. Human resources security [section 1] f. Physical and environmental security [8.2.3 and 8.2.4] g. Communications and operations management [sections 1, 7, and 10] h. Access control [sections 1, 8.2, and 10] i. Information systems acquisition, development, and maintenance [1.2.6] j. Information security incident management [1.2.7] k. Business continuity management [section 8.2] l. Compliance [sections 1 and 10]
59
Appendix B: Analyse Normenkader SOC2 Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.2.2
Logical Access Controls Logical access to personal information is restricted by procedures that address the following matters: a. Authorizing and registering internal personnel and individuals b. Identifying and authenticating internal personnel and individuals c. Making changes and updating access profiles d. Granting privileges and permissions for access to IT infrastructure components and personal information e. Preventing individuals from accessing anything other than their own personal or sensitive information f. Limiting access to personal information to only authorized internal personnel based upon their assigned roles and responsibilities g. Distributing output only to authorized internal personnel h. Restricting logical access to offline storage, backup data, systems, and media i. Restricting access to system configurations, superuser functionality, master passwords, powerful utilities, and security devices (for example, firewalls) j. Preventing the introduction of viruses, malicious code, and unauthorized software
Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.2.3
Physical Access Controls Physical access is restricted to personal information in any form (including the components of the entity’s system(s) that contain or protect personal information).
Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.2.4
Environmental Safeguards Personal information, in all forms, is protected against accidental disclosure due to natural disasters and environmental hazards
Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.2.5
Transmitted Personal Information Personal information is protected when transmitted by mail or other physical means. Personal information collected and transmitted over the Internet, over public and other nonsecure networks, and wireless networks is protected by deploying industry standard encryption technology for transferring and receiving personal information
Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.2.6
Personal Information on Portable Media Personal information stored on portable media or devices is protected from unauthorized access
Privacy
P8
Security for Privacy Principle: The entity protects personal information against unauthorized access (both physical and logical).
P 8.2.7
Testing Security Safeguards Tests of the effectiveness of the key administrative, technical, and physical safeguards protecting personal information are conducted at least annually.
60
Appendix B: Analyse Normenkader SOC2 Privacy
P9
Quality Principle: The entity maintains accurate, complete, and relevant personal information for the purposes identified in the notice.
P 9.1.0
Privacy Policies The entity’s privacy policies address the quality of personal information.
Privacy
P9
Quality Principle: The entity maintains accurate, complete, and relevant personal information for the purposes identified in the notice.
P 9.1.1
Communication to Individuals Individuals are informed that they are responsible for providing the entity with accurate and complete personal information, and for contacting the entity if correction of such information is required.
Privacy
P9
Quality Principle: The entity maintains accurate, complete, and relevant personal information for the purposes identified in the notice.
P 9.2.1
Accuracy and Completeness of Personal Information Personal information is accurate and complete for the purposes for which it is to be used.
Privacy
P9
Quality Principle: The entity maintains accurate, complete, and relevant personal information for the purposes identified in the notice.
P 9.2.2
Relevance of Personal Information Personal information is relevant to the purposes for which it is to be used.
61
