Zekerheid over de beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy bij Cloud Service Providers

Transcriptie

1 ... Zekerheid over de beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy bij Cloud Service Providers Service Organization Controls-rapporten toegepast binnen de Nederlandse wet- en regelgeving voor IT-auditors en accountants Auteur: Dhr. T.C. (Tom) Ooms MSc RA Datum: 17 april 2015

2 Zekerheid over de beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy bij Cloud Service Providers Service Organization Controls-rapporten toegepast binnen de Nederlandse wet- en regelgeving voor IT-auditors en accountants Referaat IT-Auditing & Advisory Erasmus Universiteit Rotterdam Erasmus School of Accounting & Assurance (ESAA) Postinitiële opleiding IT-Auditing & Advisory (ITAA) Naam Dhr. T.C. (Tom) Ooms MSc RA (studentnummer: ) Referaatbegeleider Dhr. J. (Jan) Pasmooij RE RA RO Plaats & datum Heerhugowaard, 17 april 2015 Openbaarmaking Gebruik met bronvermelding toegestaan

3 Voorwoord Vele jaren heb ik met veel plezier als accountant gewerkt en tientallen jaarrekeningcontroles verricht. Enkele jaren geleden ben ik mij steeds meer gaan interesseren in de IT-kant van het audit vakgebied waardoor ik in augustus 2013 heb besloten de opleiding IT-Auditing & Advisory te gaan volgen aan de Erasmus Universiteit Rotterdam. Met veel genoegen heb ik kennis genomen van onderwerpen die mij als audit professional verder hebben gebracht. Doordat ik als accountant ben opgeleid blijft mijn interesse in het assurance-vakgebied groot en voer ik in de praktijk vooral assurance-opdrachten uit bij ondernemingen die een link hebben met technologie en IT. Deze opdrachten hebben voornamelijk een raakvlak tussen processen & systemen, interne beheersingsraamwerken (beheersingsmaatregelen) en IT. Door middel van mijn praktijkervaringen van de afgelopen jaren heb ik in dit referaat aandacht geschonken aan rapportages bij serviceorganisaties over hun interne beheersingsraamwerk. Specifieke aandacht heb ik voor Cloud Service Providers (CSPs) die steeds vaker processen overnemen van een organisatie. De vraag naar assurance over processen en systemen groeit daardoor enorm. Daarentegen heb ik gemerkt dat er veel misvattingen bestaan omtrent auditing-standaarden, richtlijnen en soorten rapportages. Daarnaast verandert de vraag naar assurance van een meer financieel gedreven vraag ( hoe raken deze processen mijn jaarrekening?) naar een meer beveiliging gedreven vraag ( hoe weet ik dat die serviceorganisatie adequate veiligheidsmaatregelen heeft getroffen om mijn data te beschermen?). Mijn praktijkervaringen werden nog maar eens bevestigd door de Audit Alert van de NOREA in november 2014 (NOREA, 2014). In de praktijk blijken IT-auditors onvoldoende te weten waarvoor Richtlijn (of Standaard) 3402 bedoeld is, welke kennis nodig is om een dergelijke opdracht uit te voeren en welke comfort ontleend kan worden uit een dergelijk rapport. Een ander recent artikel over de accreditatie door een auditor van een Engelse bitcoin-beheerder (Accountant.nl, 2015) gaf wederom de veranderende vraag van assurance aan (veiligheid en juistheid algoritmes) als de onwetendheid welke assurance-standaarden hiervoor te gebruiken. De auditor had gekozen voor een assurance-rapport op basis van Standaard 3402 terwijl hij rapporteert over enkel de beveiligingsrisico s en niet over de financiële rapportage risico s. Door middel van dit referaat probeer ik enkele misvattingen uit de wereld te helpen, rapportages over serviceorganisaties en hun interne beheersing nader toe te lichten (en de vormen daarvan) en de rol die een auditor kan spelen middels een assurance-rapport. Ook bespreek ik de elementen die een auditor in ogenschouw dient te houden bij de uitvoer van een dergelijke opdracht om zodoende een kwalitatief goed product te leveren waarop gebruikersorganisaties kunnen steunen. Speciale dank gaat uit naar de heer Pasmooij (referaatbegeleider) waarvan ik de ruimte heb gekregen om dit onderwerp verder uit te diepen en mijn praktijkervaring te combineren met de zitting in de werkgroep SOC2 van de NOREA. Daarnaast heb ik de mogelijkheid gekregen om goede discussies te voeren over relevante onderwerpen voor accountants en IT-auditors gedurende colleges en hebben we de nodige goede discussies gevoerd over innovaties die ons auditberoep gaan beïnvloeden, nu en in de toekomst. Ook bedank ik de SOC2-werkgroepleden van de NOREA die voor mij tijd hebben vrijgemaakt voor goede inhoudelijke gesprekken over het onderwerp van dit referaat. Ik wens u veel leesplezier! 17 april 2015, Tom Ooms

4 Samenvatting In Nederland worden al enkele jaren door accountants en IT-auditors assurance-rapporten afgegeven op basis van standaard 3402 of NOREA richtlijn De productnaam is een Service Organization Controls 1-report (SOC1-rapport). Dit rapport gaat over serviceorganisaties en is bedoeld voor het management en de accountant van de gebruikersorganisaties om inzicht te krijgen in de financiële rapportage risico s ten behoeve van de jaarrekening(controle). De vraag naar andere SOC-rapportages over beveiligings- en privacyaspecten stijgt door de toenemende mate waarin Cloud Service Providers diensten verlenen aan organisaties. De doelstelling van dit onderzoek was om inzicht te verschaffen in de knelpunten rondom het uitbrengen van SOC2/3-rapporten op basis van de Nadere Voorschriften Controle- en Overige Standaarden en de NOREA-richtlijnen. Deze SOC2/3-rapporten gaan over de volgende criteria: beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy. Door de stijgende vraag naar SOC2/3-rapporten is een werkgroep gestart binnen de NOREA over dit onderwerp. Aan de hand van interviews met de leden van deze werkgroep is de probleemstelling van dit onderzoek getoetst. Alvorens is een conceptueel model vastgesteld op basis van literatuur en eigen praktijkervaringen. Naar aanleiding van dit onderzoek zijn de volgende knelpunten geconstateerd die nader onderzocht dienen te worden voordat assurance-rapporten, gebaseerd op SOC2/3, op basis van de Nederlandse uitvoeringsstandaarden of richtlijnen uitgebracht kunnen worden: Op dit moment is het uitbrengen van een SOC3-rapport in Nederland niet mogelijk doordat het SOC3-keurmerk is beschermd door de AICPA. Om het SOC2/3-object van onderzoek goed te kunnen controleren is een diepgaande IT kennis nodig. Het ontbreekt aan nadere richtlijnen rondom de deskundigheid van auditors om een gedegen audit uit te voeren van dit object van onderzoek. Er zijn slechts een beperkt aantal mappings, tussen bestaande en erkende, controleraamwerken en de Trust Services Principels en criteria beschikbaar (als referentiekader voor de auditor). Er is een mogelijke mismatch tussen de privacy criteria en de wet- en regelgeving. Daarnaast zijn er contradicties in de privacywetgeving tussen verschillende landen. De SOC2-rapportages zijn voor een bredere groep gebruikers beschikbaar waardoor moeilijk de toereikende reikwijdte en diepgang van een SOC-rapport, en daardoor het rationele doel, is vast te stellen door de auditor. Op basis van dit onderzoek zijn er enkele knelpunten die de uitgifte van een SOC2-rapport in Nederland mogelijk belemmeren of een risico vormen bij de uitgifte van een assurance-rapport. De accountant of IT-auditor dient daarom per opdracht goed na te gaan welke risico s er spelen, wie tot de gebruikerskring behoren en welke risico s daaraan zijn verbonden. SOC-rapporten zijn vaak omvangrijk en moeilijk om te beoordelen zonder voldoende kennis van de onderneming en haar huishouding. Door de toenemende complexiteit door ontwikkelingen zoals the internet of things waardoor systemen en processen steeds verder met elkaar zijn verbonden en waardoor er steeds meer (sub) serviceorganisaties in de keten met elkaar in verbinding staan is het haast onmogelijk om een SOC-rapport te beoordelen en de conclusies te interpreteren op de eigen organisatie. Daartegenover staat dat stakeholders behoefte hebben aan betaalbare assurance-rapporten, liefst publiekelijk beschikbaar inclusief een keurmerk. Nader onderzoek moet uitwijzen hoe deze vraag naar assurance-producten kan worden gerealiseerd en de complexiteit van SOC-rapportages kan worden verminderd.

5 Inhoudsopgave Voorwoord... I Samenvatting... II Inhoudsopgave... III 1 Inleiding Onderwerp Aanleiding van het onderzoek Probleemstelling en deelvragen Conceptueel model en onderzoeksopzet Beoogd gebruik en rapportage Verloop van het onderzoek Theoretisch kader SOC-rapportering Service Organization Controls reporting (SOC reporting) Standaarden Controleraamwerk Verschijningsvormen SOC-rapportages Risico s SOC2/3-rapportages voor IT-auditors en accountants Lessons learned rondom SOC-reporting Analyse op basis van eigen praktijkervaringen SOC-rapportering Hiaten tussen de vraag van de service- en gebruikersorganisaties en die van de huidige SOC-rapportages Risico s SOC2/3-rapportages voor IT-auditors en accountants Ervaringen SOC-reporting en lessons learned Lessons learned uit SOC-audits Inhoud van een SOC-rapport Voordelen en mogelijkheden van SOC-rapportages Informatie verkrijgende en toetsende interviews Geoperationaliseerd model Interviews subject matter experts SOC Hiaten Risico s Lessons learned... 27

6 5 Beantwoording van onderzoeksvragen Beantwoording Deelvraag 1: Hiaten vraag en aanbod SOC-rapportages Deelvraag 2: Risico s voor auditors SOC2/ Deelvraag 3: Lessons learned SOC-rapportages Conclusies en aanbevelingen Beantwoording probleemstelling Aanbevelingen Bibliografie Bijlage A - interviewverslagen Geïnterviewde: A Geïnterviewde: B Geïnterviewde: C Geïnterviewde: D Geïnterviewde: E Geïnterviewde: F Geïnterviewde: G Bijlage B Toetsend onderzoek Bijlage C Concept handreiking SOC2 NOREA/NBA... 55

7 1 Inleiding In dit hoofdstuk worden de onderwerpkeuze, de aanleiding inclusief de probleemstelling en deelvragen behandeld. De probleemstelling en deelvragen zijn vervolgens weergegeven in een conceptueel model en vertaald naar een onderzoeksopzet. Vervolgens wordt de wijze van presentatie van het onderzoek en de literatuur besproken. 1.1 Onderwerp Het onderwerp van dit referaat richt zich op Service Organization Controls-rapporten (hierna SOC-rapporten). SOC betreft een verzamelbegrip van assurance-dienstverlening door ITauditors en accountants (hierna auditors) ten behoeve van serviceorganisaties. De auditor kan een assurance-rapport verstrekken over de opzet (en werking) van de processen en systemen zoals ingericht bij de serviceorganisatie. De rapportage kan gericht zijn op financiële verantwoordingsrisico s voor de gebruikersorganisatie (SOC1 / COS3402 / NOREA-richtlijn 3402) of op de prestatie van een (IT-)systeem op de aspecten beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy (SOC2- en SOC3-rapportages). Deze laatste rapportage is voornamelijk relevant voor IT-dienstverleners zoals de Cloud Service Providers (hierna CSPs) en datacenters. In Nederland is de vraag naar SOC2 en 3-rapportages nog beperkt. De verwachting is echter op basis van een stijgende outsourcing van bedrijfsprocessen naar serviceorganisaties dat de vraag gaat toenemen. Door de opkomst van CSPs die hele bedrijfsprocessen overnemen stijgt de vraag naar nieuwe kwalitatieve assurance-producten. De huidige NOREA-richtlijn 3402 en NV COS 3402 (SOC1) voldoet niet meer aan de vraag van gebruikers van de serviceorganisatie. Figuur 1: reikwijdte SOC1, SOC2 en SOC3-rapport (Lonborg & Avedissian, 2013) De vraag verandert voornamelijk omdat een SOC1-rapportage slechts een beperkte reikwijdte heeft met betrekking tot de aspecten (data) integriteit, beveiliging en beschikbaarheid. Daarnaast zijn aspecten als vertrouwelijkheid en privacy niet van belang om over te rapporteren in het kader van de financiële verantwoordingsrisico s van de gebruikersorganisatie (waarvoor SOC1-rapportages zijn bedoeld).

8 In de praktijk ontstaat er echter een beweging waarbij toch vertrouwelijkheid- en privacy elementen worden meegenomen binnen de reikwijdte van een COS 3402-rapport. Een voorbeeld betreft het Keurmerk Zeker Online waarbij een standaard controleraamwerk is vastgesteld voor online administratieve dienstverleners. Binnen de Keurmerk Zeker Online systematiek wordt een COS 3402-assurance-rapport afgegeven door de IT-auditor of accountant op basis van het standaard raamwerk (waarin dus ook vertrouwelijkheid en privacy is opgenomen). Vervolgens wordt een keurmerk afgegeven. Een dergelijk voorbeeld geeft aan dat nader onderzoek nodig is om na te gaan hoe we SOC2 en SOC3 kunnen integreren binnen de Nederlandse wettelijke kaders omdat de huidige COS 3402 reikwijdte wordt uitgebreid met doelstellingen en criteria die niet direct van invloed zijn op de financiële verantwoordingsrisico s (waarvoor COS 3402 primair is bedoeld). Doelstelling van dit onderzoek is om inzicht te verschaffen in de risico s voor IT-auditors en accountants rondom SOC2 en 3-rapporten in Nederlandse context. Door de stijgende vraag naar SOC2 en 3-rapporten binnen Nederland is een werkgroep gestart binnen de NOREA over dit onderwerp. Dit referaat kan de werkgroep handvatten bieden voor nader onderzoek naar de aandachtspunten en risico s rondom de SOC2 en 3 binnen de Nederlandse wettelijke kaders (voor IT-auditors en accountants). In dit referaat wordt gesproken over Cloud Service Providers (CSPs). Voor deze beperking tot de CSPs is gekozen omdat de probleemstelling in de praktijk zich nu als eerste voordoet bij dit type serviceorganisaties. Daarentegen kunnen de uitkomsten ook worden gebruikt voor andere (IT)-dienstverleners waarvoor beveiligings- en privacyaspecten relevant zijn. In de praktijk zijn bijvoorbeeld datacenters ook bezig met rapportering over beveiliging en privacy. 1.2 Aanleiding van het onderzoek De afgelopen jaren hebben er diverse incidenten plaatsgevonden bij IT-dienstverleners of aanverwante partijen. Hierna volgen een aantal voorbeelden van deze incidenten: Op basis van recente beveiligingsincidenten met OpenSSL en SSL3.0 bleek dat er al jaren een lek zat in de beveiliging van deze communicatiesoftware waarmee wij als internetgebruikers veilig met elkaar dachten te communiceren. De Distributed denial-of-service-aanvallen (DDoS-aanvallen) hebben de afgelopen jaren grote bedrijven al met de nodige problemen opgezadeld. Grote banken en betaalorganisaties hebben bijvoorbeeld al meerdere malen meegemaakt dat er zoveel internetverkeer naar hun betaalapplicatie werd gestuurd waardoor klanten niet meer via internet konden betalen. De betaalmethodes waren niet meer beschikbaar. Hierdoor hebben duizenden web shops mogelijkerwijs omzet misgelopen omdat betalingen niet afgehandeld konden worden. Onjuiste facturen van Telecombedrijven doordat contractgegevens niet juist zijn verwerkt of doordat de facturen niet juist zijn samengesteld op basis van de bronregistratie. De integriteit van deze gegevens en ook de factuur is daardoor niet gewaarborgd. USB-sticks met vertrouwelijke informatie die worden achtergelaten of verloren door werknemers. Of phishing-attacks waarbij personen worden opgelicht en vertrouwelijke informatie wordt achtergelaten in onbetrouwbare internetomgevingen (waar vervolgens door internetfraudeurs misbruik van wordt gemaakt). Jaarlijks horen we meermaals dat privacy gevoelige informatie is gestolen van individuele personen zoals creditcard gegevens. Er kan allang niet meer van een incident worden gesproken.

9 Naar aanleiding van deze incidenten stijgt de vraag naar zekerheid over aspecten zoals beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy. In Amerika is reeds een attest-standaard aanwezig op basis waarvan accountants over deze SOC2 en SOC3 Trust Services Principles rapporteert. In Nederland bestaat een dergelijk audit of attest-raamwerk nog niet. Serviceorganisaties en gebruikersorganisaties vragen ook in Nederland steeds meer aan IT-auditors en accountants of zij assurance kunnen verschaffen over deze aspecten. In de praktijk hebben de IT-auditors en accountants echter onvoldoende kennis om te bepalen op welke wijze zij kunnen rapporteren over de beveiligings- en privacy elementen binnen de huidige standaarden en richtlijnen. Derhalve is nader onderzoek vereist om tot een analyse te komen welke aspecten nader geëvalueerd dienen te worden om tot een handreiking te komen voor IT-auditors en accountants. In dat kader heeft de NOREA gemeend een werkgroep op te richten die een nadere analyse uitvoert op welke wijze SOC2/3-rapporten binnen een Nederlandse context uitgebracht dienen te worden. De eerste fase is gebruikt voor een knelpuntenanalyse, vervolgens is gezocht naar een uitwerking voor IT-auditors waarna vervolgens tot een handreiking kan worden gekomen voor zowel IT-auditors als accountants. 1.3 Probleemstelling en deelvragen Naar aanleiding van de problematiek zoals geschetst in de vorige twee paragrafen kan de volgende probleemstelling worden verwoord: Welke knelpunten dienen nader te worden onderzocht om zodoende, binnen de Nadere Voorschriften Controle- en Overige Standaarden en de NOREA-richtlijnen, een Service Organization Controls-rapport (SOC-rapport) te kunnen uitbrengen rondom de aspecten beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy. Om antwoord te kunnen geven op de probleemstelling zijn de volgende deelvragen geformuleerd: 1. Welke hiaten zitten er tussen de vraag naar assurance-producten van Cloud Service Providers (CSPs) en de gebruikersorganisaties versus de huidige controle- en assurance-standaarden (en richtlijnen)? 2. Welke risico s zijn er aangaande SOC2 en SOC3-rapporten die aandacht behoeven en dienen te worden geadresseerd in een handreiking voor IT-auditors en accountants? 3. Van welke lessons learned rondom SOC1-reporting, binnen de huidige Nederlandse controle- en assurance-standaarden (en richtlijnen), kunnen we als auditors leren om een kwalitatief goed SOC2 of SOC3-rapport af te geven?

10 1.4 Conceptueel model en onderzoeksopzet Op basis van de probleemstelling en de deelvragen kan het volgende conceptueel model worden weergegeven: risico s SOC2/3 2 3 Nederlands wettelijk kader Vraag CSP s en gebruikersorganisaties (huidige) SOC reports 1 hiaten Nederlands wettelijk kader Figuur 2: conceptueel model Het onderzoek is gericht op internationale literatuur en praktisch gebruik binnen de Nederlandse wettelijke kaders. Het verzamelen en verwerken van gegevens zal plaatsvinden om de probleemstelling en deelvragen te beantwoorden. Doelstelling is om een uitspraak te doen over het gebruik van SOC-rapporten binnen de Nederlandse wettelijke kaders. De nummers zoals weergegeven in het conceptueel model refereren naar de deelvragen zoals benoemd in hoofdstuk 1.3. De onderzoeksmethoden die worden gebruikt betreffen een beperkte meta-analyse van (internationale wetenschappelijke) literatuur, het voeren van interviews met behulp van de input uit de meta-analyse en het valideren van de uitkomsten van de interviews en metaanalyse met de NOREA werkgroep SOC2/3. De volgende onderzoekstappen worden genomen: 1. Uitvoeren van een beperkt literatuuronderzoek ter illustratie van de verschillende SOCrapportages en aanverwante producten (hoofdstuk 2) 2. Opstellen van een lessons learned, hiaten- en risicoanalyse op basis van eigen praktijkervaring rondom SOC-rapporten (hoofdstuk 3) 3. Opstellen van een concept knelpuntenanalyse op basis van de meta-analyse en praktijkervaringen (hoofdstuk 4). De analyse bevat de volgende aspecten: Vraag van gebruikers CSPs versus auditors producten (SOC1 t/m 3) Risico s aangaande de huidige assurance SOC1 t/m 3 producten Ervaringen SOC-reporting en lessons learned 4. Voeren van interviews met de NOREA werkgroepleden SOC2/3 (hoofdstuk 4) over: Vraag van gebruikers CSPs versus auditors producten (SOC1 t/m 3) Risico s aangaande toekomstige SOC2/3 rapportages Ervaringen SOC-reporting en lessons learned

11 5. Valideren van het geoperationaliseerd model op basis van interviewverslagen (hoofdstuk 4) 1.5 Beoogd gebruik en rapportage Naar aanleiding van het onderzoek zoals beschreven in de voorgaande paragrafen zal een rapport worden opgesteld. Het rapport bestaat uit een knelpuntenanalyse welke antwoord geeft op de geformuleerde deelvragen en probleemstelling (zoals benoemd in hoofdstuk 1.3). Het rapport wordt verstrekt aan de werkgroepleden en is daarnaast openbaar beschikbaar voor iedere belanghebbende. 1.6 Verloop van het onderzoek In het figuur hierna is weergegeven hoe dit referaat is opgebouwd. In hoofdstuk 2 wordt een theoretisch kader beschreven met betrekking tot SOC. Hoofdstuk 3 beschrijft eigen praktijkervaringen waarna in hoofdstuk 4 een geoperationaliseerd model wordt behandeld en gevalideerd op basis van interviews met subject matter experts uit het audit-veld. In hoofdstuk 5 worden de onderzoeksvragen beantwoord en in hoofdstuk 6 de conclusies en aanbevelingen beschreven. Hoofdstuk 3 Analyse eigen praktijkervaringen Hoofdstuk 1 Inleiding Hoofdstuk 2 Theoretisch kader (literatuur) Hoofdstuk 5 Beantwoording onderzoeksvragen Hoofdstuk 6 Conclusies Hoofdstuk 4 Empirisch onderzoek (interviews) Figuur 3: Overzicht opzet referaat

12 2 Theoretisch kader SOC-rapportering Om inzicht te geven in de verschillende verschijningsvormen van SOC-rapportages, aanverwante producten en de relatie tussen Assurance & Auditing standaarden wordt in dit hoofdstuk een nadere uiteenzetting gegeven van deze onderwerpen. Om SOC-rapporten te begrijpen is het eerst noodzakelijk om te begrijpen waarom serviceorganisaties überhaupt zijn ontstaan en een groot deel van de processen overnemen van bedrijven. Belangrijkste redenen voor een bedrijf om een gedeelte van haar processen uit te besteden wordt veroorzaakt door de specialistische kennis die een serviceorganisatie heeft van deze processen (terwijl het voor het bedrijf zelf niet haar corebusiness betreft). Hierdoor kan de kwaliteit van de dienstverlening bij de serviceorganisatie op een zeer hoog niveau liggen door het gespecialiseerde personeel. Ook kan de dienstverlening tegen gunstigere kosten worden gerealiseerd door de schaalgrootte en focus van de serviceorganisatie op deze specifieke dienstverlening (Sinha, Jaiswal, Gupta, & Chaurasiya, 2011). Risico s uitbesteding van business processen aan serviceorganisaties Het uitbesteden van processen brengt echter niet alleen voordelen met zich mee. Er zijn ook een aantal risico s te definiëren die specifiek toe zijn te wijzen aan uitbesteding, namelijk (Sinha, Jaiswal, Gupta, & Chaurasiya, 2011) : 1. Technologisch risico s: deze risico s zitten voornamelijk op het IT vlak. Het risico dat een systeem, een applicatie of het netwerk niet live is. Door steeds verdere digitalisering kunnen bedrijven zich het steeds minder permitteren dat de IT niet goed functioneert. Bijvoorbeeld web shops die altijd online moeten zijn. 2. Proces risico s: deze risico s kunnen worden onderverdeeld in kwalitatief en kwantitatief: - Kwalitatief risico: bijvoorbeeld een risico dat klanten niet tevreden zijn met de dienstverlening. - Kwantitatief risico (effectiviteit en efficiency): een risico dat de verwerking van omzettransacties niet wordt gerealiseerd (verwerking te traag), of dat de wachttijd voor het verhelpen van incidenten te lang is, of wanneer de facturen niet aansluiten met een bestelde order hoeveelheid. Vooral de kwantitatieve risico s kunnen een direct effect hebben op de jaarrekeningen van de gebruikersorganisaties. Echter hebben de andere benoemde risico s slechts een indirect effect op de financiën terwijl deze risico s meer relevant zijn vanuit een technologisch oogpunt en tevredenheid over de dienstverlening. Uitbesteding betekent niet direct dat risico s niet voor de gebruikersorganisatie zijn of dat deze zijn weerlegd. De activiteit om risico s te mitigeren is weerlegd, echter is de gebruikersorganisatie nog steeds verantwoordelijk om het risico te beheersen. Daarom is het van belang dat gebruikersorganisaties in voldoende mate aan service level management doen en dus monitoring controls hebben ingericht om de serviceverlening van de serviceorganisatie te toetsen. Het is niet voor niets dat dat er een groot deel rondom service level management in COBIT5 is opgenomen (ISACA, 2012) Daarentegen is de vraag of monitoring en service level management voldoende is op basis van service level reporting en monitoring tools. De vraag naar zekerheid dat processen daadwerkelijk goed zijn ingericht en werken bij een serviceorganisatie wordt steeds groter (Fanning, 2014).

13 2.1 Service Organization Controls reporting (SOC-reporting) Om zekerheid te krijgen over de wijze waarop het interne beheersingskader bij een serviceorganisatie is ingericht wordt steeds vaker gevraagd naar verantwoordingsrapporten. Om deze verantwoording af te kunnen leggen zijn SOC-rapportages ontwikkeld door beroepsorganisaties van auditors en accountants. Wat is SOC? De term SOC is een in de US geregistreerd handelsmerk door de AICPA en staat voor: Service Organization Control. SOC-rapporten gaan over de controls en controleomgeving zoals ingericht bij een serviceorganisatie ten behoeve van derden, zoals bijvoorbeeld de gebruikersorganisaties. De term SOC refereert niet naar een audit of assurance-standaard van een binnenlandse of buitenlandse standaardsetter, zoals bijvoorbeeld de NV COS en NOREA richtlijnen (uitgegeven door de NBA respectievelijke de NOREA). SOC1 kan worden gekenmerkt als een merknaam, terwijl in internationaal verkeer de onderliggende uitvoeringsstandaard 3402 wordt gehanteerd (Boer & Van Beek, 2013). Het overzicht hierna geeft de verschillende vormen van SOC-rapportages aan, namelijk SOC1, SOC2 en SOC3: Consideration Point Service Organization Controls (SOC) reporting SOC1 SOC2 SOC3 AICPA suggested scope Controls relevant to report users financial statements Controls relevant to compliance or operations, based on AICPA Trust Principles: Security Availability Processing integrity Confidentiality Privacy Purpose of Report Provide information about controls that may be relevant to a user entity s internal control over financial reporting. Provide management, user entities, and other parties information and an independent accountant s opinion on controls at the service organization related to the Trust Principles Provide interested parties an independent accountant s opinion on controls at the service organization Intended Audience Restricted; limited distribution General Use (with public seal); unrestricted distribution Content of Report Description of service organization's system Description of controls Auditor opinion on: fairness of presentation of description Control Design (Type I and II) Control Effectiveness, including description of PwC s test of controls and results (Type II only) Unaudited system description Auditor opinion of controls effectiveness International Audit Standard ISAE3402 (US: SSAE16, NL: COS3402) ISAE3000 (US: AT101, NL: COS3000) Tabel 1: verschillen tussen SOC1 t/m 3 (PwC, 2014) SOC1 is de bekendste SOC-rapportage waarmee menig accountant te maken heeft gehad. Deze rapportage wordt gebruikt om als management en accountant van de gebruikersorganisatie

14 voldoende zekerheid te verkrijgen rondom de processen en controls ingericht bij de serviceorganisatie, ten behoeve van de jaarrekeningcontrole. In een SOC1-rapportage wordt uitgegaan van risico s en beheersdoelstellingen gedefinieerd door de serviceorganisatie. Het doel van een SOC2-rapportage is specifiek gericht op het IT-domein rondom beveiliging, vertrouwelijkheid, integriteit, beschikbaarheid en privacy. Het rapport is bedoeld voor iedere relevante gebruiker zolang hij op basis van zijn kennis en ervaring uit het rapport de juiste conclusies kan trekken. Dit rapport is ook bewust breder bedoeld omdat het vertrouwen opteert te geven over de systemen ingericht bij de serviceorganisatie. Daarnaast is er in tegenstelling tot een SOC1-rapportage een vooraf vastgesteld normenkader waarin de principles en criteria zijn benoemd (beschreven in AT100 van de AICPA). Zowel het SOC2 als SOC3-rapport heeft een beperkte verspreidingskring (waarbij SOC2 dus wel een grotere groep beoogde gebruikers heeft). Dit geldt niet voor een SOC3-rapport wat een openbaar rapport betreft. Het rapport is vergelijkbaar met een SOC2-rapport behalve de lay-out en de beoogde gebruikerskring. Het SOC-rapport betreft een op abstractieniveau beschreven samenvatting van een SOC2-rapport waar op hoofdlijnen inzicht wordt gegeven in de processen ingericht bij de serviceorganisatie. Dit SOC3-rapport is feitelijk bedoeld om als serviceorganisatie te kunnen aangegeven dat zij compliant zijn aan een bepaald niveau van dienstverlening. Een SOC3-rapport geeft geen details over het testwerk verricht door de auditor om werking van controls te toetsen. Om als serviceorganisatie te bepalen welk SOC-rapport geschikt is ten behoeve van de gebruikers kan onderstaande tabel worden gebruikt: HOW TO IDENTIFY THE SOC REPORT THAT IS RIGHT FOR YOU? Will the report be used by your customers and their auditors to plan and perform an audit or integrated audit of your customer s financial statements? Will the report be used by your customers as part of their compliance with the Sarbanes-Oxley Act or similar law or regulation? Will the report be used by your customers or stakeholders to gain confidence and place trust in a service organization s systems? Do you need to make the report generally available or seal? Yes Yes Yes Yes SOC 1 Report SOC 1 Report SOC 2 or 3 Report SOC 3 Report Do your customers have the need for and ability to understand the details of the processing and controls at a service organization, the tests performed by the service auditor and results of those tests? Yes No SOC 2 Report SOC 3 Report Tabel 2: Criteria voor de keuze van het juiste SOC-rapport (AICPA, 2015) Zoals gezegd is de vorm van een SOC1 en SOC2 rapportage gelijk. Dit betekent dat het rapport grotendeels bestaat uit een beschrijving van het systeem, een beschrijving van de beheersdoelstellingen en controls en een assurance-rapport van de auditor (zie tabel 1). Eén van de voordelen van SOC-rapportages is dat het een algemeen bekende vorm is van rapportage waardoor het rapport een algemeen geaccepteerde vorm van verantwoording is. Een SOC1 en SOC2 rapportage kan een type-i of een type-ii rapport betreffen. Type-I betekent dat alleen de opzet en implementatie van controlemaatregelen is getoetst door de auditor. Bij

15 een type-ii rapport is ook de werking van de controlemaatregelen getoetst door de auditor. In het kader van een SOC1-rapportage voor de jaarrekeningcontrole van de gebruikersorganisatie is normaal gesproken een type-ii vereist. Bij een SOC2-rapportage kan dit verschillen. SOC3 kent geen onderscheid. Hier dient altijd door de auditor de werking van controlemaatregelen te worden getoetst. Bij SOC3 hoort ook een seal of keurmerk welke een geregistreerd handelsmerk is van de AICPA waardoor dit niet te gebruiken is in Nederland. Ook heeft de NBA of de NOREA op dit moment nog geen eigen keurmerk geregistreerd. 2.2 Standaarden In de paragraaf hiervoor is aangegeven dat SOC een merknaam is terwijl onderliggende uitvoeringsstandaarden bepalen hoe de auditor zijn werk dient uit te voeren. Zoals weergegeven in tabel 1 in de vorige paragraaf is er voor SOC1 een specifieke uitvoeringsstandaard in internationaal verkeer vastgesteld, namelijk ISAE3402. Dit geldt nog niet voor SOC2 en SOC3 waar de algemene assurance-standaard 3000 wordt gehanteerd. Deze assurance-standaard is een algemeen geaccepteerde uitvoeringsstandaard voor accountants en auditors waarbij de kwalitatieve aspecten van een assurance-opdracht in ogenschouw worden genomen. Om te waarborgen dat de rapportagevorm van het gehele rapport van de serviceorganisatie als dat van de auditor (het assurance-rapport) een algemene vorm heeft zodat dit te begrijpen is voor de gebruikers zijn de NOREA en de NBA gestart met de ontwikkeling van een handreiking om tot een SOC2 (en SOC3)-rapport te komen. Doel is om de vorm van het rapport, evenals de uitvoeringswerkzaamheden van de auditor aan te laten sluiten met een SOC1-aanpak. NOREA richtlijnen In Nederland heeft de NOREA enkele standaarden van de NBA geadopteerd in haar eigen richtlijnen. Dit betreft onder andere COS3000 en COS3402 die zijn overgenomen in NOREA richtlijn 3000 respectievelijk De strekking van deze richtlijnen versus de COS is gelijk Controleraamwerk Voor SOC1 geldt geen vooraf gedefinieerd raamwerk van interne beheersing. Op basis van een risicoanalyse proces stelt de serviceorganisatie een controleraamwerk op wat de auditor vervolgens toetst. Hier kan de auditor uiteraard wel referentie raamwerken gebruiken om vast te kunnen stellen of een controleraamwerk relevante controls bevat en of risico s in voldoende mate worden gemitigeerd. Bij SOC2/3 zijn de beheersdoelstellingen (ook wel criteria genoemd) wel vastgesteld. De controls die deze doelstellingen afdekken zijn echter niet voorgeschreven (overigens zijn wel illustratieve controls benoemd in AT100). Om een nadere invulling te geven aan de te verwachtte controlemaatregelen geïmplementeerd bij een CSP heeft de Cloud Security Alliance (CSA) een Cloud Controls Matrix (CCM) ontwikkeld. De AICPA heeft in samenwerking met de CSA een mapping gemaakt van de CCM met de SOC2 criteria wat de auditor kan helpen in de uitvoering van zijn werkzaamheden maar ook een CSP kan helpen om een generiek SOC2- rapport te realiseren ten behoeve van de gebruikers van de services van haar organisatie (AICPA & CSA, Illustrative Type 2 SOC 2 Report with the Criteria in the Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM), 2014). Privacy 1 Wanneer in dit referaat gesproken wordt over standaard, COS, ISAE of richtlijn 3000 of 3402 worden al deze verschillende (uitvoerings)standaarden en richtlijnen bedoeld

16 Het privacy principle is een lastig aspect in een SOC2-rapportage. Privacy is vooral compliance gedreven, vanuit wet- en regelgeving waardoor het vooral het voldoen is aan regels. De criteria zijn echter opgesteld als doelstellingen waardoor het moeilijk is een match te maken tussen (lokale) wet- en regelgeving en de criteria. Daarnaast verschilt de wetgeving per regio waardoor het moeilijk is al deze aspecten te vatten in één SOC2-rapport. Het is niet voor niets dat het privacy domein sinds januari 2014 in de herziene Trust Services Principles (TSPs) is weergegeven als een apart principle met haar eigen criteria, los van de andere principles (Beal, 2014) 2.4 Verschijningsvormen SOC-rapportages In Nederland zien we voornamelijk SOC1-rapportage verschijnen op basis van standaard Door een toenemende mate van uitbesteding aan serviceorganisaties wordt geschat dat al 50 tot 75% van de transacties van bedrijven geheel of gedeeltelijk worden ge-processed buiten de eigen organisatie. Om deze reden is er steeds meer vraag naar validatie van de uitbestede activiteiten (Fanning, 2014). Daarentegen is er wel een problematiek met betrekking tot de assurance-behoefte versus het aanbod van SOC-rapportages. In de praktijk blijkt bijvoorbeeld een SOC2-rapport moeilijk te begrijpen door de enorm hoeveelheid van detailinformatie waardoor de gebruiker niet meer weet wat hij hier mee moet. De AICPA heeft hier wel getracht iets aan te doen door het aantal criteria van SOC2 terug te brengen tot een aanvaardbaar niveau (Beal, 2014). Daarnaast is er veel meer behoefte aan een keurmerk of seal wat betekent dit bedrijf is in control. Wanneer er behoefte is naar gedetailleerde informatie wordt een ISAE3402 uitvoeringsstandaard gebruikt voor een IT-only-rapport terwijl een SOC2 uitvoeringsstandaard veel logischer lijkt (Lonborg & Avedissian, 2013). Hierna worden enkele voorbeelden besproken met betrekking tot SOC-rapportagevormen in Nederland. Zeker Online Het Keurmerk Zeker Online is opgericht omdat er vraag in de markt was naar een keurmerk. De gebruikers van CSPs, en specifiek dienstverlening omtrent de financiële administraties in de Cloud, hadden behoefte naar zekerheid omtrent meer aspecten dan alleen de financiële risico s omtrent de jaarrekeningcontrole (SOC1) maar ook naar bijvoorbeeld privacy en beschikbaarheid van de Cloud applicatie. Daarnaast was het wenselijk vanwege meer belastingtechnische redenen dat er zekerheid kwam over de juiste werking van de software zodat de belastingdienst hierop kan steunen in het kader van haar onderzoeken bij belastingplichtigen. Zodoende is een controleraamwerk ontwikkeld waarin al deze aspecten zijn opgenomen. Hierover wordt een assurance-rapport verstrekt door een auditor op basis van standaard 3402 (Zeker-Online, 2015). Wat opvalt, is dat er een standaard controleraamwerk is opgesteld welke verschillende controleobjecten afdekken maar slecht in een beperkte mate. Daarnaast is het opvallend dat een assurance-rapport wordt afgegeven op basis van ISAE3402 wat juist een uitvoeringsstandaard is enkel bedoelt voor financiële risico s ten behoeve van de jaarrekening van de gebruikersorganisatie. Uiteraard is het wel zo dat er blijkbaar vraag is naar dergelijke rapportages waarbij ook nog eens een keurmerk wordt afgegeven. Privacy Audit Proof De vraag naar privacy-audits speelt al langere tijd. Zodoende hebben de NOREA en de NBA een privacy audit richtlijn 3600 ontwikkeld. Al enkele jaren worden assurance-rapporten verstrekt

17 door auditors op basis van uitvoeringsstandaard en assurance-standaard 3000 en met behulp van richtlijn Buiten deze verschillende verschijningsvormen van de rapporten blijkt in de praktijk dat de serviceorganisatie een verkregen SOC1 of SOC2-rapport niet op een juiste manier kwalificeert. Zo heeft de ABN AMRO op haar internetsite staan dat zij een ISAE3402-verklaring heeft waardoor geconcludeerd kan worden dat er sprake is van een integere bedrijfsvoering (AMRO, 2015). Dit terwijl er enkel door de auditor een conclusie kan worden getrokken of de controls werken (waardoor financiële risico s worden afgedekt) en of de beschrijving toereikend is. Dit soort voorbeelden geven weer dat er nog een groot risico zit met betrekking tot de verwachtingskloof tussen de auditor en de service- en gebruikersorganisaties. Juist vanwege de onduidelijkheid van zowel auditors als service- en gebruikersorganisatie is de NOREA eind 2014 met een Audit Alert gekomen waarin zij de doelstellingen van een ISAE3402- rapport uitlegt (NOREA, 2014). Hiaten vraag en aanbod SOC-rapportages In de onderstaande tabel is samengevat weergegeven welke hiaten er zijn tussen de vraag en het aanbod van SOC-rapportages op basis van het literatuuronderzoek in dit hoofdstuk: # Hiaten Theoretische onderbouwing 1 Er is ook vraag naar een keurmerk in plaats van een gedetailleerd rapport met controlemaatregelen. Blijkt uit ontwikkelingen zoals Zeker Online 2 De vraag naar privacy-audits is groot terwijl hier nog maar beperkt op wordt gecontroleerd in de huidige SOC-rapportages (zelfs de tip van beroepsorganisaties voor auditors om hier voorzichtig mee om te gaan). Blijkt uit audits op basis van Richtlijn 3600 en Zeker Online. 3 De complexiteit van de criteria en de omvang van het aantal criteria zorgt voor een omvangrijk moeilijk leesbaar SOC2- rapport Blijkt uit de overwegingen van de AICPA om de criteria te versimpelen en het aantal te verminderen (Beal, 2014) 4 ISAE3402-rapportages worden gebruikt om te rapporteren over enkel IT-beheerprocessen of controleraamwerken die meer afdekken dan alleen financiële risico s ten behoeve van de jaarrekeningcontrole (terwijl standaard 3402 hiervoor niet is bedoelt). Blijkt uit rapportagevormen zoals Zeker Online en IT-only rapporten op basis van ISAE Daadwerkelijk gebruik en uitingen omtrent ISAE3402-audits ten opzichte van de werkelijke comfort die hieraan ontleent kan worden (verwachtingskloof) Blijkt uit publicaties zoals de ABM AMRO op haar website (AMRO, 2015). Tabel 3: hiaten volgens literatuur Uit de literatuur blijkt vooral dat aspecten zoals de verwachtingskloof ontstaan zijn uit de leer van het gewekte vertrouwen van Limperg. Een Nederlandse gedachtegang en in mindere mate opgepakt door internationale literatuur. De gedachtegang daarachter is voornamelijk dat ervanuit wordt gegaan dat een auditor goed beschrijft wat de randvoorwaarden van een audit zijn en dit goed kenbaar maakt.

18 2.5 Risico s SOC2/3-rapportages voor IT-auditors en accountants In deze paragraaf zal nader worden ingegaan op de risico s voor de auditors en accountants omtrent SOC2/3-rapportages. De keuze van een SOC-rapportage Alhoewel verschillende SOC-rapportage vormen bestaan met verschillende objecten van onderzoek (financieel versus het IT-domein, zie ook hoofdstukken hiervoor over SOC1t/m3) blijkt in de praktijk dat er veelal wordt gekozen voor een SOC1-rapportage terwijl deze niet altijd passend is (omdat een IT-domein in scope is). Halterman (2011) beschrijft de mogelijkheden van SOC-rapportages en de kans voor auditors om SOC2-rapportages uit te brengen voor dit specifieke domein. Auditors dienen dan echter wel hun verantwoordelijkheid te nemen om een passend assurance-product te bieden en niet te kiezen voor een SOC1- rapportage wanneer deze niet passend is voor het doel van het onderzoek. De criteria die relevant zijn om op te nemen in het specifieke SOC-rapport dient door de auditor nauwlettend te worden beoordeeld. Dit kan lastig te beoordelen zijn waardoor dit een zeker risico voor de auditor met zich meebrengt (Fanning, 2014). Daarnaast dient de auditor zich bewust te zijn van de minimale periode in scope van het rapport zodat de SOC-rapportage relevant is, maar ook om te waarborgen dat er voldoende periode in scope is om de toereikende werking van controls te kunnen toetsen (Halterman, 2011). Software gericht onderzoek Een ander risico voor de auditor betreft het feit dat bij een SOC2/3-rapportage het object van onderzoek de governance en controls rondom security en privacy zijn. Maar juist het harde ITgebied de software of infrastructuur kan elementen bevatten die relevant zijn om te auditen omdat deze risico s met zich meebrengen. Eerder zijn de technologische en proces risico s aangehaald (Sinha, Jaiswal, Gupta, & Chaurasiya, 2011). De procesrisico s mogen dan in een bepaalde mate worden afgedekt door een SOC-rapportage dit geldt echter slechts in beperkte mate voor de technologische risico s. Deze zitten in het (software)systeem geïntegreerd. Een meer software-based benadering waarbij de software het object van onderzoek, inclusief de connectiviteit met andere systemen, is daardoor een relevante andere benadering. De auditor dient bij deze benadering adequate tooling en nieuwe controletechnieken in te zetten (in plaats van enkel interviews en broninspectie) waardoor de audit effectiever maar ook efficiënter wordt (Bachlechner, Thalmann, & Manhart, 2014). Management verantwoordelijkheid Een SOC-rapportage kenmerkt zich door een zogenaamde assertion-based-reporting. Dit betekent dat het management op basis van haar management bewering in het rapport aangeeft dat processen zijn ingericht en het interne beheersingskader adequaat is ingericht en dat controls werken. Ook beweert het management dat zij voldoende management testing methodieken heeft ingericht om tot deze conclusie te komen. Dit kan bijvoorbeeld door de inrichting van een interne audit functie. De auditor doet echter geen uitspraak over de juistheid van deze management bewering maar enkel een uitspraak over het controleraamwerk en de beschrijving van het systeem zoals opgenomen in het rapport. Hierdoor heeft de auditor onvoldoende oog voor de uitspraak van het management in de bewering en de wijze waarop zij zelf comfort heeft verkregen over de werking van controlemaatregelen. De auditor had dit bijvoorbeeld kunnen doen door te spreken met de interne audit functie en haar vastleggingen en controleplan te bestuderen (Sinha, Jaiswal, Gupta, & Chaurasiya, 2011). Risico s voor de auditor In de onderstaande tabel is samengevat weergegeven welke risico s worden ondersteund door literatuur zoals beschreven in dit hoofdstuk.

19 # Risico s Theoretische onderbouwing 1 Te weinig aandacht voor de harde IT-kant van het onderzoeksobject omdat SOC enkel de governance en proceskant van IT belicht. Hierdoor ook te weinig inzet van audit tooling. (Bachlechner, Thalmann, & Manhart, 2014) 2 Beheersdoelstellingen door de serviceorganisatie onvoldoende beschreven of sprake cherry-picking bij de keuze voor criteria. Dit is moeilijk te beoordelen door de auditor. (Fanning, 2014) (Halterman, 2011) Tabel 4: risico s volgens literatuur 2.6 Lessons learned rondom SOC-reporting Tijdens de vervanging van SAS70 in 2011 door de internationale ISAE3402 (en in de US, SSAE16) werd beoogd een aantal zaken scherper neer te zetten om de kwaliteit en duidelijkheid van de rapporten te verbeteren. Een aantal jaren later kunnen we nu evalueren in hoeverre de kwaliteit van deze SOC1-rapportages is verbeterd. Reikwijdte relevant voor de gebruiker Op een ISACA conferentie (Lonborg & Avedissian, 2013) werden de resultaten van ruim twee jaar ISAE3402 en SSAE16 audits gedeeld aan de aanwezigen. Vooral opmerkingen rondom de reikwijdte kunnen worden geplaatst: Worden alle elementen waar de gebruiker vragen over heeft wel gedekt? Worden alle processen welke uitbesteedt zijn wel gedekt? De match tussen de contractuele afspraken / contracten tussen de gebruikers- en serviceorganisatie zijn deze wel gedekt? Is er voldoende onderbouwing voor de sub serviceorganisaties en worden deze terecht wel of niet uitgesloten van het rapport ( carve-out )? Wordt terecht een User Controls Consideration (UCC) beschreven in het rapport en daardoor een gedeeltelijke verantwoordelijkheid belegd bij de gebruikersorganisatie? Naast de opmerkingen over de reikwijdte blijkt het dat in de praktijk niet geheel duidelijk wat het doel is van een assurance-rapport en wat de term certificering nou in werkelijkheid in houdt. Certificeren is het toetsen aan het norm en de onduidelijkheid zit hem tegelijkertijd aan de bekendheid van een norm. Wie bepaalt dat de norm voldoende is? (Ewals, 2013) Beschreven beheersdoelstellingen Zoals ook door Lonborg & Avedissian (2013) aangegeven wordt er in onvoldoende mate aandacht geschonken aan de juistheid van beheersdoelstellingen. Voor een SOC1-rapportage betreft dit de link met de relevante informatie voor de gebruiker van de jaarrekening. Hierbij kan specifieker een link worden gelegd met de assertions van de jaarrekening en de beheersdoelstellingen in het SOC1-rapport. De taak van de auditor is om ook verder te kijken naar de onderliggende proces doelstellingen in plaats van te blijven hangen op het abstracte risiconiveau van de beheersdoelstelling. Vervolgens zijn de controlemaatregelen ook onvoldoende concreet beschreven wat in combinatie met onduidelijke beheersdoelstellingen tot een moeilijk leesbaar SOC-rapport leidt (Ewals, 2013). Beschrijving De beschrijving is een belangrijk onderdeel van het rapport waarin de processen worden beschreven waarin de link dient te worden gelegd met de dienstverlening. Daarentegen mist de diepgang van deze beschrijving en is er onvoldoende een link gelegd met de key controls zoals

20 opgenomen in de controlematrix en de beschrijving van de processen (Lonborg & Avedissian, 2013). De auditor zou meer aandacht moeten schenken aan hetgeen daadwerkelijk mist in de beschrijving. Testwerkzaamheden Wanneer er bevindingen komen uit de testwerkzaamheden wordt onvoldoende in het SOCrapport opgeschreven of: Er mitigerende controlemaatregelen zijn; Welke communicatie er is geweest met de serviceorganisatie over de bevindingen; Zijn de juiste testperiodes gekozen voor de controlemaatregelen. De informatie die daarnaast wordt toegevoegd aan de test tabel is onvolledig waardoor de impact door de gebruikersorganisatie en haar auditor in onvoldoende mate kan worden ingeschat (Lonborg & Avedissian, 2013). Naast het beschrijven van de testwerkzaamheden wordt door de auditor veelal manuele controletechnieken gebruikt op basis van deelwaarnemingen. Bij de toenemende mate van automatisering en daardoor ook het feit dat controleobjecten veelal in een geautomatiseerde omgeving opereren zijn manuele controletechnieken niet alleen meer voldoende om iets te kunnen zeggen over de werking van het systeem en/of controlemaatregelen. Daardoor zijn aanvullende tooling en automatiseringstechnieken nodig om een adequate audit te kunnen uitvoeren (Bachlechner, Thalmann, & Manhart, 2014). Kennis van het controleobject Het object van onderzoek bij een SOC-rapport is gericht op governance, processen en controls. Het systeem van interne beheersing. Dit kan zijn financieel gericht (SOC1) of meer IT-gericht (SOC2/3). De kennis van auditors is volgens Ewals (2013) niet altijd op voldoende. Het komt voor dat zelfs een niet gecertificeerde auditor (geen RA of RE) een assurance-rapport uitbrengt. Daarnaast is er specifiek in het geval van het IT-domein specifieke kennis noodzakelijk om een adequaat oordeel te geven bij een SOC2-rapportage.

21 3 Analyse op basis van eigen praktijkervaringen SOC-rapportering Als accountant ben ik al enkele jaren werkzaam binnen de IT-audit praktijk van ons kantoor. Zodoende heb ik meer dan 4 jaar werkervaring met opdrachten rondom de Administratieve Organisatie en Interne Beheersing (AO/IB) en specifiek assurance-opdrachten hieromtrent. De afgelopen jaren ben ik vooral bij SOC1 (COS3402) opdrachten betrokken en bij enkele adviesopdrachten omtrent SOC2. In dit hoofdstuk zal ik mijn praktijkervaringen met SOC1 nader beschrijven. 3.1 Hiaten tussen de vraag van de service- en gebruikersorganisaties en die van de huidige SOCrapportages In de huidige praktijk van SOC-rapportering in Nederland is voornamelijk het begrip ISAE3402 bekend bij service-, gebruikersorganisaties en auditors. Deze term ISAE refereert echter naar de International Standards of Assurance Engagements van de International Federation of Accountants (IFAC). Na de vervanging van de Amerikaanse SAS70 standaard naar een internationale standaard ISAE3402 is deze term erg bekend geworden in het maatschappelijk verkeer. Deze standaard is bedoeld voor auditors als handvat om een audit uit te voeren rondom de interne beheersing van financiële rapportering ( internal control over financial reporting ). In de praktijk wordt echter gevraagd om een ISAE3402-rapport, wat dit ook zou mogen zijn. Feitelijk vragen gebruikers serviceorganisaties om assurance over processen gerelateerd aan de dienstverlening. De verwijzing naar een assurance-standaard is daardoor erg verwarrend. Zeker omdat in veel landen de ISAE3402 standaard is geadopteerd in de eigen standaarden van de beroepsorganisaties. Zoals in Nederland de COS3402. In de US is dit de SSAE16, waar op enkele kleine aspecten verschillen zitten (hier ga ik in dit referaat niet verder op in). Huishouding op orde In de praktijk is zichtbaar dat serviceorganisaties ISAE3402 of een SSAE16 realiseert om zodoende aan haar klanten te laten zien dat het op orde is. Veelal weet zowel de service- als gebruikersorganisaties niet precies wat dit inhoud. Een ISAE3402-rapport wordt maar zelden goed doorgelezen door een gebruikersorganisatie. Daarnaast heeft een serviceorganisatie onvoldoende aandacht voor de potentiële risico s van hun klanten, maar wordt de risico s voornamelijk vanuit de interne risicoanalyse ingestoken waarna de vertaling voor haar klanten in slechts beperkte mate wordt gemaakt. Dit blijkt bijvoorbeeld uit de beschrijving van de interne beheersing en processen en de zogenoemde user consideration controls (UCC). Deze UCCs zijn vaak onvolledig of onjuist (hierover meer in hoofdstuk 2.3). Gebruik van een SOC1-rapportage Zowel een gebruikers- als serviceorganisatie is niet altijd bekend met het feit dat een ISAE3402- rapportage eigenlijk enkel is bedoeld voor het management en de accountant van de gebruikersorganisatie ten behoeve van de financiële rapportage. Anders gezegd is het rapport ontstaan zodat accountants inzicht hebben in de processen en controlemaatregelen die zijn belegd bij een serviceorganisatie zodat ze deze informatie kunnen gebruiken voor de jaarrekeningcontrole bij de gebruikersorganisatie. De rapportage wordt daarentegen door de serviceorganisatie actief gebruikt om nieuwe klanten binnen te halen. Een SOC1-rapport wordt steeds vaker als een mandatory aspect gezien om als serviceorganisatie überhaupt in de race te zijn om dienstverlening aan te bieden aan toekomstige klanten. De kwaliteit of uitkomst van een SOC-rapport is daarnaast nog geen eens

22 een onderwerp wat belangrijk is voor de uiteindelijke keuze van een toekomstige gebruiker. Alleen de aanwezigheid van het rapport is van belang. Vraag van gebruikersorganisaties Zoals besproken zit de gebruikersorganisatie veel meer te wachten op een bevestiging dat de huishouding van de organisatie op orde is en niet zozeer op de details daarvan. Een SOCrapportage biedt daarentegen enorm veel informatie die een gebruiker zelf dient te interpreteren. Dit is anders dan bijvoorbeeld certificeringen of keurmerken. Een ISO27001/2 certificaat geeft aan dat een organisatie compliant is het raamwerk van informatiebeveiliging. Op welke wijze en of het een schoolcijfer 6 of 10 is speelt geen rol in een dergelijke certificering. Buiten het feit dat de aanwezigheid van een SOC1-rapport vaak belangrijker is dan de inhoud daarvan is de werkelijke vraag naar assurance van gebruikers vaak anders. De beveiliging en privacy-maatregelen bij een CSP worden vaak als zeer belangrijk gezien terwijl een SOC1- rapport hier slechts beperkt in voorziet. De vraag naar andersoortige assurance-producten is zeker aanwezig. Een SOC2-rapport is in een situatie wanneer de serviceorganisatie wilt rapporteren over beveiliging en privacy passender. Een SOC2-rapport wordt echter nog zeer beperkt in Nederland (en ook Internationaal) afgegeven. Een SOC2-rapport is nog niet een algemeen geaccepteerde verantwoordingsdocument van een serviceorganisatie. Een voorbeeld van een SOC-rapportage, een keurmerk en ook nog eens een rapport met zowel controlemaatregelen rondom financiële rapportage als beveiliging en privacy is: Zeker Online. Dit betreft een keurmerk wat wordt afgegeven wanneer op basis van een SOC1-rapportage (Standaard 3402) een goedkeurende assurance-verklaring wordt afgegeven. De reikwijdte van de SOC1 wordt echter verder uitgebreid met beveiliging en privacy maatregelen terwijl SOC1 hier eigenlijk niet voor is bedoeld. Daarentegen is dit wel een voorbeeld waarbij getracht is om de vraag van gebruikersorganisaties en het aanbod van serviceorganisaties en auditors op elkaar aan te laten sluiten. Het keurmerk geeft bevestigd een bepaalde mate van kwaliteit en het SOC1-rapport geeft detailinzicht in de controlemaatregelen. Begrip Toch is het risicovol om als auditor een uitspraak te doen in een assurance-rapport waarin een verklaring dient te worden gegeven over zowel een financieel (SOC1) als een IT-domein (SOC2). In een dergelijk geval dient een auditor een uitspraak te doen over een geheel van controlemaatregelen. Een bevinding kan echter een materiële impact hebben voor het financiële domein terwijl deze impact voor het IT-domein van minder belang is. Het is dan lastig om dit geheel te wegen in één assurance-rapport. Daarnaast is het SOC1 framework ook niet ervoor bedoeld om een uitspraak te doen over het IT-domein. In de praktijk wordt dit nu wel soms gedaan. Het risico bestaat echter dat de gebruikersorganisatie andere waarde gaat hechten aan het rapport dan daadwerkelijk kan op basis van de werkzaamheden. Daarentegen wordt deze discussie ook bemoeilijkt doordat gebruikersorganisaties soms geen assurance-rapport accepteren op basis van ISAE3000. Deze term is vaak onbekend en wordt daardoor niet als voldoende gezien. Wanneer dezelfde werkzaamheden worden uitgevoerd, met dezelfde reikwijdte en er wordt een ISAE3402-rapport afgegeven wordt dit opeens wel geaccepteerd. Wat hieruit blijkt is dat het verschil tussen een assurance-standaard en de term SOC-rapportering, lees: serviceorganisatie controls rapportering, niet wordt begrepen. De assurance-standaard is bekend bij gebruikersorganisaties terwijl dit slechts een standaard is voor auditors door auditors om te zorgen dat er één wijze van rapportage en uitvoer van werkzaamheden bestaat. De gebruiker zou hier eigenlijk niet mee bezig moeten zijn. Een ander aspect waar gebruikers onvoldoende begrip van hebben betreft de impact van bevindingen in een SOC1-rapport op de eigen organisatie. Een risico-inschatting wordt

23 onvoldoende gedaan. Daarnaast wordt de paragraaf user consideration controls (UCC) onvoldoende beoordeeld. Dit terwijl deze informatie zeer van belang is om te bepalen in welke mate er wel maar ook niet gesteund kan worden op het SOC-rapport en welke controlemaatregelen binnen de gebruikersorganisatie voldoende geïmplementeerd moeten zijn. Verwachtingskloof De verwachtingskloof tussen de auditors, service- en gebruikersorganisaties is potentieel erg groot. Voornamelijk omdat we als auditor niet goed uitleggen wat onze assurancedienstverlening precies inhoudt en welke waarde hieraan kan worden gehecht. Daarentegen zijn er ook grote kansen voor auditors als we de assurance-behoefte van gebruikers kunnen afdekken en de risico s rondom de verwachtingskloof goed beheersen. De belangrijkste hiaten rondom de verwachtingskloof zijn in de volgende tabel weergegeven. # Hiaten 1 Vraag van gebruikersorganisatie al lang niet meer alleen naar SOC1 (terwijl wel vaak alleen beschikbaar) maar veel meer naar andere aspecten zoals beveiliging en privacy. 2 Marketingmiddel (of zelfs business case) voor CSP versus een specifiek assurance-product voor een beperkt doel (alleen rapportage of financiële risico s t.b.v. financiële rapportering). 3 Vraag van gebruikersorganisaties is steeds meer naar de AS/IS (of zelfs toekomstige situatie) werking van controlemaatregelen in plaats van de historische werking. 4 Verwachte reikwijdte van de gebruikersorganisatie sluit veelal niet aan met de werkelijke reikwijdte van een assurance-rapport 5 Teveel informatie in SOC-rapportages waardoor de gebruiker de kern van de boodschap onvoldoende kan destilleren uit een rapport voor zijn specifieke situatie. Tabel 5: hiaten rondom de verwachtingskloof 3.2 Risico s SOC2/3-rapportages voor IT-auditors en accountants De verwachtingskloof en de hiaten die daaraan bijdragen, zoals beschreven in voorgaande paragraaf, vormen een serieuze bedreiging voor de auditor en de accountant. Echter buiten de verwachtingskloof zijn er SOC2/3-specifieke risico s voor IT-auditors en accountants. Reikwijdte van een rapport Zoals beschreven in de voorgaande paragraaf kan een beperking in reikwijdte bijdragen aan een hiaat tussen de verwachting van een gebruikersorganisatie en daadwerkelijk geleverde comfort. In de praktijk zien we nu dat organisaties vaak voor bepaalde principles of criteria nog onvoldoende volwassen zijn zodat dit qua verwachting tot bevindingen in het assurance-rapport gaat leiden. Voor een auditor is het in een dergelijk geval wel belangrijk om niet mee te gaan met een beperkte reikwijdte van een assurance-rapport waardoor cherry-picking van processen of systemen kan gaan plaatsvinden. Wanneer een CPS bijvoorbeeld security niet in scope heeft van het TSP framework terwijl dit het algemene principle is met de relevante procedures en richtlijnen is de rol van een auditor weggelegd om de relevantie van een assurance-rapport hieromtrent aan te vechten. Security zal naar verwachting een minimaal principle moeten zijn wat in de reikwijdte is meegenomen. Gebruikers- en verspreidingskring

24 Een groot verschil van SOC1 ten opzichte van SOC2/3 betreft de gebruikerskring. SOC1 is specifiek bedoeld voor het management en de accountant van de gebruikersorganisatie. Dit rapport is ook ontstaan aan de behoefte om assurance te ontvangen over controls bij een serviceorganisatie ten behoeve van de jaarrekeningcontrole van de gebruikersorganisatie. Hierdoor is de gebruikerskring ook vrij nauw bepaald en is het SOC1-rapport ook specifiek geënt op het gebruik van het rapport door een gebruikersorganisatie. De gebruikerskring voor SOC2 is echter op voorhand al breder gedefinieerd door de AICPA, namelijk: These reports are intended to meet the needs of a broad range of users that need information and assurance about the controls at a service organization that affect the security, availability, and processing integrity of the systems the service organization uses to process users data and the confidentiality and privacy of the information processed by these systems. De beoogde gebruikers van een SOC2 rapport zijn naast het management van de gebruikersorganisatie ook diegene die een begrip hebben van: De aard van de dienstverlening van de serviceorganisatie; Hoe het systeem van de serviceorganisatie relateert tot de gebruikersorganisatie, sub serviceorganisatie en andere partijen; Interne beheersing en haar beperkingen; Complementaire user consideration controls en hoe deze relateren tot beheersingsmaatregelen bij de serviceorganisatie en de van toepassing zijnde TSP criteria; De van toepassing zijn de TSP criteria; Het risico van het niet halen van de van toepassing zijnde TSP criteria en hoe beheersingsmaatregelen deze risico s adresseren. De AICPA beschrijft dan ook op basis van bovenstaande dat de beoogde gebruikersgroep breder zou kunnen zijn dan bij SOC1, namelijk: As such, prospective customers, regulators, and other parties with a sufficient knowledge and understanding of the above are intended users of the report and no transmittal letter or release letter is required for the report to provided to these intended users. Deze bredere verspreidingskring brengt ook een zekere mate van risico s mee voor de serviceauditor. Doordat de potentiële gebruiker niet alleen de gebruikersorganisaties en haar auditors zijn kan er ook andere comfort aan een rapport worden ontleend waar op voorhand wellicht niet aan wordt gedacht. Een risicoanalyse aan de voorkant van een assurance-opdracht zal dan ook veel breder uitgevoerd dienen te worden. Een ander risico omtrent dit element betreft het risico rondom toekomstige gebruikers van de serviceorganisatie. Doordat deze partijen tot de gebruikersgroep behoren en daardoor comfort mogen ontlenen aan het rapport wekt de suggestie dat een SOC2-rapport iets zegt over toekomstige werking van beheersingsmaatregelen. Met betrekking tot een SOC3-rapportage is het gebruik nog breder gedefinieerd. Het betreft een rapport zonder beperking in de verspreidingskring en daardoor publieke verkrijgbaar. Daarentegen betreft het rapport een abstract van de beschrijving van het systeem en geen detailinformatie over beheersingsmaatregelen. De serviceauditor dient zich ervan bewust te zijn dat er een potentiële grote groep gebruikers van het rapport aanwezig is, die niet is geïdentificeerd, maar wel comfort ontlenen aan het assurance-rapport als onderdeel van de SOC3-rapportage. Privacy Het privacy criteria is een element wat in de AICPA atteststation-standaard als een apart domein wordt gezien vanwege de compliance gedreven inhoud van het domein. Daarentegen is

25 er wel een duidelijke relatie met beveiligingsmaatregelen, zoals specifiek rondom het domein vertrouwelijkheid. Toch is het privacy domein een risicovol criteria om mee te nemen in een SOC2-rapportage. Doordat privacy een aspect is wat niet te vatten of te beheersen is op basis van beheersingsmaatregelen. Dit komt voornamelijk doordat privacy voor persoon A wat anders betekent dan voor persoon B. Daarnaast is privacy gebonden aan wet- en regelgeving die per land of regio kan verschillen. Kijk alleen al naar de Amerikaanse wet- en regelgeving versus de voorgestelde Europese privacy verordening. Een vertaling van wet- en regelgeving en compliance versus beheersingskaders is lastig te maken, zeker als er ook nog verschillen in de wet- en regelgeving zijn. Als een auditor toch een uitspraak gaat doen over het privacy principle op basis van de SOC2 criteria bestaat een risico dat er een hiaat zit tussen het assurancerapport en de werkelijke behoefte aan comfort rondom het privacy domein. Beveiligingsrisico s Zoals gezegd wordt in een SOC2/3-rapport de beveiliging en privacyaspecten van een serviceorganisatie onder de loep genomen. Zoals staat beschreven in hoofdstuk 2 (theorie) zijn de vijf TSPs onderverdeeld in 7 deelgebieden. Deze deelgebieden zien voornamelijk toe op het organisatorische en reactief vlak rondom de beheersing van de TSPs. Anders gezegd: processen en richtlijnen om adequaat om te gaan met beveiligings- en privacy incidenten. Uiteindelijk gaat het erom dat beveiligingsrisico s zijn beheerst die we nu niet kennen waar adequaat op gereageerd dient te worden. Een information security management systeem (ISMS) is dan het meest primaire wat adequaat ingericht moet zijn. De vraag is in hoeverre bijvoorbeeld een ISO27001/2 certificering niet voldoende is. Control matrices Zoals in de vorige paragraaf aangegeven zijn beveiligingsrisico s aan wijzigingen onderhevig. Een beveiligingslek van vandaag de dag is nu bekend en verholpen met update en patching. Daarentegen gaat het om risico s die nog niet bekend zijn en hoe actief men daarop acteert. Toch zijn er criteria opgenomen in de TSPs welke specifiek ingaan op beveiliging controls die nu relevant zijn maar zijn deze in een periode van tijd nog steeds relevant. De vraag is of een auditor een uitspraak kan doen dat controlemaatregelen een risico afdekken als het risico onderhevig is aan wijzigingen. Dit brengt een potentieel auditrisico mee voor de serviceauditor. Normenkaders Om een nadere invulling te hebben van de criteria naar controlemaatregelen zijn als enkele mappings gemaakt tussen bestaande control frameworks met het SOC2 normenkader. Deze nadere invulling kan inzicht geven aan mogelijke controlemaatregelen die een serviceorganisatie als referentiekader kan gebruiken. De Cloud Control Matrix van de Cloud Security Alliance is een dergelijk voorbeeld die voor CSPs een control mapping heeft gemaakt. Daarentegen bestaat er uiteraard een kans dat dergelijke voorgestelde beheersingsmaatregelen snel niet meer relevant zijn of significant ten opzichte van een criteria. Is een wachtwoordpolicy van minimaal 8 tekens en complexiteit nog wel zo relevant als biometrische kenmerken de toekomst is voor logische toegangsbeveiliging? De auditor dient daarom te allen tijde voldoende aandacht te schenken aan de relevantie van control frameworks in de verschillende specifieke klantsituatie. Nadere control mapping met het SOC2 framework kan verder bijdragen aan het verminderen van de kans dat risico s onvoldoende worden afgedekt door controlemaatregelen. Zeker ook wanneer control mappings en control frameworks met elkaar worden vergeleken. Voorbeelden kunnen zijn normenkaders zoals COBIT5, ITIL maar ook bijvoorbeeld ISO27002 en het Richtsnoer beveiliging van persoonsgegevens (van het college bescherming persoonsgegevens). Kennis van de auditor

26 Een element wat niet onderbelicht moet worden is de kennis van de (IT-)auditor of accountant. Technische IT kennis is bij de beoordeling van de werking van controlemaatregelen is dermate relevant omdat dergelijke IT-controls onderdeel zijn van control frameworks van de serviceorganisaties. De auditor is breed geschoold om over verschillende onderzoeksobjecten een uitspraak te doen. Daarentegen zijn er deep skills nodig om een uitspraak te kunnen doen over het SOC2-domein. Er bestaat een risico dat de auditor zonder inzet van specialisten een uitspraak gaat doen over het SOC2-domein wat mogelijkerwijs niet gegrond is. Een voorbeeld is een accountant die een assurance-verklaring gaat afgeven over SOC2. Zonder adequate scholing of inzet van technische specialisten lijkt dit op voorhand onmogelijk. Assurance-framework In Nederland is er geen apart assurance-framework voor SOC2/3 zoals dat er voor SOC1, op basis van COS3402, wel is. Dit betekent dat er geen standaard voorgeschreven formaat is evenals assurance-standaard die algemeen geaccepteerd is waaronder een dergelijk rapport kan worden uitgegeven. In Amerikaanse context is SOC2/3 wel geadopteerd in de atteststandaarden (die we in Nederland niet kennen). Dit betekent dat we in Nederlandse, maar ook in Internationale context, moeten terugvallen op assurance-standaard Dit betreft een algemene assurance-standaard waar de vrijheid van de keuze van criteria en audit werkzaamheden niet staat voorgeschreven. Er bestaat een risico dat er een wirwar aan verschillende rapportages ontstaan die beogen een SOC2-rapport af te geven. Criteria De rol van een auditor is om te toetsen aan (bekende) normen. Een SOC-rapportage is daarnaast specifiek bedoeld als algemeen bekend rapport waardoor de waarde en de mate van comfort door een gebruiker makkelijker te bepalen is. Bekendheid van de criteria en dus de normen is daardoor erg van belang. De belangrijkste risico s voor de auditor rondom de normenkaders en criteria zijn hierna opgenomen. # Risico s 1 Er is geen Nederlands of Internationaal assurance-framework voor SOC2/3 waardoor er risico s bestaan omtrent de vorm en inhoud en daardoor vergelijkbaarheid van een standaard product rondom de rapportering over controls bij een serviceorganisatie (rondom beveiliging en privacy) 2 Het privacy principle is ingestoken vanuit de Administratieve Organisatie & Interne Beheersing gedachte terwijl dit een compliance gedreven principle betreft. Er bestaat een risico dat de controlemaatregelen onvoldoende de compliance gedreven aspecten afdekken. 3 Beveiligingsrisico s zijn aan wijzigingen onderhevig. Statische normensets dekken potentiële (toekomstige) risico s daardoor onvoldoende af. 4 In hoeverre worden de TSPs geaccepteerd als norm voor de algehele beveiliging- en privacy internationaal bezien. Er zijn voldoende andere controleraamwerken waar separate auditopdrachten door auditors op gedaan kunnen worden. Tabel 6: risico s criteria en normenkaders

27 3.3 Ervaringen SOC-reporting en lessons learned De afgelopen jaren zijn voornamelijk ISAE3402 (of in de US, SSAE16) assurance-rapporten uitgebracht. Mijn eigen praktijkervaringen rondom SOC-reporting, voornamelijk SOC1, wordt nader beschreven in deze paragraaf. Aan het einde van de sub paragraaf worden lessons learned besproken die bruikbaar zijn voor de auditor bij de uitvoer van zijn werkzaamheden. Daarnaast wordt in de opvolgende sub paragraaf aandacht geschonken aan de belangrijkste inhoudelijke aandachtspunten van een SOC-rapport Lessons learned uit SOC-audits De belangrijkste aspecten die nadere aandacht nodig hebben in de SOC-opdrachten kunnen worden onderscheiden op basis van de verschillende fasen van een assurance-opdracht. Opdrachtaanvaarding en risicoanalyse In de fase van de opdrachtaanvaarding is het enorm belangrijk om als auditor het vraagstuk van de opdrachtgever en de gebruiker te identificeren. Dit is een belangrijk onderdeel van de principaal-agent theorie (Eisenhardt, 1989) binnen het accountancy vakgebied en specifiek binnen de relatie tussen serviceorganisaties en gebruikersorganisaties. De gebruikersorganisatie heeft haar processen uitbesteedt aan de serviceorganisatie en wilt dat er een onafhankelijke auditor vaststelt of de serviceorganisatie haar werk goed uitvoert. De auditor is dan wel verplicht om een goede link te leggen tussen wat de serviceorganisatie qua dienstverlening uitvoert, de processen die hieraan ten grondslag liggen, de risico s die zich kunnen voordoen en het interne beheersingskader die deze risico s afdekken (of eventuele andere risicobeslissingen, zoals het afwenden of weerleggen van risico s) (COSO ERM, 2004). Wat ontbreekt, is de adequate beoordeling van de risico-inschatting voorafgaande aan de opdracht door de auditor waardoor de reikwijdte van de opdracht niet altijd adequaat is overeengekomen in de opdrachtbevestiging. De auditor kan bij het uitvoeren van de werkzaamheden erachter komen dat er diensten zijn welke niet zijn opgenomen in de initiële afspraken met de serviceorganisatie. Daarentegen kan het zijn dat deze diensten wel degelijk relevant zijn voor de gebruikersorganisatie. Hierdoor kan er sprake zijn van cherry-picking, daarentegen heeft de auditor al een opdrachtbevestiging met de serviceorganisatie getekend. Toch zou de auditor in een dergelijke situatie zich bewust moeten zijn van zijn rol en in gesprek moeten gaan met de serviceorganisatie. Daarnaast had de auditor op voorhand specifieker moeten toetsen wat de wensen zijn van de gebruikersorganisatie rondom de SOC-rapportage, ondanks het feit dat de verspreidingskring breed is en er niet één gebruiker hoeft te zijn. Sub serviceorganisaties Een ander voorbeeld betreft de sub serviceorganisatie. Bij het lezen van vele SOC1-rapporten blijkt vaak dat er niet wordt gerept over sub serviceorganisaties terwijl deze er in de praktijk vaak wel zijn. Kijk alleen maar op het gebied van technische infrastructuur hosting van de IT van organisaties. De infrastructuur wordt steeds vaker geplaatst in een data center. Wellicht zijn deze (soms enkel fysieke) controlemaatregelen niet significant voor het rapport, maar deze toelichting dient er wel te zijn, evenals de risicoschatting die door de auditor beoordeeld moet zijn. Daarentegen zullen er ook situaties zijn waar de sub serviceorganisatie gewoon niet zijn besproken tussen de auditor en de gebruikersorganisatie en terwijl deze wellicht wel significant zijn. Wanneer sub serviceorganisaties wel zijn toegelicht blijkt niet altijd waarom gekozen is voor een carve-out (alleen monitoring controls opgenomen op de processen belegd bij de serviceorganisatie) of een inclusive methode (alle controls van de sub serviceorganisatie zijn onderdeel van het controleraamwerk van het rapport). Door de ontwikkeling waarbij steeds meer CSP ontstaan die allen deelprocessen van een keten gaan bedienen blijft het wel zaak om

28 adequaat in te schatten of een SOC-rapport zelfstandig leesbaar blijft of dat een verdere carveout geen gevolgen heeft voor de relevantie van het rapport. Beschrijving In de beschrijving van het rapport schrijft de gebruikersorganisatie op hoe de processen, systemen en controleomgeving zijn ingericht. Deze beschrijving vormt integraal onderdeel met de controlemaatregelen die zijn getest door de auditor. De auditor stelt in praktijk vaak vast dat de beschrijving verenigbaar is en dat hier geen aspecten in staan die niet juist zijn. Daarentegen wordt soms onvoldoende controle informatie verzameld om daadwerkelijk aspecten vast te stellen die niet reeds zijn getest bij de controls testing. De auditor moet zich er van bewust zijn dat hij ook een uitspraak doet over de beschrijving en daardoor voldoende werkzaamheden moet verrichten op dit document (ook al wordt dit document vaak aan het einde van de controle pas op een volledige wijze ontvangen van de serviceorganisatie). Een ander element betreft de user control considerations (UCCs). Doet de auditor nou voldoende werk op deze UCCs om vast te stellen dat deze lijst met controlemaatregelen juist maar voornamelijk ook volledig is. Ook hier is het wenselijk dat de auditor meer aandacht schenkt aan deze paragraaf om zodoende de verenigbaarheid met de gebruikersorganisatie vast te kunnen stellen. Het risico bestaat namelijk dat er bewust controlemaatregelen worden beschreven in de UCCs (en daardoor belegd bij de gebruikersorganisatie) terwijl dit vanwege de aard van de dienstverlening van de serviceorganisatie niet gerechtvaardigd is. Uitvoer werkzaamheden De werkzaamheden voor de auditor starten na de opdrachtaanvaarding bij een adequate beoordeling van het risicoanalyse proces zoals ingericht bij de serviceorganisatie. Deze werkzaamheden worden niet altijd diepgaand uitgevoerd waardoor een auditor er later achter komt dat bepaalde controlemaatregelen wellicht niet geheel een beheersdoelstelling (en dus risico) afdekken. Een diepgaande analyse van de risico s versus het controleraamwerk is dus zeer van belang. De auditor kan daarbij ook gebruik maken van bestaande controleraamwerken die ondersteunen in dit analyse proces. Zoals bijvoorbeeld COBIT5 of ITIL wanneer gekeken wordt naar IT beheerprocessen. Bij de uitvoering van de werkzaamheden door de auditor worden niet altijd voldoende deelwaarnemingen gestoken wat gerechtvaardigd is op basis van bewezen testtabellen (op significantie met 5% betrouwbaarheid). Waar auditor A een controlemaatregel zal testen op basis van 1 waarneming kiest auditor B voor een waarneming van 25. Daarnaast verschilt de testmethodiek waar auditor A kiest voor observatie kiest auditor B voor een inspectie. Waarbij de inspectie methodiek veel diepgaandere controle informatie verschaft. De vastlegging van bevindingen voldoet tevens niet altijd aan de gestelde eisen. Bij een bevinding dient het testaantal en het aantal fouten te worden toegelicht door de auditor. In de praktijk ontbreken deze gegevens soms, evenals informatie over eventuele uitbreiding van de deelwaarneming om vast te stellen of een uitzondering als een incident kan worden aangemerkt.

29 Lessons learned Op basis van praktijkervaringen zijn er een aantal aspecten waar de auditor in toekomstige opdrachten rekening mee kan houden. De belangrijkste aandachtspunten zijn opgenomen in de volgende tabel. # Lessons learned 1 Voor de opdrachtaanvaarding een voldoende beeld hebben van de huishouding van de organisatie. Op deze wijze kan adequaat worden bepaald of de reikwijdte en diepgang in lijn is met de dienstverlening van de serviceorganisatie. 2 Specifieke aandacht schenken aan sub serviceorganisaties en vaststellen of deze significante dienstverlening uitvoeren ten behoeve van de serviceorganisatie om zodoende een terechte conclusie te kunnen trekken als auditor omtrent een carve-out. 3 Voldoende diepgaande controledocumentatie verzamelen om de juistheid (en volledigheid) van de elementen uit de beschrijving te kunnen toetsen (niet alleen door middel van interview ). 4 Significant voldoende deelwaarnemingen nemen op basis van best practices binnen het accountancyvakgebied welke eveneens statistisch zijn onderbouwd. Daarnaast zoveel mogelijk diepgaande controletechnieken gebruiken indien mogelijk en combinatie met nieuwe audit tooling. 5 Diepgaande review uitvoeren van de risicoanalyse zoals opgesteld door de serviceorganisatie. Op deze wijze kan de auditor verassingen achteraf voorkomen, zoals: onvoldoende controlemaatregelen die een beheersdoelstelling afdekken. Tabel 7: Lessons learned SOC-reporting Inhoud van een SOC-rapport De inhoud van een SOC-rapport verschilt nogal. Een rapport van salarisverwerker A kan qua inhoud dermate verschillen ten opzichte van salarisverwerker B. Terwijl dit niet in lijn der verwachting ligt. Reikwijdte Een element wat soms verschilt is de periode in scope van het rapport. Doordat SOC1- rapporten worden gebruikt door het management en de auditor van gebruikersorganisatie ten behoeve van de jaarrekeningcontrole dient het rapport soms snel na het einde van het boekjaar aanwezig te zijn. In de praktijk is het onmogelijk om als serviceauditor tijdig te rapporteren over de werking van controls. Er wordt dan gekozen om de periode in scope te verkorten tot bijvoorbeeld november of oktober (wanneer boekjaar gelijk aan kalenderjaar). De relevantie van een rapport met een kortere looptijd is ten behoeve van een jaarrekeningcontrole echter niet bewezen. Op basis van de NV COS dienen controlemaatregelen waarop gesteund wordt voor de gehele periode getest zijn. Waarom dan een SOC1-rapport met een kortere looptijd? Hetzelfde geldt voor SOC2/3-rapporten. De periode in scope van het rapport moet wel relevant genoeg zijn voor de gebruiker. Dit is dus een aspect wat een belangrijke onderdeel zou moeten zijn in de mobilisatiefase van een SOC-opdracht van de auditor. Carve-out en inclusive method Zoals in de sub paragraaf hiervoor besproken worden de sub serviceorganisaties niet altijd goed toegelicht in het rapport. Inhoudelijk is dit een belangrijk element van het rapport omdat een goede toelichting duidelijk maakt welke dienstverlening door welke serviceorganisaties worden uitgevoerd. Zeker bij CSPs komt het vaak voor dat bepaalde dienstverlening is uitbesteed. Zo is

30 er vaak een aparte hosting partij van een data center ten opzichte van het data center zelf. Vervolgens kan het ook nog zijn dat technisch of functioneel beheer weer aan twee verschillende partijen is uitbesteed. Adequate toelichting in het rapport van de specifieke dienstverlening en de dienstverlening uitgevoerd door sub serviceorganisaties is daarom zeer van belang. Beschrijving In de beschrijving ( system description) dient de serviceorganisatie de dienstverlening en processen te beschrijven ter onderbouwing van de interne controlemaatregelen die tevens in het rapport zijn opgenomen en gecontroleerd zijn door de auditor. Deze beschrijving geeft echter niet altijd alle wenselijke elementen weer die noodzakelijk zijn voor het gewenste inzicht richting de gebruikersorganisaties. De koppeling dienstverlening, versus de processen die dit ondersteunen versus de interne controlemaatregelen die de risico s afdekken wordt niet altijd op een adequate manier beschreven in de beschrijving. Daarnaast is niet altijd de controleomgeving op een adequate manier weergegeven waarin het risicoanalyseproces een van belang onderdeel is. In de bevestiging van het management ( management assertion ) bevestigt het management dat zij voldoende testwerkzaamheden heeft (laten) uitvoeren om vast te kunnen stellen dat het beheerskader voldoende is en dat controlemaatregelen werken. Een nadere toelichting ontbreekt of is vaak summier opgenomen in de beschrijving. Een onderdeel in de beschrijving betreft de zogenoemde user control considerations (UCCs). Deze controlemaatregelen zijn overwegingen voor de gebruikersorganisaties omtrent controlemaatregelen waarvan de serviceorganisatie verwacht dat deze zijn ingericht bij de gebruikersorganisaties. Deze controls zijn veelal bepaald op basis van de dienstverlening en de contractuele afspraken hieromtrent tussen de service- en gebruikersorganisatie. De toelichting en verenigbaarheid van deze UCCs met de rest van het rapport is echter niet altijd geheel duidelijk. Een nadere toelichting en link met de dienstverlening is een aspect wat nadere aandacht nodig heeft. Inhoud SOC-rapporten Op basis van praktijkervaringen kunnen de inhoudelijke aspecten van de SOC-rapporten op bepaalde elementen sterk verbeteren. De vijf belangrijkste aspecten die nadere aandacht dienen te krijgen in toekomstige SOC-rapportages, en waar de auditor dus meer aandacht aan dient te schenken in zijn audit, zijn hierna weergegeven. # Inhoudelijke aspecten van een SOC-rapport ter verbetering 1 De reikwijdte van de processen en controlemaatregelen in het rapport dienen vollediger en juister te worden toegelicht. 2 De sub serviceorganisaties en de redenen voor een carve-out dienen specifieker en beter te worden toegelicht in de SOC-rapportage 3 De link tussen de dienstverlening van de serviceorganisatie versus de processen, systemen en interne beheersing kan adequater worden toegelicht. 4 Een nadere toelichting van het management op de wijze waarop het management voldoende werkzaamheden heeft verricht om vast te stellen dat het interne beheersingskader voldoende is ingericht. 5 De UCCs kunnen vollediger en juister worden toegelicht door de serviceorganisatie waarbij een aansluiting wordt

31 gezocht op de contractuele afspraken van de dienstverlening met de gebruikersorganisatie. Tabel 8: Inhoudelijke aspecten ter verbetering SOC-rapporten 3.4 Voordelen en mogelijkheden van SOC-rapportages Buiten de risico s die er zijn voor auditors, evenals aspecten die verbeterd moeten worden in de audits rondom de interne beheersing van serviceorganisaties, liggen er ook enorme kansen. De vraag naar assurance over verschillende aspecten neemt de aankomende jaren alleen maar toe. Door de opkomst van CSPs en de ontwikkeling van the internet of things (The Internet of Things, sd). Ieder apparaat of systeem zal op den duur een verbindingsmogelijkheid tot het internet hebben. Dit is niet alleen praktisch voor het aansturen van deze apparaten maar ook om de denkkracht (processor) en opslagkracht elders vast te leggen in plaats van in ieder individueel systeem. Hierdoor kunnen de kosten omlaag van bijvoorbeeld huishoudelijke apparaten. Om zeker te weten dat jouw data veilig staat opgeslagen en dat de processor wel werkt op het moment dat je aan de slag wilt met een apparaat is het wel van belang dat je zeker weet dat het systeem werkt en dat je data veilig staat opgeslagen. Dit zijn allemaal kansen voor auditors om deze processen en systemen te controleren. Maar ook de laag daaronder. De technische en infrastructurele kant van IT die the internet of things mogelijk maken. Voor auditors is het dus vooral zaak om aan te haken bij technologische ontwikkelingen en de vraag naar assurance. We zijn nu in de fase waarop de audit wordt gerobotiseerd door middel van tooling en data-analyses (De Boer, 2014), dit kan ook in het kader van SOC-reporting uiteindelijk leiden tot continuous assurance.

32 4 Informatie verkrijgende en toetsende interviews In dit hoofdstuk wordt het conceptueel model geoperationaliseerd op basis van de praktijkervaringen (zoals besproken in hoofdstuk 3) en het theoretisch kader (zoals geschetst in hoofdstuk 2). Op basis van interviews met subject matter experts van diverse (grote) accountants- en adviesorganisaties wordt het geoperationaliseerd model getoetst. 4.1 Geoperationaliseerd model De huidige SOC-rapportages zijn nog vrij nieuw in Nederland. Sinds 2011 is SAS70 vervangen door ISAE3402 en rapportages zoals SOC2 en SOC3 zijn eigenlijk nauwelijks nog uitgegeven in Nederland. Hierdoor is ervoor gekozen om de interviews met subject matter experts zowel informatie verkrijgend als toetsend te gebruiken. Dit betekent dat de helft van de interviewtijd gebruikt is om het conceptueel model verder vorm te geven op basis van de informatie verkregen van de geïnterviewde. In de tweede helft van het interview is het model getoetst op basis van de reeds beschikbare informatie en criteria zoals opgenomen in het geoperationaliseerde model. Zie hoofdstuk 2 en hoofdstuk 3 voor de reeds beschikbare aspecten relevant voor het conceptueel model (hoofdstuk 1). Bij de beantwoording van de deelvragen en hoofdvraag in hoofdstuk 5 en 6 zullen de uitkomsten worden besproken waardoor ervoor is gekozen om het conceptueel model niet verder te operationaliseren. 4.2 Interviews subject matter experts SOC Details van de interviews zijn opgenomen in bijlage A. Per geïnterviewde is een samenvatting opgenomen van de belangrijkste uitkomsten uit het interview. Hierna wordt gescored of op basis van de interviews een element als een hiaat, risico of lessons learned is aangemerkt ter toetsing van het model. Daarnaast zijn elementen toegevoegd aan het model naar aanleiding van de interviews. De interviews zijn gehouden met 7 experts welke tevens zitting hadden in de SOC2-werkgroep van de NOREA (en NBA). Wanneer een nieuw aspect op basis van de interviews door meer dan één geïnterviewde is benoemd is dit als hiaat, risico of lessons learned opgenomen in de hier opvolgende paragrafen. Wanneer een al beschreven aspect minimaal tweemaal is genoemd door een geïnterviewde is de hiaat, het risico of de lessons learned op basis van het toetsend onderzoek als bewezen beschouwd Hiaten In de tabel in bijlage B zijn de hiaten tussen de vraag naar SOC-rapportages en het aanbod van SOC-rapportages weergegeven op basis van de literatuur en eigen praktijkervaringen. In de tabel in bijlage B is daarnaast door middel van een letter weergeven of een hiaat op basis van het informatie verkrijgende deel van het interview is vastgesteld. Alleen wanneer een hiaat meer dan één keer is benoemd door twee verschillende geïnterviewden is deze opgenomen in de tabel als een nieuw mogelijk hiaat. Op basis van het informatie verkrijgende gedeelte van het interview zijn er twee nieuwe hiaten vastgesteld, namelijk: De behoefte is er meer naar softwarecertificatie en/of een productgericht onderzoek naar het systeem in plaats van een SOC-rapportage (wat procesgericht is) (driemaal vastgesteld op basis van de interviews); en Daarnaast blijkt er een behoefte naar betaalbare rapporten in plaats van dure controleopdrachten om tot een SOC-rapportage te komen (tweemaal vastgesteld op basis van de interviews).

33 Naar aanleiding van het toetsend onderzoek zijn er twee hiaten niet bewezen (zie bijlage B voor verdere details) Risico s In de tabel in bijlage B zijn de risico s voor accountants en auditors weergegeven op basis van de literatuur en eigen praktijkervaringen. In de tabel in bijlage B is daarnaast door middel van een letter weergeven of een risico op basis van het informatie verkrijgende deel van het interview is vastgesteld. Alleen wanneer een risico meer dan één keer is benoemd door twee verschillende geïnterviewde is deze opgenomen in de tabel als een nieuw mogelijk risico. Op basis van het informatie verkrijgende gedeelte is er één nieuw risico s vastgesteld, namelijk: De achterliggende details van een SOC3-rapport (zoals toets resultaten van een auditor) zijn niet beschikbaar. Hierdoor bestaat een risico dat onjuiste conclusies worden ontleend op basis van dit rapport. Naar aanleiding van het toetsend onderzoek zijn er drie risico s niet bewezen (zie bijlage B voor verdere details) Lessons learned In de tabel in bijlage B zijn de lessons learned rondom SOC-reporting van de afgelopen jaren weergegeven. Deze lessons learned zijn beschreven naar aanleiding van het literatuuronderzoek en eigen praktijkervaringen. In de tabel in bijlage B is daarnaast door middel van een letter weergeven of een lessons learned op basis van het informatie verkrijgende deel van het interview is vastgesteld. Alleen wanneer een lessons learned meer dan één keer is benoemd door twee verschillende geïnterviewde is deze opgenomen in de tabel als een nieuwe lessons learned. Op basis van het informatie verkrijgende gedeelte is er geen nieuwe lessons learned geadresseerd.

34 5 Beantwoording van onderzoeksvragen In dit hoofdstuk worden de deelvragen beantwoord op basis van de informatie verkrijgende en toetsende interviews zoals beschreven in hoofdstuk Beantwoording In hoofdstuk 1 zijn de deelvragen beschreven van dit onderzoek om uiteindelijk de probleemstelling te kunnen beantwoorden. De deelvragen worden in de volgende sub paragrafen beantwoord op basis van het literatuuronderzoek in hoofdstuk 2, de eigen waarnemingen beschreven in hoofdstuk 3 en de interviews gehouden zoals beschreven in hoofdstuk Deelvraag 1: Hiaten vraag en aanbod SOC-rapportages De volgende deelvraag is verwoord voor dit onderzoek: Welke hiaten zitten er tussen de vraag naar assurance-producten van Cloud Service Providers (CSPs) en de gebruikersorganisaties versus de huidige controle- en assurance-standaarden (en richtlijnen)? De daadwerkelijke vraag van CSPs en hun gebruikers versus het daadwerkelijke aanbod van SOC-rapportages op het moment binnen de standaarden geldig hier in Nederland lijken nogal te verschillen. De behoefte naar zekerheid omtrent de processen uitbesteedt aan een serviceorganisatie is groter dan het aanbod aan SOC-rapportages. De belangrijkste hiaten tussen de vraag en het aanbod zijn: 1. Veel verschillende stakeholders met verschillende assurance-behoeften willen op enige manier over verschillende onderwerpen comfort ontvangen. Dit is niet alleen de procesmatige kant van processen en controls ingericht bij de serviceorganisatie maar kan bijvoorbeeld ook de softwarematige kant van systeem settings betreffen; 2. Om deze redenen is het ook zo dat er meer comfort aan een SOC-rapport wordt ontleend dan eigenlijk op basis van het onderzoek van de auditor gegrond is (verwachtingskloof). Dit kan worden veroorzaakt doordat gebruikers de functie van het SOC-rapport niet snappen en bijvoorbeeld een SOC1-rapportage gebruiken ter bevestiging dat de dienstverlening van de serviceorganisatie op een veilige manier plaatsvindt. Daarvoor is een SOC1-rapport echter niet primair bedoeld maar meer ten behoeve van de financiële rapportage risico s van de gebruikers van de serviceorganisatie (en haar accountants); 3. De vraag naar assurance groeit, maar tegelijkertijd ook de roep naar keurmerken of seals. Een bevestiging voor de gebruikers dat de transacties die door de serviceorganisatie worden verwerkt op een veilige en betrouwbare wijze worden afgewikkeld. De behoefte naar details is daarbij niet altijd aanwezig. Een bevestiging is voldoende. De huidige SOC-rapportages geven juist wel die enorme detailinformatie inclusief een assurance-rapport waarbij de gebruiker zelf nog altijd de bevindingen dient te interpreteren in relatie tot haar eigen organisatie. Een uitzondering betreft de SOC3-rapportage wat minder detail geeft. Daarentegen is er in Nederland nog geen SOC3-rapportage uitgebracht (of een geaccepteerd keurmerk/product); 4. Gebruikers hebben steeds meer een continuous-assurance behoefte. Een uitspraak over het verleden op basis van een SOC-rapportage heeft minder toegevoegde waarde. Zeker geldt dit in het IT-domein bij SOC2/3. Het hier en nu is daarbij veel belangrijker (evenals de adequate reactie van bijvoorbeeld incident response).

35 Minder significant aangetoond maar zeker niet onbelangrijk is de behoefte die serviceorganisaties hebben naar betaalbare assurance-producten. De huidige SOC-rapportages worden als duur beschouwd wat ook weer wordt veroorzaakt doordat bestaande SOCrapportages een standaard behoefte afdekken, terwijl de vraag juist naar meer specifiekere assurance-producten is. Dit kan mogelijkerwijs leiden tot specifiekere toewijsbare kosten per assurance-deliverable. Een voorbeeld van een specifieker product kan zijn de softwarecertificatie. Naast de behoefte om te weten of processen en controls adequaat zijn ingericht is er ook vraag naar de controle van het systeem zelf. Softwarecertificatie zou verder ontwikkeld kunnen worden tot een algemeen geaccepteerd assurance-product. Zodoende kan ook worden voorkomen dat bijvoorbeeld standaard 3402 wordt gebruikt voor softwarecertificering terwijl deze hier eigenlijk niet voor is bedoeld Deelvraag 2: Risico s voor auditors SOC2/3 De volgende deelvraag is verwoord voor dit onderzoek: Welke risico s zijn er aangaande SOC2 en SOC3-rapporten die aandacht behoeven en dienen te worden geadresseerd in een handreiking voor IT-auditors en accountants? Voor IT-auditors en accountants zijn er kansen om ook in Nederland SOC2/3-rapportages uit te brengen. Door de enorme groei van het aantal CSP en het feit dat steeds meer transacties buiten de eigen onderneming worden verwerkt betekent meer vraag naar assurance over de processen en systemen ingericht bij serviceorganisaties. Er zijn echter ook enkele risico s te benoemen waar auditors zich voldoende van bewust moeten zijn. De belangrijkste risico s zijn: 1. Er is te weinig aandacht in de audit voor de architectuur van het systeem (de harde IT-kant van het onderzoeksobject) en de systeem settings. Dit is te merken door het beperkte gebruik van audit-tooling om deze productmatige kant van de software te toetsen (de risico s in de software worden hierdoor mogelijkerwijs niet ontdekt); 2. Er zijn onvoldoende mappings tussen de SOC2/3 doelstellingen/criteria met andere controleraamwerken beschikbaar waardoor de acceptatie van de Trust Services Principles (van SOC2/3) niet gegarandeerd is als geaccepteerde internationale norm voor beveiliging en privacy. Daarnaast veroorzaakt dit risico dat auditors onvoldoende referentie controleraamwerken kunnen gebruiken om vast te stellen dat een doelstelling daadwerkelijk is gemitigeerd door een controlemaatregel; 3. Het SOC2/3-domein vergt een verregaande kennis van het IT-object van onderzoek. De auditor dient hiervan bewust te zijn voorafgaande de opdrachtacceptatie. Daarnaast dienen accountants zich nader af te vragen of SOC2/3 een onderzoeksdomein is waar zij op basis van hun kennis een uitspraak over kunnen doen. Voor IT-auditors ligt hier een kans om een assurance-product te bieden. Wel blijft diepgaande kennis rondom het IT-domein een belangrijk element om rekening mee te houden bij de teamsamenstelling; 4. De SOC2/3-rapportages hebben een bredere gedefinieerde groep van gebruikers waardoor mogelijkerwijs meer verzekeringsrisico s aanwezig zijn voor de auditor. Wanneer er zich een incident voordoet binnen een serviceorganisatie kan het zijn dat de gebruikers direct de verzekeringspremie opeisen bij de auditor omdat hij zijn assurance-rapport heeft verstrekt bij het SOC-rapport. Dit is niet het primaire doel van het SOC-rapport, het is geen verzekeringspremie, zo kan dit echter wel worden ervaren. Er zijn ook enkele risico s die minder significant zijn aangetoond. Daarentegen zijn deze nog wel steeds relevant. De beveiligingsrisico s zijn aan continue wijzigingen onderhevig. Precies om

36 deze redenen zit hier een risico in voor SOC2/3-rapportages. De statische normensets dekken (toekomstige) risico s slechts beperkt af waardoor er een verwachtingskloof ontstaat met de gebruiker van het SOC-rapport). Bij een SOC3-rapport zijn er geen nadere details toegevoegd over de testresultaten en controlemaatregelen. Dit brengt een risico met zich mee dat een onjuiste conclusie aan dit rapport worden verbonden. Er zijn slechts een beperkt aantal SOC-rapporten waarin de afgelopen jaren het privacy domein is opgenomen. Dit wordt voornamelijk veroorzaakt doordat het privacy principle is ingestoken vanuit de Administratieve Organisatie & Interne Beheersing (AO/IB) gedachte terwijl dit een compliance-gedreven (door wet- en regelgeving) principle betreft. Er is een groot risico dat de criteria van het privacy principle niet alle minimale aspecten van de lokale wet- en regelgeving afdekt. Daarnaast is het bijna onhaalbaar om compliant te zijn aan alle internationale privacywetgeving (tegelijkertijd). Voor de auditor is het daardoor een groot risico om over het privacy domein assurance te verlenen Deelvraag 3: Lessons learned SOC-rapportages De volgende deelvraag is verwoord voor dit onderzoek: Van welke lessons learned rondom SOC1-reporting, binnen de huidige Nederlandse controleen assurance-standaarden (en richtlijnen), kunnen we als auditors leren om een kwalitatief goed SOC2 of SOC3-rapport af te geven? Sinds 2011 zijn er vele SOC1-rapportages uitgebracht op basis van ISAE3402. De ervaringen en leerpunten zijn divers maar zijn vaak gericht op het adequaat bepalen van de reikwijdte van de opdracht, door: 1. Het beter beschrijven van de reikwijdte van de processen en controlemaatregelen opgenomen in het rapport. Daarnaast kan de link gelegd worden met de dienstverlening van de serviceorganisatie ten opzichte van de contracten met de gebruikers. De auditor dient deze link tussen de dienstverlening, systemen, processen en controlemaatregelen beter vast te stellen; 2. De auditor dient op een adequate wijze te toetsen welke sub serviceorganisaties er zijn en te bepalen of deze onderdeel moeten zijn van het rapport van de serviceorganisatie (inclusive methode) of dat deze uitgesloten mogen worden (carve-out) omdat de sub serviceorganisatie geen significant onderdeel is van de dienstverlening van de serviceorganisatie. Uiteraard dient de serviceorganisatie deze analyse eerst zelfstandig beter uit te voeren alvorens de auditor hier een controle op doet. De toelichting van sub serviceorganisaties dient beter te worden toegelicht in het SOC-rapport; 3. De user control considerations (UCCs) dienen vollediger en juister te worden toegelicht in de beschrijving van het rapport. De auditor kan op basis van de carve-out van sub serviceorganisaties en verantwoordelijkheden zoals opgenomen in de contractafspraken met gebruikers toetsen of de UCCs plausibel zijn. Al deze drie elementen hebben effect op de bepaling van de reikwijdte van het rapport alvorens de auditor tot toetsing van de controlemaatregelen over gaat. Als deze bovenstaande elementen onvoldoende worden opgepakt bestaat er een risico dat de controlematrix niet volledig of juist. Als de auditor over is gegaan op het toetsen van de controlemaatregelen dient meer aandacht te worden geschonken aan de testmethodes, het aantal deelwaarnemingen dat wordt genomen en de inzet van audit tooling. Meer diepgaandere controletechnieken kunnen worden gebruikt. Dit geldt zeker wanneer het IT-domein wordt onderzocht en onderdelen in de architectuur en software dienen te worden vastgesteld. De testresultaten van de auditor dient hij op een duidelijke en adequate wijze te adresseren in het rapport. De vertaling naar het oordeel in het

37 assurance-rapport dient te verbeteren (waardoor de gebruiker dit niet zelf hoeft te interpreteren). Het element wat vaak onderbelicht is in een SOC-rapportage betreft de management bewering ( assertion ). Het management verklaart een adequaat beheersingskader te hebben ingericht en hier voldoende management testing op gedaan te hebben om te kunnen concluderen dat controlemaatregelen werken. De auditor dient veel meer onderbouwing op te vragen om de bewering van het management te toetsen. Dit kan bijvoorbeeld door het beoordelen van de audit resultaten van de interne audit functie (indien aanwezig).

38 6 Conclusies en aanbevelingen Op basis van praktijkervaringen (hoofdstuk 2) en een theoretisch onderzoek (hoofdstuk 3) is het conceptueel model zoals beschreven in hoofdstuk 1 geoperationaliseerd en getoetst op basis van interviews (zie hoofdstuk 4). In hoofdstuk 5 zijn de deelvragen beantwoord. Tot slot wordt in dit hoofdstuk de probleemstelling beantwoord. Daarnaast worden enkele aanbevelingen gedaan op basis van de interviews om de hiaten, risico s of lessons learned op te volgen. 6.1 Beantwoording probleemstelling De volgende probleemstelling is verwoord voor dit onderzoek: Welke knelpunten dienen nader te worden onderzocht om zodoende, binnen de Nadere Voorschriften Controle- en Overige Standaarden en de NOREA-richtlijnen, een Service Organization Controls-rapport (SOC-rapport) te kunnen uitbrengen rondom de aspecten beveiliging, beschikbaarheid, (data) integriteit, vertrouwelijkheid en privacy. Het is mogelijk om binnen het Nederlandse wettelijke kader een SOC-rapport uit te brengen waarin de aspecten beveiliging, beschikbaarheid, integriteit, vertrouwelijkheid en privacy centraal staan. Een SOC-product wat bij deze vraag aansluit is reeds enkele jaren geleden op de markt gebracht door de AICPA (de Amerikaanse beroepsorganisatie voor accountants) en aangeduid met SOC2 (detailrapportage controlemaatregelen) of SOC3 (samenvatting of abstract van de criteria). Hierbij wordt gebruik gemaakt van een standaard normenkader die worden aangeduid als de Trust Services Principles (TSPs) en zijn opgenomen in de Amerikaanse attest-standaard (AT100). Een accountant of IT-auditor kan in Nederland op basis van COS3000 of NOREA richtlijn 3000 een assurance-rapport uitbrengen met als normenkader de TSPs zoals opgenomen in AT100. Om ervoor te waken dat er een standaard SOC2-rapportage, erkend en herkend door de markt, circuleert binnen het internationale verkeer met assurance-rapporten uitgegeven in Nederland is het van belang om een herkenbaar SOC2-product op te leveren. Daarom is het verstandig om voor de vorm van het SOC2-rapport COS3402 of NOREA richtlijn 3402 als basis te gebruiken. Deze vorm is herkenbaar voor de gebruikers (namelijk identiek aan SOC1). Deze vorm is tevens zo bedoeld door de AICPA toen zij dit product in de VS presenteerde. Waar de auditor wel voor dient te waken is de verwachtingskloof met de gebruikers van de SOC-rapporten. Het rationele doel van de opdracht tot de beoordeling van de beschrijving en controlemaatregelen ten behoeve van een SOC2-rapport dient daarom altijd te worden vastgesteld en de auditor dient na te gaan of de behoeften van de gebruikers in voldoende mate worden gedekt. De volgende knelpunten dienen nog nader te worden onderzocht: Op dit moment is het uitbrengen van een SOC3-rapport in Nederland niet mogelijk doordat het SOC3 handelsmerk beschermd is door de AICPA. Aangezien er wel vraag is naar keurmerken of seals in het maatschappelijk verkeer is nader onderzoek noodzakelijk om na te gaan of een SOC3-keurmerk binnen afzienbare tijd ook in Nederland door een auditor kan worden uitgegeven; Om het SOC2/3 object van onderzoek goed te kunnen controleren is een diepgaande IT kennis nodig. Iedere auditor dient zich af te vragen of hij deze kennis voldoende beschikt of dat er aan het controleteam deze kennis dient te worden toegevoegd. Accountants mogen op basis van hun opleiding en status assurance-rapporten afgeven bij dergelijke SOC2/3-rapporten. Daarentegen dient nader te worden onderzocht of dit wenselijk is op basis van de beperkte kennis van het IT-domein. Daarentegen kunnen IT-auditors juist de kans pakken om op dit domein assurance te verlenen. Nadere

39 opleidingseisen kunnen wellicht worden gedefinieerd om vast te stellen of je als individuele auditor voldoende kennis en ervaring hebt om een SOC2/3-opdracht te aanvaarden. Verdere scholing kan tevens helpen om dit risico af te dekken. In de opleidingen voor IT-auditor en accountant kan meer aandacht worden geschonken aan auditing vaardigheden en specifieke IT-kennis rondom dit object van onderzoek; Er zijn slechts een beperkt aantal mappings, tussen bestaande en erkende, controleraamwerken en de TSPs en criteria beschikbaar. Een voorbeeld betreft de Cloud Control Matrix van de Cloud Security Alliance. Deze mappings zijn echter nog vrij onbekend in Nederland en daarnaast ontbreken mappings met andere erkende controleraamwerken zoals bijvoorbeeld COBIT5 en ITIL. De auditor dient referentie raamwerken beschikbaar te hebben om te kunnen toetsen of doelstellingen (of criteria) in voldoende mate worden afgedekt door controlemaatregelen. Daarnaast biedt de beschikbaarheid van mappings het voordeel dat deze bekend kunnen zijn in het internationaal verkeer waarin SOC-rapportages zich verspreiden waardoor de vergelijkbaarheid van SOC-rapportages toeneemt. De beroepsorganisatie NOREA kan een belangrijke rol spelen in het actualiseren van mappings van controleraamwerken met de TSPs en criteria; Het privacy principle en criteria zijn opgesteld in een Amerikaanse context. Daarnaast zijn de criteria geselecteerd op basis van governance en processen. Daarentegen is het privacy vraagstuk veel breder en vaak gedreven door lokaal gedreven wet- en regelgeving. Deze regelgeving is per regio ook weer verschillend. Er is een mogelijke mismatch tussen de privacy criteria en de wet- en regelgeving. Daarnaast zijn er contradicties tussen de verschillende landen in wet- en regelgeving. Hierdoor bestaan er risico s voor de auditor dat de criteria en maatregelen niet alle lokale wet- en regelgeving internationaal afdekken. Dit terwijl een SOC2/3-rapport wel beoogt internationaal geaccepteerd te zijn. Een nadere analyse dient gemaakt te worden naar de risico s omtrent het opnemen van het privacy principle en criteria in een SOC2/3- rapport alvorens een auditor hier assurance over kan verlenen. Doordat SOC2/3-rapportages een breder gedefinieerde groep van gebruikers heeft zijn er meer risico s verbonden aan het uitbrengen van een assurance-rapport door de auditor ten opzichte van bijvoorbeeld een SOC1-rapport (beperkte groep van beoogde gebruikers). Daarnaast wordt een SOC-rapportage door de gebruikers soms als een verzekeringspremie gezien wat een aanvullend risico met zich meebrengt. Zeker wanneer je als auditor niet precies weet wie tot die brede gebruikerskring hoort en het SOC2/3-rapport verschillende assurance-behoeften vervult. Dit kan leiden tot een mogelijke onjuiste reikwijdte van het rapport (qua processen maar ook periode in scope) of een onterechte conclusie of oordeel in het assurance-rapport. Op basis van dit onderzoek zijn er enkele knelpunten die de uitgifte van een SOC2-rapport in Nederland mogelijk belemmeren of een risico vormen bij de uitgifte van een assurance-rapport. De accountant of IT-auditor dient daarom per opdracht goed na te gaan welke risico s er spelen, wie tot de gebruikerskring behoren en welke risico s daaraan zijn verbonden (gerelateerd aan het verzekeringsrisico zoals hiervoor beschreven). In de concept handreiking van de werkgroep SOC2 van de NOREA is opgenomen dat de auditor voorzichtigheid dient te betrachten om over privacy te rapporteren in een SOC2-rapport (zie bijlage C voor de concept handreiking). Voor de SOC3-rapportage dient eerst een oplossing te worden gezocht voordat een dergelijk keurmerk kan worden uitgegeven. De beroepsorganisaties NOREA en NBA dienen hierover een standpunt in te nemen.

40 6.2 Aanbevelingen Naar aanleiding van dit onderzoek zijn er ook enkele overige hiaten en risico s gesignaleerd. Enkele aanbevelingen hieromtrent zijn hierna opgenomen. Hiaten tussen de vraag en aanbod van SOC-rapporten Verscheidenheid aan assurance-behoeften. Meer comfort ontleend aan een SOC-rapport dan zou moeten op basis van het onderzoek. Behoefte naar keurmerken en seals (ook buiten het SOC3-product / seal). Aanbevelingen Nader onderzoek naar assurance-behoeften die verder kunnen worden gestandaardiseerd als assurance-product. Dit zorgt voor herkenbare verantwoordingsdocumenten. Een voorbeeld betreft de verdere ontwikkeling van softwarecertificatie. Educatie voor auditors over het gebruik van assurancestandaarden en SOC-rapporten model. Tevens verbeteren van communicatie richting service- en gebruikersorganisaties over SOC-rapporten. De werkgroep SOC2/3 van de NOREA (ondersteund door de NBA) kan nader onderzoek doen naar de mogelijkheden om een seal te ontwikkelen voor SOC3- rapporten in Nederland. Daarnaast kunnen de beroepsorganisaties nader onderzoek doen naar keurmerken die ontstaan door zelfregulering (zoals Zeker Online). Vraag naar continuous-assurance over de SOC-domeinen in plaats van uitspraak over historische werking controls. Stimuleren om SOC2/3-producten uit te brengen voor kortere periodes in scope (bijv. 3 maanden) inclusief een overlap met voorgaande periodes waardoor continue op korte termijn assurance wordt verleend. Dit kan de eerste stap zijn naar daadwerkelijke continuous-assurance. Tabel 9: hiaten vraag en aanbod SOC-rapporten Wat duidelijk blijkt uit dit onderzoek is dat er een vraag is naar specifieke assurance over die aspecten die voor de verschillende gebruikers relevant zijn. Daarnaast is er behoefte aan keurmerken om aan te tonen richting de gebruikersorganisaties dat de serviceorganisatie in control is of dat deze software betrouwbaar is. Nader onderzoek naar de inzet van keurmerken en specifieke assurance-producten voor verschillende stakeholders is daarom wenselijk. De volgende stap is die naar continuous-assurance afgegeven door auditors. Voor de domeinen beveiliging en privacy is deze stap zeer relevant. Risico s voor auditors rondom SOC2/3-rapportages Te weinig aandacht voor de architectuur van een systeem. Audit tooling wordt te beperkt ingezet om dit te toetsen. Onvoldoende mappings beschikbaar doelstellingen versus controlemaatregelen en t.b.v. referentiekaders auditors. Vergaande kennis rondom het IT-domein van de auditor is noodzakelijk om een SOC2/3-assurance-rapport te kunnen uitbrengen. Aanbevelingen Meer audit tooling gebruiken in combinatie met meer traditionele controle technieken, zoals controls testing. Het gebruik van data-analyses kan tevens helpen om de output van controlemaatregelen te toetsen. De beroepsorganisaties NOREA en NBA kunnen een primaire rol gaan spelen in het beoordelen van mappings met erkende controleraamwerken. Deze handschoen kan actief door de NOREA worden opgepakt om zodoende de relevantie van SOC-rapporten te vergroten en referentieraamwerken beschikbaar te maken om de kwaliteit van SOC-rapporten te verbeteren. Educatie voor auditors over het gebruik van assurancestandaarden en het model van SOC-rapporten. Daarnaast verdere educatie rondom het IT-object van onderzoek.

41 De beroepsorganisaties dienen daarnaast een besluit te nemen of een referentiekader mee te geven wanneer een accountant of auditor een SOC2/3-assurance-rapport zou moeten kunnen uitbrengen op basis van zijn kennis en ervaring. Breed gedefinieerde groep van gebruikers (breder dan SOC1) waardoor doelstelling rapport moeilijk is te toetsen Er kan een verschil worden gemaakt in de beoogde gebruikersgroep en de verspreidingskring. De auditor zou vooraf kunnen definiëren wie de verspreidingskring is (conform de definitie vastgesteld door de AICPA en opgenomen in de draft NOREA guidance, zie bijlage C). Daarnaast kan de auditor binnen deze verspreidingskring de beoogde gebruikers definiëren. Bij de opdrachtaanvaarding, scoping en uitvoer van de werkzaamheden kan de auditor rekening houden met deze beoogde gebruikersgroep. Tabel 10: aanbevelingen risico s SOC2/3 voor auditors Vanuit risico perspectief voor de auditors is vooral de definitie van de beoogde gebruikers een risico. Deze is veel breder gedefinieerd voor SOC2/3 ten opzichte van SOC1. Daardoor kunnen alle stakeholders die het rapport kunnen interpreteren hieruit comfort ontlenen. Juist dit maakt het lastig om door de auditor vooraf te bepalen wat de juiste reikwijdte van een rapport zou moeten zijn. Aanvullend onderzoek inclusief een stellingname van de beroepsorganisaties is hier wenselijk. Het privacy domein is daarnaast een domein waar aandacht voor zou moeten zijn gegeven de vraag van de stakeholders en de vraag die leeft in de maatschappij rondom privacy. Daarom is het wenselijk snel onderzoek te verrichten naar de integratie van de wet- en regelgeving van lokale privacywetgeving met de SOC2-criteria. Overige aanbevelingen SOC-rapportering Beter beschrijven van de reikwijdte van de processen en controlemaatregelen en de link met contractuele afspraken met gebruikers Carve-out sub serviceorganisaties beter identificeren Vollediger en juister vaststellen User Control Considerations (UCC) Diepgaandere testmethodes, hogere testaantallen en gebruik van audit tooling Beter beoordelen van de management bewering en de management testing uitgevoerd Tabel 11: overige aanbevelingen De genoemde leerpunten uit de ervaringen van SOC-rapportages van de afgelopen jaren bestrijken bijna alle inhoudelijke aspecten van een SOC-rapport eveneens de rol van de auditor om deze onderdelen van het rapport te controleren. Dit onderzoek geeft een bepaalde negatieve lading mee over de kwaliteit van de SOC-rapporten. Daarentegen zijn er ook veel kwalitatief goede SOC-rapporten in omloop waarbij goede gedegen controles zijn uitgevoerd door auditors. Deze lessons learned dienen daarom vooral opbouwend te worden gebruikt. Deze leerpunten bieden handvatten voor verdere aandachtspunten in de opleidingen tot auditor. Zie bijlage B voor alle lessons learned. Suggesties voor nader onderzoek Ondanks dat dit onderzoek niet heeft bewezen dat SOC-rapportages complex zijn van aard en dat gebruikers deze rapporten daardoor moeilijk kunnen interpreteren doe ik wel een suggestie

42 om nader onderzoek hier naar te doen. Doordat SOC-rapportages complex zijn kan het ook zijn dat er daardoor een verwachtingskloof ontstaat tussen de auditor en de gebruikers. Een beperking in dit eigen onderzoek betreft het feit dat enkel auditors van accountantskantoren zijn geïnterviewd. Door ook andere betrokkenen toe te voegen aan het onderzoek kan mogelijk dit aspect rondom de complexiteit van SOC-rapporten wel worden aangetoond. Uit dit onderzoek blijkt dat er behoefte is naar betaalbare SOC-rapporten terwijl tegelijkertijd meer behoefte is aan kwalitatief betere controles. Dit is een effect wat tegenstrijdig op elkaar werkt. Diepgaandere controletechnieken zullen normaalgesproken tot meer audituren leiden. Nader onderzoek kan bijdragen aan de vraag van gebruikers naar betaalbare rapporten en de wijze waarop dit valt te realiseren. Ook kan het zijn dat goedkopere SOC-rapporten niet valt te realiseren maar dat het juist noodzakelijk is om beter uit te leggen aan de serviceorganisaties en gebruikers hoe audituren en kosten zich verhouden. Om inzicht te krijgen in de behoefte aan assurance van de verschillende stakeholders en de wijze waarop huidige SOC-rapporten complementair aan elkaar zijn is nader onderzoek naar deze aspecten wenselijk. SOC2-rapport Serviceorganisatie NIVO A Control Environment / Governance NIVO B (User) Entity Controls Processen en Beheersmaatregelen User Entity Controls NIVO C Relevant ISMS bij de Sub Serviceorganisatie Information Security Management System Relevant ISMS bij de Gebruikersorganisatie NIVO D Information Management (Sub) Serviceorganisaties Gebruikersorganisaties Figuur 4: Reikwijdte van een SOC2-rapport ten opzichte van de (sub) service- en gebruikersorganisatie(s) Een SOC-rapport is in het algemeen vooral gericht op de governance en proces controls. De verantwoordelijkheid en interpretatie van sub serviceorganisaties en gebruikersorganisatie vervalt niet. Deze dienen nog steeds een relevant Informatie Security Management Systeem (ISMS) ingericht hebben met een interactie (door middel van bijvoorbeeld monitoring controls) met de serviceorganisatie die een SOC(2)-rapport overlegt. De interactie tussen (sub) serviceorganisaties en gebruikersorganisatie is een interessant object van onderzoek. Zeker wanneer de verwachting is dat steeds meer CSP ontstaan en steeds meer specifieke onderdelen van de IT worden uitbesteed aan gespecialiseerde sub serviceorganisatie. Hierdoor ontstaan ITketens waar een verscheidenheid aan serviceorganisaties met elkaar in interactie treden. Werkgroep NOREA/NBA SOC2 In het vierde kwartaal van 2014 is een werkgroep gestart binnen de NOREA (met ondersteuning van de NBA) over de implementatie van SOC2/3-rapporten in Nederlandse context. De hiaten, risico s en lessons learned zoals hiervoor beschreven zijn op basis van dit onderzoek de revue gepasseerd en geheel of gedeeltelijk geadresseerd in de concept handreiking (zie bijlage C).