Skip to main content

IT-assurance versus IT-certificering

Wat zijn de verschillen en overeenkomsten tussen IT-assurance en

IT-certificering en hoe ziet het wederzijds gebruik tussen die twee eruit?

Er is veel begripsverwarring over de inhoud, toepassing en geboden zekerheid door IT-assurance en -certificering. Het gebruik van termen als ‘certificeringsaudit’, ‘ISO-auditing’, ‘privacycertificering’ en ‘certificering van de jaarrekening’ vergroot de onduidelijkheid. Dit artikel geeft uitleg over beide typen onderzoeken en beschrijft welke overwegingen genomen kunnen worden om antwoord te krijgen op de vragen van:

  • afnemers van (uitbestede) IT-diensten: “Kan ik het beste om een ISO-certificaat of een IT-assurancerapport vragen?”
  • serviceproviders: “Zal ik zowel een ISO-certificaat als een IT-assurancerapport of één van beide aan mijn klanten aanbieden?”
  • auditors: “Hoe ga ik in mijn audit om met een beschikbaar ISO-certificaat?”

Inleiding

In toenemende mate komen zowel IT-gerelateerde[De inhoud van dit artikel is ook toepasbaar op niet IT-gebieden, zoals inzake kwaliteit, duurzaamheid, e.d., gezien de samenstelling van de lezersgroep zijn deze buiten beschouwing gebleven. Dit geldt evenzo voor het niet in dit artikel behandelen van product- en persoonscertificering.] ISO-certificaten als IT-assurancerapporten in dezelfde omgeving voor. Denk hierbij bijvoorbeeld aan ISO 27001-certificaten voor informatiebeveiliging en de COS/Richtlijn 3000/3402 assurancerapporten voor algemene IT-beheersingsmaatregelen. Ook al kennen ze gelijkenissen, het is belangrijk dat afnemers en aan­bieders de verschillen en toepassingsgebieden goed kunnen onderscheiden. Een verdieping daarbij is welke vorm van assurance en/of certificering gewenst is in welke situatie. Verderop in dit artikel wordt een aantal veelvoorkomende vormen en varianten van beide besproken.

De discussie over welke type zekerheid gewenst is voor de afnemer van ICT-diensten is vervroegd. Waar voorheen de keuze hiervoor pas na de uitbesteding of invoering van nieuwe systemen werd gemaakt, is dit nu veelal onderdeel van de RFP-procedure. Dat wordt mede ingegeven door wet- of regelgeving die voorschrijft dat er zekerheid moet worden verkregen over uitbestede activiteiten. Het management van de uitbestedende partij blijft immers verantwoordelijk voor de uitbestede processen.

Randvoorwaarde bij het juiste begrip bij afnemers en aanbieders van IT-diensten is dat IT-auditors niet alleen het onderscheid tussen assurance en certificering doorgronden, maar tevens hoe ze in één onderzoek tezamen moeten worden behandeld. Hierbij wordt ingegaan op het al dan niet kunnen steunen op een ISO-certificaat in een assurancerapport en vice versa.

Assurance

Om de overeenkomsten en verschillen tussen assurance en certificering te begrijpen, wordt hieronder beschreven wat de term ‘assurance’ omvat.

Aard

In het Raamwerk Assuranceopdrachten door IT-auditors is opgenomen dat een assuranceopdracht onder meer de volgende elementen dient te bevatten:

  • Doel assuranceopdracht. Afgezien van de vaktechnische doelstelling is het doel om derde partijen die vertrouwen op een dienst of product de zekerheid te bieden dat die voldoet aan een overeengekomen normenkader. Volgens de beroepsvoorschriften mogen er twee soorten van assuranceopdrachten worden uitgevoerd: tot het verkrijgen van een beperkte of een redelijke mate van zekerheid. Bij een redelijke mate van zekerheid wordt een positief geformuleerd oordeel – inzake het voldoen aan een normenkader – gerapporteerd aan de verspreidingsgroep, bij een beperkte mate is sprake van een negatief geformuleerde conclusie: “Op grond van onze in dit rapport beschreven werkzaamheden is ons niets gebleken op basis waarvan wij zouden moeten concluderen dat de interne beheersingsmaatregelen volgens de criteria XYZ niet in alle van materieel belang zijnde opzichten effectief zijn”. Absolute zekerheid is vrijwel nooit mogelijk, tenzij de waarnemingen van de IT-auditor een integraal karakter hebben (zoals bij volledige data-analyse).
  • Partijen. Bij een assuranceopdracht zijn drie partijen betrokken: (IT-)auditor, verantwoordelijke partij en beoogde gebruiker(s). Er kan ook sprake zijn van IT-assurance indien zowel degene die zekerheid ontleent aan een assurancerapport als de auditee en (interne) IT-auditor zich in één organisatie bevinden.
  • Object van onderzoek. Dit houdt het door de opdrachtgever gedefinieerde onderwerp in dat door de auditor  wordt geëvalueerd of getoetst. Dit kan een (governance)structuur, strategie, (informatie)systeem, proces, product of ander logisch samenstel van componenten zijn.
  • Toetsingsnormen. Dit zijn de eisen of criteria die worden gebruikt voor het evalueren of toetsen van het object van onderzoek waaronder, voor zover van belang, die voor presentatie en toelichting. Als er geen standaard-normenkader beschikbaar is kan er, op basis van algemeen aan normenkaders te stellen eisen, een specifieke set van toetsings­normen worden gespecificeerd. Deze algemene eisen betreffen ([NORE02]):
    • objectiviteit: de mate waarin normen(stelsels) vrij zijn van persoonlijke beïnvloeding;
    • eenduidigheid: de mate van precisering en eenduidigheid van formulering;
    • relevantie: de mate waarin normen(stelsels) bruikbaar zijn voor bepaalde auditopdrachten;
    • herleidbaarheid: de mate waarin kan worden vastgesteld waaraan normen(stelsels) zijn ontleend;
    • zorgvuldigheid: de mate waarin het normenstelsel beantwoordt, al dan niet juridisch verankerd, aan de maatschappelijke opvattingen over behoorlijk IT-gebruik.
  • Assurancerapport. Dit resultaat van het onderzoek betreft een schriftelijk rapport van de auditor met een oordeel of conclusie omtrent het object van onderzoek. Er kan sprake zijn van een goedkeurend oordeel, een oordeel met beperking of een afkeurend oordeel. Oordeelsonthouding is niet mogelijk, dan zal het leiden tot een afkeurend oordeel of het teruggeven van de opdracht.

Typen

Hoewel voor de term ‘assurance’ duidelijk is beschreven welke elementen assurance dient te bevatten, zijn er op de markt diverse vormen op basis waarvan assurance verstrekt kan worden. Tussen deze vormen van assurance bestaan ook weer overeenkomsten en verschillen. Een bekende en overkoepelende vorm van assurance is de ISAE 3000. ISAE 3000 is in Nederland geïmplementeerd onder de naam Standaard 3000 (NBA) en Richtlijn 3000 (NOREA).

Er kan onderscheid worden gemaakt tussen SOC 1-, SOC 2- en SOC 3-rapporten. Voor het onderscheid tussen de diverse vormen van IT-assurance verwijzen wij naar het artikel eerder in deze Compact “Nieuwe ontwikkelingen IT-gerelateerde Service Organisation Control-rapportages, SOC 2 en SOC 3” van Han Boer en Jaap van Beek.

Andere bekende vormen zijn nog softwarecertificering[Softwarecertificering is eigenlijk vorm van IT-assurance met een oordeel over betrouwbaarheidsfunctionaliteiten.], ZekeRE Zorg (DBC- en AWBZ-registratie en -facturering), ZekeRE Business (elektronisch zakendoen) en Trust Services. Zie verder [Oeve02].

Eisen aan de auditor die een assurancerapport verstrekt

Niet iedereen mag een assurancerapport verstrekken. In de Nederlandse vertaling van de ISAE 3402-standaard  (bekend als Richtlijn 3402 en Standaard 3402, opgesteld door respectievelijk NOREA en NIVRA) ([NORE10]) wordt vermeld dat alleen een ‘beroepsbeoefenaar’ bevoegd is om een ISAE 3402-assurancerapport te verstrekken. Voor een beroepsbeoefenaar wordt door de NOREA verwezen naar de IT-auditor, mits deze voldoet aan het Reglement Gedragscode ‘Code of Ethics’. Deze code is van toepassing op iedere in het RE-register ingeschreven IT-auditor. Hetzelfde geldt voor RA’s die zijn ingeschreven bij het NBA/NIVRA. Een ISAE 3402-assurancerapport kan daarom alleen door een ingeschreven RE of RA worden verstrekt.

Ook bij privacyaudits staat opgenomen dat de Registeraccountant (RA) of de Register EDP-auditor (RE), die beschikt over de aanvullende vereiste gespecialiseerde kennis en ervaring zoals aangegeven in paragraaf 12 van de richtlijn “Assurance-opdrachten tot bescherming van persoonsgegevens”, deze privacyaudits mogen uitvoeren.

Certificering

Het certificeren is alom bekend van de ISO 9001-certificaten bij menige organisatie, alleen de inhoud van certificering is minder bekend. De oorsprong van certificering ligt dan ook in het verantwoorden over kwaliteitsmanagementsystemen, in eerste instantie bij de Amerikaanse overheid en (defensie-)industrie. De ISO 9001-standaard heeft uiteindelijk in 1987 het levens­licht gezien, waarna er in de afgelopen 25 jaar vele zijn gevolgd – met als bekendste op IT-gebied de ISO 27001 voor informatie­beveiliging. In dit artikel richten wij ons op de IT-gerelateerde certificeringsstandaarden (zie kader 1).

Aard

Certificatie betreft het door een onafhankelijke, geaccrediteerde partij laten vaststellen of het managementsysteem van de betreffende organisatie voldoet aan alle eisen op een bepaald gebied. Het managementsysteem is de wijze waarop een organisatie of proces bestuurd wordt, oftewel de organisatiestructuur en de samenhangende beleidsregels, afspraken en werkwijzen binnen een bedrijf ten behoeve van een planmatige en systematische beheersing en verbetering van bedrijfsprocessen en -procedures om vooraf bepaalde doelstellingen te realiseren. Onder­deel hiervan vormt de door Deming ontwikkelde ‘Plan-Do-Check-Act’-cirkel voor het continu verminderen van variatie in de proces­uitvoering. Variatie gaat namelijk ten koste van de kwaliteit van een product of dienst.

De specifieke certificeringseisen of -criteria zijn opgenomen in een certificeringsstandaard of beoordelingsrichtlijn; de wijze van certificering voor een bepaalde standaard is opgenomen in een zogeheten certificatieschema. Deze standaarden en schema’s kunnen worden beheerd door zowel publieke als private partijen (zie verder onder ‘Overige vormen’).

In figuur 1 is gevisualiseerd hoe een managementsysteem voor ISO 27001 (Information Security Management System, ISMS) op hoofdlijnen functioneert.

C-2013-2-Koorn-01

Figuur 1. Managementsysteem voor informatiebeveiliging met Plan-Do-Check-Act-cyclus.

Het certificaat wordt over het algemeen voor een periode van drie jaar toegekend, mits blijvend aan de eisen wordt voldaan. Na de initiële certificeringsaudit vindt één of meer keren per jaar een controle- of surveillanceaudit plaats. Na drie jaar volgt er een nieuwe cyclus, tenzij het certificaat door de certificatie-instelling of de overheid[Zoals toen de OPTA besloot om de registratie van DigiNotar als leverancier van elektronische handtekeningen (certificaten) in te trekken.] wordt ingetrokken of de organisatie de certificering niet continueert.

Typen

In feite is sprake van vier hoofdtypen van certificering:

  • Organisatie- of procescertificering. Een procescertificaat verklaart dat een organisatie met haar specifieke vervaardigings- of verwerkingsproces voldoet aan de certificeringscriteria of bepaalde technische specificaties. Deze zijn dan veelal vastgelegd in een norm of in een attest (zie hieronder).
  • Productcertificering. Idem voor een product of (technische) component.
  • Attest: Bij een productcertificaat gaat het over de eigenschappen van een product, bij een attest gaat het over de toepassing van een product: een attest is een verklaring dat een product of systeem geschikt is voor de beoogde toepassing. Het attest beschrijft het product of het systeem. Eenmaal afgegeven vinden normaliter geen controles meer plaats.
  • Persoonscertificering. Een persoonscertificaat is een bewijs dat een persoon heeft aange­toond aan vastgestelde vakbekwaamheidseisen te voldoen.

Voor de eerste en laatste zijn er certificatie-instellingen en voor de tweede testlaboratoria/ inspectie-instellingen en kalibratielaboratoria (voor meet­instrumenten). In het vervolg van dit artikel laten wij de product- en persoonscertificering buiten beschouwing.

Certificeringsaanpak

Om vast te stellen of een organisatie een certificaat verdient voert een geaccrediteerde certificatie-instelling een certificatie-audit uit. Een certificatie-audit bestaat veelal uit een aantal hoofdfasen:

  1. Aanvraag, scoping en risicoanalyse. In de voorbereidende fase zal een organisatie naast haar doelstellingen voor de certificering ook de reikwijdte ervan moeten bepalen. Dit gebeurt in een zg. Verklaring van Toepasselijkheid (‘Statement of Applicability’). In deze verklaring staat vermeld welke processen en/of locaties van een organisatie en welke normen uit de standaard van toepassing zijn. Deze verklaring wordt op het uiteindelijke certificaat opgenomen. In deze fase wordt tevens kennisgenomen van de uitgevoerde risicoanalyse en de selectie van maatregelen door de organisatie. Derhalve hoeft niet per definitie de gehele set van maatregelen uit een ISO-standaard te worden geïmplementeerd.
  2. Documentatieonderzoek. De opzet van het managementsysteem wordt vastgesteld aan de hand van de documentatie, vergelijkbaar met een opzetbeoordeling of Test of Design.
  3. Implementatieonderzoek. Vervolgens onderzoekt de certificerende partij de (corrigerende) maatregelen om de risico’s uit de risicoanalyse en/of documentatie op te heffen. Hieruit komen al dan niet tekortkomingen. In de certificaatsperiode van drie jaar dienen alle geselecteerde maatregelen een keer aan bod te komen.
  4. Afstemmen certificatierapport en afgifte certificaat. Na de afstemming van het certificatierapport besluit de lead-auditor over de ernst van de geconstateerde tekortkomingen ten opzichte van de certificeringseisen. Hierbij is sprake van kritieke (major) en niet-kritieke (minor) non-conformiteiten. Een kritieke non-conformiteit houdt onmiddellijk een hoog risico in dat binnen drie maanden verholpen moet zijn, een niet-kritieke moet voor de volgende certificeringsaudit zijn opgelost[ Indien na een jaar de niet-kritieke non-conformiteit niet is verholpen, wordt deze per definitie naar een kritieke non-conformiteit gepromoveerd.]. Hierbij zal de certificatie-instelling terugkeren om een oorzaakanalyse, corrigerende maatregelen en de implementatie daarvan te beoordelen. Uiteindelijk zal worden overgegaan tot afgifte van het openbare certificaat, het certificatierapport met de eventueel geconstateerde non-conformiteiten blijft vertrouwelijk.

Eventueel kan er nog een proefbeoordeling plaatsvinden tussen stappen 1 en 2 om te bepalen in hoeverre de organisatie gereed is om voor de formele certificeringsaudit op te gaan. De bevindingen uit deze eventuele proefbeoordeling kunnen worden (her)gebruikt voor de formele certificering als deze binnen vier maanden na de proefbeoordeling plaatsvindt.

Kader 1. Standaardisatieorganen en IT-standaarden

Er zijn internationaal en nationaal verschillende standaardisatieorganen die assurance- en met name certificeringsstandaarden opstellen en beheren, zoals:

  • algemene internationale standaardisatieorganisaties: de  International Organization for Standardization (ISO), de International Electrotechnical Commission (IEC) en de International Telecommunication Union (ITU);
  • specifieke internationale organisaties: de Institute of Electrical and Electronics Engineers (IEEE), de Internet Engineering Task Force (IETF) en het World Wide Web Consortium (W3C);
  • Europese organisaties: zoals de European Committee for Standardization (CEN), de European Committee for Electrotechnical Standardization (CENELEC) en de European Telecommunications Standards Institute (ETSI);
  • nationale organisaties: American National Standards Institute (ANSI), National Institute of Standards and Technology (NIST) (beide Amerikaans), British Standards Institution (BSI), Deutsches Institut für Normung (DIN) en het Nederlands Normalisatie-instituut (NEN);
  • private partijen of consortia: zoals EMVCo (Europay MasterCard Visa) voor chip­betaal­kaarten en -lezers, de PCI (Payment Card Industry) Security Standards Council voor de beveiligingsstandaard inzake de beveiliging van betaalkaarten, de World Lottery Association (WLA) voor informatiebeveiliging bij loterijen en de Software Improvement Group (SIG) voor softwarekwaliteit.

Tot de relevante IT-gerelateerde certificeringsstandaarden behoren, naast de eerdergenoemde ISO 27001-standaard:

  • ISO 20000: IT Service management;
  • ETSI TS 101 456: gekwalificeerde elektronische handtekeningen;
  • ISO 22301/BS25999: Business Continuity Management;
  • ISO 31000: Risicomanagement;
  • ISO 29100: Privacy framework;
  • NEN 7510: Informatiebeveiliging in de zorg (toepassing van ISO 27001 in de zorgsector);
  • ISO 24760: Framework for Identity Management;
  • ISO 24745: Biometric Information Protection;
  • ISO 27034: IT security techniques – application security;
  • ISO 15408: Evaluatiecriteria voor IT-beveiliging (beter bekend als de ‘Common Criteria’);
  • ISO/IEC 29147: Responsible vulnerability disclosure;
  • ISO/IEC 13335: IT Security management;
  • ISO/IEC 38500: Corporate governance of information technology;
  • ISO/IEC 19770: Software Asset Management;
  • ISO 15489: voor records management en archivering;
  • ISO/IEC 15288:2008: Systems and software engineering – System life cycle processes
  • ISO 90003:2004: Software engineering – Guidelines for the application of ISO 9001:2000 to computer software;
  • CMMi: Capability Maturity Model integration voor de kwaliteit van softwareontwikkeling.

Eisen aan certificatie-instelling en -auditor

ISO-certificaten kunnen door verschillende certificatie-instellingen en daarvoor werkende auditors worden verstrekt. De accreditatie-eisen aan de organisaties zijn vastgelegd in ISO 17020[ Conformity assessment – Requirements for the operation of various types of bodies performing inspection.] (algemeen) of ISO 17025 ( laboratoria) of EN45011 (productcertificatie).

Certificering mag alleen worden uitgevoerd door goedgekeurde c.q. geaccrediteerde certificatie-instellingen. De Raad voor de Accreditatie houdt toezicht op het goed functioneren van de certificatie-instellingen in Nederland. In bijzondere omstandigheden waarbij de certificatie-instelling opereert binnen een wettelijk kader, is het noodzakelijk dat deze (aanvullend) een zg. aanwijzing voor een bepaalde periode van de overheid krijgt. Dit geldt bijvoorbeeld voor de certificering in het kader van de Wet Elektronische Handtekeningen; de PKI- of certificatie­dienstverleners mogen alleen door een door het ministerie van EZ aangewezen certificatie-instelling worden onderzocht.

Iedere certificatie-instelling moet een belangenvertegenwoordiging hebben[ ISO 17021 vereist namelijk dat certificatie-instellingen een eigen orgaan hebben waarin hun onafhankelijkheid en onpartijdigheid wordt geborgd.]. In Nederland noemen we dit het College van Deskundigen / Belanghebbenden. De taak van zo’n college is de onpartijdigheid van de instelling te waarborgen. Bij maatschappelijk relevante onderwerpen wordt vaak gebruikgemaakt van één geharmoni­seerd certificatieschema. Meestal beheert dit college het certificatieschema. Een dergelijk college is meestal ondergebracht in een rechtspersoon zoals een stichting, zodat het centrale college overeenkomsten kan aangaan met de nationale accreditatie-instelling. In geval van een centraal college controleert de accreditatie-instelling zowel het centrale college als de certificatie-instellingen die eraan verbonden zijn. Voorbeeld is ECP-EP.nl, die de door haar ontwikkelde certificeringsschema’s voor ISO 27001 en TTP.nl (elektronische hand­tekeningen) in Nederland beheert (zie ook [Koor02]).

Overeenkomsten en verschillen tussen assurance en certificering

Zoals uit bovenstaande beschrijvingen van assurance en certificering blijkt, zijn er diverse overeenkomsten en verschillen tussen assurance en certificering. Belangrijke overeenkomsten zijn dat voor beide vormen drie partijen aanwezig zullen moeten zijn, namelijk de certificerende partij, de verantwoordelijke partij en de partijen die gebruik (willen) maken van diensten van de verantwoordelijke. Daarnaast is bij certificering ook sprake van een object van onderzoek (bijvoorbeeld informatiebeveiliging bij een ISO 27001) en is er sprake van toetsingsnormen waaraan voldaan moet worden.

Belangrijke verschillen tussen assurance en certificering zijn met name gelegen in de scope/diepgang (managementsysteem versus individuele normen/maatregelen) en de manier waarop wordt gerapporteerd over de uitkomsten (assurancerapport versus certificaat) en hiermee ook de doelgroep en verspreidingskring.

De belangrijkste verschillen tussen assurance en certificering zijn weergegeven in tabel 1. Hierbij is voor de duidelijkheid het verschil tussen een 3000/3402-assuranceopdracht en een ISO 27001-certificering opgenomen.

  Assurance (ISAE 3000/3402/3600) Certificering (ISO 27001)
Rapportage    
Product Assurancerapport (uitgebreid met standaardverklaring erin) Certificaat (kort en gestandaardi­seerd)
Managementverklaring Ja, opgenomen in SOC 1/3402-rapport, ook van eventuele onder­aannemers Nee
Het behalen zegt dat de organisatie volledig in control is Nee, het assurancerapport kan afwijkingen bevatten Ja, van het managementsysteem, niet zozeer van de onderliggende beheer­sings­maatregelen. Een organisatie behoudt haar certificaat alleen als alle kritieke non-conformiteiten op korte termijn zijn verholpen. Certificaat bevat geen beschrijving van tekort­komingen.
Doelgroep & verspreidingskring    
Normen gehanteerd specifiek voor organisatie of gebruikersorganisaties Ja Nee, standaardset met alleen keuze voor organisatieonderdelen/normen buiten scope
Specifieke doelgroep Ja, de klanten van de serviceorganisatie Nee, kunnen zowel klanten als andere belanghebbenden zijn
Verspreidingskring Beperkt tot klanten (m.u.v. SOC 3 bij openbaar webzegel) Algemeen geldend, geen beperking aan verspreidingskring
Gebruik voor (overheids)toezicht Ja, in toenemende mate verplicht (bijv. bij uitbesteding) Beperkt, NEN 7510-certificering staat op nominatie om verplicht te worden gesteld voor zorgverleners[ Zie ook [Just03], waarin wordt gesteld dat certificering vooral dan een geschikt instrument is als de keten van privaat toezicht voldoende betrouwbaar is, de activiteiten van de private toezichthouders voldoende controleer­baar zijn, en er voldoende draagvlak bestaat bij de organisatie.]
Overige aspecten    
Onderaannemers in scope mogelijk (zg. ‘inclusive’-model) Ja, duidelijk leesbaar voor gebruikers­­organisaties, tenzij is gekozen voor ‘carve-out’-model Nee, iedere organisatie heeft eigen certificaat nodig
Diepgang Ieder jaar bestaan en werking van alle normen, op basis van toereikende steekproef Over driejaarsperiode van (bestaan van) alle normen
Zekerheid verstrekt door RA of RE Ja Nee, niet verplicht, uitsluitend door geaccrediteerde onafhankelijke en deskundige certificatie-instellingen en auditors
Mate van zekerheid Beperkte of redelijke mate van zekerheid Alleen redelijke mate van zekerheid
Geldig in de toekomst Nee Ja
Beschrijving van testwerkzaamheden opgenomen Ja, verplicht in ISAE 3402 (inclusief testresultaten), gebruikelijk in ISAE 3000 Nee
Steunen op Internal Audit Ja, als IAD (-er) voldoet aan bekwaam­heids-, onafhankelijkheids- en opleidingseisen Ja
Oordeel over werking (toetsing over bepaalde periode) Ja, alleen bij type 2, type 1 omvat alleen opzet en bestaan Nee, in feite alleen opzet en bestaan
Globale inspanning (bandbreedte bij overeenkomstige organisatie en scope) 25 – 70 dagen (in daaropvolgende jaren 70 – 90% van initiële audit) 6 – 18 dagen (in 2e en 3e jaar ca. 40 – 55% van initiële audit, vervolgens weer hercertificering)
Vast normenkader en scope Nee, geen vast normenkader, beheersingsmaatregelen worden specifiek gemaakt voor de serviceorganisatie en haar klanten Ja, conform relevante (ISO-) standaard, voorgedefinieerde set van maatregelen

Tabel 1. Verschillen tussen assurance en certificering.

Wederzijds gebruik van IT-assurance en -certificering

In toenemende mate komt zowel IT-assurance als IT-certificering voor in dezelfde omgeving of serviceketen. Indien een organisatie zoals een IT-serviceprovider over beide beschikt is te bezien in hoeverre efficiëntiewinst haalbaar is door zoveel mogelijk de normen­kaders en werkingsperioden op elkaar af te stemmen (zie ook de slotparagraaf Marktvisies).

In het geval er op elkaar moet worden gesteund zijn twee situaties te onderscheiden:

  • Bij een IT-certificering kan worden gesteund op een IT-assurancerapport indien de normen en werkingsperioden overlappend zijn. Bij afwijkende perioden kan voor de certificering geopteerd worden door te onderzoeken of het managementsysteem de resterende maanden naar behoren heeft gefunctioneerd.
  • Wanneer bij IT-assurance moet worden gesteund op een certificering die heeft plaatsgevonden, bijvoorbeeld bij uitbesteding aan een IT-serviceprovider met een ISO 27001-certificaat, gelden er beperkingen. Zeker als het een Type 2-rapport betreft kan niet worden volstaan met een ISO-certificaat, aangezien onduidelijk is welke normen in het betreffende jaar zijn ‘geraakt’ en aangezien niet alle normen/maatregelen ieder jaar of met voldoende waarnemingen worden onder­zocht. Dit betekent dat de meeste auditwerkzaamheden zelfstandig moeten plaats­vinden.

Toekomstige ontwikkelingen

Verschillen en overeenkomsten tussen assurance en certificering zijn voor zowel serviceorganisaties als gebruikersorganisaties vaak nog onduidelijk. Een mogelijke oorzaak hiervoor is de grote hoeveelheid soorten assurance en certificering in de markt. Om goed de waarde en bruikbaarheid van assurance of certificering te kunnen begrijpen is het van belang dat de bewustwording over de verschillen wordt verbeterd.  

De afgelopen jaren hebben diverse ontwikkelingen rondom assurance en certificering plaats­gevonden. Er zijn in die periode nieuwe vormen van assurance ontstaan. Zo heeft SAS 70 plaatsgemaakt voor de nieuwe ISAE 3402-standaard (SOC 1); ook de SOC 3-webrapportage is een relatief nieuwe vorm van assurance. Bij certificering blijven de ontwikkelingen eveneens doorgaan.

De verdere ontwikkeling rondom assurance en certificering is lastig te voorspellen. Op basis van de recente ontwikkelingen en de marktvisies die zijn opgenomen in dit artikel (zie verderop) verwachten wij dat de volgende ontwikkelingen zich in de toekomst voor kunnen doen rondom assurance en certificering:

  • Door de toename van wet- en regelgeving en het zichtbaar kunnen nemen van verant­woordelijkheid voor de uitbestede processen verwachten wij dat de vraag naar assurance en certificering de komende jaren zal toenemen. Door onduidelijkheden in de markt over de overeenkomsten en verschillen tussen certificering en assurance, en doordat (potentiële) klanten om verschillende vormen van zekerheid vragen, verwachten wij dat steeds meer serviceorganisaties een combinatie van certificering en assurance zullen aanbieden aan (potentiële) gebruikersorganisaties. De aanpak zal hierbij meer verschuiven naar certificering/ISO 27001 als basis (opzet en bestaan), waarbij aanvullend ook de werking aangetoond zal worden met een IT-assurancerapport.
  • Zoals te lezen valt in de visies uit de markt (zie de slotparagraaf), wordt verwacht dat certificering in waarde zal dalen en dat er in toenemende mate geïntegreerd, dus over naleving van meerdere normen­kaders, gaat worden gemonitord en gerapporteerd (zg. Integrated Reporting op basis van breed Business Control Framework). Dit geeft overkoepelend inzicht en verlicht tevens de als hoog ervaren auditdruk.
  • De toekomst van IT-certificering en IT-assurance ligt wellicht in de combinatie van beide, alsmede verdere professionalisering van Continuous Auditing, Monitoring en Assurance. Wij verwachten dat het frequenter auditen een logische vervolgstap zal zijn naar een bredere beheersingsscope met het monitoren van meerdere audit- en complianceonderwerpen; dit staat ook wel bekend als IT GRC (Governance, Risk & Compliance). Er is in de markt ook meer vraag naar tussentijdse informatie over de kwaliteit en beheersing van uitbestede processen. Hierbij zijn tussentijdse KPI/KRI-rapportages van belang, die al dan niet worden geaudit, en a tempo Continuous Assurancerapportages waarop te reageren en sturen valt.
  • Gerelateerd aan assurance zijn SOC 2 en SOC 3 relatief nieuw. Onze verwachting is dat deze vormen snel populair zullen worden. Vanuit marketingoverwegingen is meer vraag naar SOC 3 te verwachten, wellicht met name bij organisaties die daarmee de grootste ‘vertrouwens­sprong’ kunnen maken (zoals SaaS/cloud-leveranciers).
  • De ontwikkelingen zullen daarnaast verschillen per branche. Uit de marktvisies blijkt dat één van de belangrijkste redenen voor het verstrekken van een assurancerapport of certificaat door een serviceorganisatie de klantwens is. Op dit moment verschilt de vraag naar assurance of certificering per sector. Zo is in de IT-sector zowel assurance als certificering gebruikelijk. Daarentegen is voor bijvoorbeeld uitbestede processen door pensioen­fondsen,waaronder pensioenadministratie en vermogensbeheer, de vraag naar assurance (en dan specifiek ISAE 3402) gebruikelijk. Het beschikken over een ISAE 3402-rapport zegt natuurlijk nog weinig over de scope en het normenkader die het rapport zal bevatten en de frequentie waarmee wordt gerapporteerd. Dus zowel aanbieders als afnemers van assurance of certificering zullen explicieter moeten afstemmen welke eisen en wensen er zijn om ervoor te zorgen dat het product zijn relevante rol behoudt of versterkt en niet verwordt tot een ‘tick in de box’.

Marktvisies:

Wij hebben twee afnemers en twee aanbieders van IT-assurance en/of ISO 27001 een aantal vragen gesteld over hun visie rondom dit onderwerp. Deze paragraaf bevat een kort overzicht van de reacties.

Wie is verantwoordelijk?

Aanbieders

  • CFO was en is voor zowel de ISO 27001 als de ISAE 3402 de eindverant­woordelijke. De uitvoering ligt bij de afdeling Risk Management & Compliance.

Afnemers

  • De verantwoordelijkheid voor informatie­beveiliging ligt bij de afdeling Information Risk Management. De “Corporate Information Security Manager” is gestart met 3402-traject onder verantwoordelijkheid van IRM met begeleiding vanuit Internal Audit.  Op dit moment is het onderwerp teruggegeven aan de ICT-dienstenorganisatie en is daarmee een vast onderdeel van de uitbestedingsstrategie (overeenkomst) en het interne IT Control Framework.
  • De afdeling ICT is verantwoordelijk voor de informatiebeveiliging en vraagt in dat kader TPM’s aan de IT-dienstenleveranciers. In specifieke situaties heeft de accountant van de afdeling ICT de mogelijkheid gekregen om onderzoek te doen om een beeld te krijgen of de dienstverlening conform de gemaakte afspraken wordt geleverd.

Waarom gekozen voor zowel IT-assurance als ISO 27001-certificering?

Aanbieders

  • In de praktijk betekent gecertificeerd zijn voor veel bedrijven een jaar lang opzet en bestaan onderhouden en pas rond de jaarlijkse audit verhoogde  aandacht voor de werking, ondanks dat  de Kwaliteitsafdeling de PDCA-cyclus op gang houdt. IT-assurance dwingt de organisatie tot continuïteit en aantoonbaarheid van activiteiten en vermindert daarmee de “dip” na de jaarlijkse audit en de “spike” voor de volgende audit.
  • Wij waren al ISO 27001- en ISO 9001-gecertificeerd omdat dat tot onze dienstverlening behoort. Het hebben van beide certificaten en een ISAE 3402-rapport wordt ook door veel van onze klanten geëist.

Afnemers

  • In 1999 was BS17999 een logische keuze omdat men behoefte had aan een best-practices op het gebied van informatiebeveiliging. En een absolute voorwaarde om een vergunning van de toezichthouder te verkrijgen. In die tijd waren alle IT-processen intern belegd in tegenstelling tot nu. Daarom is in 2006 ook besloten om IT-assurance te vragen aan iedere relevante IT-leverancier over de door hem geleverde diensten.
  • Onze IT-diensten zijn uitbesteed. De afdeling ICT ontvangt van één van de providers een ISAE 3000-verklaring omdat deze ‘free format’ is en getoetst wordt op basis van het referentiekader dat de organisatie en serviceprovider overeengekomen zijn. De providers laten uit hoofde van de contracteisen zich certificeren op basis van ISO 27001.

In hoeverre is er overlap IT-assurance – ISO 27001-certificering?

Aanbieders

  • In feite geen overlap. IT-assurance, mits goed opgezet, is een verlengstuk van normeringen / certificering en een middel om de doelen die geleid hebben tot en voortkomen uit de certificeringstrajecten beter te onderhouden en dus kwaliteit en continuïteit beter te waar­borgen. IT-assurance helpt ook om de verantwoordelijkheid daar te beleggen waar die thuishoort.
  • In 3402 is een aantal controledoel­stellingen uit de ISO-certificaten overgenomen en uitgewerkt. Deze zijn aangevuld met vooral specifieke HR-doelstellingen.

Afnemers

  • Bij een aantal algemene aspecten is er sprake van overlapping, zoals bij fysieke beveiliging. Bij de assuranceverklaringen kunnen providers waar nodig dan ook gebruikmaken van de resultaten uit ISO 27001-verklaringen. De providers zijn overigens contractueel verplicht ook zo’n verklaring te hebben.
  • IT-assuranceverklaring maakt onderdeel uit van de verantwoording aan de toezichthouder in het kader van de totale bedrijfsvoering. ISO 27001-certificering is onderdeel van de aanbestedingstrajecten. Reden hiervoor is een zekerheid te hebben dat de provider zijn organisatie op een beheerste wijze heeft ingericht.

Communicatie met klanten over verschillen en overeenkomsten tussen assurance en certificering?

Aanbieders

  • Veelal nog ad-hoc, reactieve communicatie n.a.v. vragen. Intern gaat nadere toelichting worden opgesteld voor intern gebruik, voor proposals en/of andere externe communicatie.
  • Bij klanten wordt het rapport op verzoek aangeboden en toegelicht door onze afdeling of de relatiemanager.

Afnemers

  • We moeten het verschil tussen beide typen externe verantwoording door serviceproviders vaak aan onze eigen organisatie uitleggen.
  • Certificering maakt onderdeel uit van een contract tussen de organisatie en de serviceprovider. Over een verschil tussen certificering en assurance wordt niet gesproken.

Voor wie is het assurancerapport en ISO-certificaat bedoeld?

Aanbieders

  • De ISO-certificaten zijn voor de volle breedte, dus zowel voor partners, interne en externe klanten bedoeld. IT-assurance is specifiek opgezet voor één  klant, met de bedoeling het in de toekomst generiek te maken omdat deze klant  inziet dat IT-assurance voor de volledige dienstverlening bijdraagt aan kwaliteitsverbetering en tegemoetkomt aan de vraag van klanten.
  • ISO-certificaten voor al onze klanten. Assurance-rapport voor de klanten waar wij resultaatverplichte opdrachten voor uitvoeren.

Afnemers

  • Als derde partijen primaire IT-processen voor ons uitvoeren is er bijna altijd sprake van een 3402-verklaring. Dit laatste is ook noodzakelijk in het kader van financiële en operationele auditwerkzaamheden.  In alle andere gevallen maakt het voldoen aan de ISO 2700x-kwaliteitsnorm standaard onderdeel uit van onze inkoopvoorwaarden.
  • We maken intern zeer beperkt gebruik van ISO 27001-verklaringen van leveranciers.

Wat zijn neveneffecten van beide trajecten?

Aanbieders

  • Uit het IT-assurancetraject zijn diverse efficiëntieslagen naar voren gekomen. Een IT-assurancetraject dwingt om nog eens goed stil te staan bij wat men doet, de noodzaak van wat men doet en zo ja, of en hoe dat meetbaar en aantoonbaar te maken is. Expliciete keuzes moeten worden gemaakt. Hierdoor kan qua efficiëntie veel worden gewonnen maar ook commercieel; activiteiten die niet zijn overeengekomen en/of vastgelegd maar wel nodig blijken kunnen formeel aangeboden worden aan klanten; door werkwijzen in lijn te brengen kan men makkelijker profiteren van elkaars expertise en capaciteit.
  • Door integratie van rapportage over de verschillende frameworks hebben we efficiëntie behaald in de auditingkosten en -belasting voor de organisatie.

Afnemers

  • We denken wel dat enige kwaliteitsverbetering te meten is. Het is in ieder geval zo dat we de leverancier makkelijker (inhoudelijk) kunnen aanspreken.  Dagelijkse problemen in de dienstverlening (veelal procesmatig) worden hiermee echter zelden opgelost.
  • Zeer beperkt, de assuranceverklaringen worden voor ‘certificeringsdoeleinden’ gebruikt.

Wordt Continuous Auditing/Monitoring toegepast?

Aanbieders

  • Vanuit de Kwaliteitsafdeling is er een continu doorlopende interne auditcyclus die alle vier de certificeringen dekt. IT-assurance zal in de toekomst helpen om de auditdruk op de organisatie te verminderen en de wijze van auditen kan hierdoor ook veranderen omdat vanuit IT-assurance al veel evidence zal worden geleverd.
  • Met de projectthermometers in het kader van de ISAE 3402 (periodieke self-assessments) en de continue monitoring vanuit India.

Afnemers

  • Wij passen dit vanaf 2013 toe op al onze belangrijke processen via een Business Control Framework.
  • We werken er momenteel aan om dit te bereiken.

Welke ontwikkelingen worden op dit terrein in de toekomst verwacht?

Aanbieders

  • Verwacht wordt dat de “waarde” van certificering steeds minder gaat worden, van een onderscheidend vermogen is certificering verworden tot gemeengoed; iets wat standaard aanwezig is. Klanten, intern en extern, zoeken steeds meer naar zekerheid dat je als leverancier ook daadwerkelijk en continu doet wat er is overeengekomen. Daarbij staat de druk die certificering en assurance leggen op leveranciers in schril contrast met de toenemende vraag naar prijsverlaging. In de IT-outsourcingbranche voorzien we  in de nabije toekomst een breekpunt waarbij voor de prijs die klanten willen betalen de gevraagde certificeringen en assurance niet meer zijn op te brengen. De uitdaging is dus om de twee ineen te schuiven; elkaar te laten complementeren en tegelijk dermate toegevoegde waarde voor de organisatie te laten opleveren dat je van kostenpost naar toegevoegde waarde gaat.
  • Meer integratie van frameworks en verschillende controledoelstellingen. In de verdere toekomst voorkeur voor een Integrated Assurance-rapport, één rapport voor de onderbouwing van zowel de assurance alsook de certificeringen.

Afnemers

  • Wij sturen erop om de auditdruk verder te verminderen. En zoveel mogelijk frameworks (COSO, BCM, CobIt, ISO, Privacy, e.d.) af te dekken met het Business Control Framework-proces en bijbehorende “in control”-verklaringen.
  • Wij verwachten dat het jaarlijks verstrekken van assurancerapportages zijn langste tijd gehad heeft. Reden hiervoor is dat deze alleen maar historische informatie verstrekken waar het lijnmanagement niet op zit te wachten. We zien meer heil in Continuous Auditing/Monitoring en Continuous Assurance.

Literatuur

[Just03] Expertisecentrum Rechtshandhaving, Handhaving en certificering – een handreiking voor de beleids- en wetgevingspraktijk, Ministerie van Justitie, 2003.

[Koor02] Drs.ing. R.F. Koorn RE CISA, drs. P. van Walsem RE en M. Lundin CPA CISA, Auditing and Certification of a Public Key Infrastructure, Information Systems Control Journal, Volume 5, 2002.

[NORE02] NOREA, Studierapport 3, Raamwerk voor ontwikkeling normenstelsels en standaarden – Een facilitair instrument bij de beroepsuitoefening, 2002.

[NORE10] NOREA, NOREA Richtlijn 3402 assurancerapporten betreffende interne beheersingsmaatregelen bij een serviceorganisatie, 2010 http://www.norea.nl.

[Oeve02] Drs. W.C.N. van Oeveren, dr. ir. P.L. Overbeek RE, ir. L. Yap, drs. P.A. van Walsem, drs. R.P. Schouten RE RA en drs. M.A. Francken RA, drs. K.H.G.J.M. Ho RE RA, drs. L. Hoogeveen, drs. H.G.Th. van Gils RE RA en drs. A.R.J. Basten RE, Productcatalogus, Compact, november 2003.

Met dank aan:

  • M.J. Maunder-Cockram (Fujitsu)
  • H. van Breukelen (Sogeti)
  • B. Lohmeijer (Rabo Vastgoed)
  • W. Tewarie (UWV)

Assurance in the cloud

Cloud computing rukt steeds meer op in het bedrijfsleven. Er is veel discussie in het vakgebied over wat de impact is van cloud computing op veiligheid en vertrouwelijkheid van data in de cloud. Is cloud vergelijkbaar met uitbesteding of wordt een nieuwe dimensie toegevoegd aan het spectrum? Is het nog mogelijk voor gebruikers om zelf voldoende grip op de risico’s te houden en hoe moet de assuranceprovider inspelen op deze ontwikkelingen? De auteurs behandelen een aantal actuele ontwikkelingen en proberen oplossingsrichtingen aan te geven voor deze issues. Eén ding wordt duidelijk: assurance zal zich in snel tempo moeten mee ontwikkelen met de cloud om relevant te blijven voor bedrijven en gebruikers van clouddiensten.

Inleiding

Privé kunt u via de clouds van Apple, Google, etc. op ieder apparaat en iedere plek ter wereld uw foto’s en databestanden openen en met anderen delen. U richt het zo in dat u niets hoeft te doen op uw laptop, smartphone of tablet, want alles wat u doet wordt automatisch voor u in de cloud opgeslagen. En ook uw e-mail zal zich wel ergens in de cloud bevinden.

Vanuit het bedrijfsleven is de cloud niet meer weg te denken. Slogans als ‘Wij leveren cloudintegratiediensten waarmee uw datacenterdiensten transformeren van een kapitaalintensieve omgeving die moeizaam schaalbaar is naar een omgeving die zich snel aanpast en schaalt naar de groeiende vraag’ zijn aan de orde van de dag. Variërend van al dan niet tijdelijk wat extra capaciteit inhuren (IAAS), een compleet ingericht platform gebruiken waarop alle software staat om een complete webwinkel te ontwikkelen (PAAS) tot het aanbieden van onlinediensten als het voeren van de financiële of logistieke administratie zonder zelf pakketten aan te schaffen (SAAS), het kan allemaal en het gebeurt inmiddels veelvuldig.

Natuurlijk ontstaat daarbij de vraag hoe betrouwbaar deze diensten zijn en hoe de aanbieders die betrouwbaarheid en vooral beveiliging, continuïteit en privacy garanderen. Bij de selectie van een cloudprovider zijn dat vraagstukken die meestal wel maar soms ook niet te regelen zijn. Dat is mede afhankelijk van de aard van de dienstverlener en de omvang van het contract. Voor mijn Google e-mailaccount geldt eenvoudig ‘take it or leave it’, maar als een multinational overgaat tot gmail blijken er wel specifieke afspraken mogelijk te zijn. In dit artikel wordt eerst ingegaan op de behoefte aan assurance, worden de nieuwe risico’s en control frameworks besproken inclusief de assuranceproducten en wordt vervolgens stilgestaan bij de noodzakelijke dynamisering van de assurancerapporten en de assurancedienstverlening zelf. Tot slot wordt ingegaan op de ontwikkeling van concepten als Continuous monitoring en Continuous auditing om antwoord te geven op de uitdaging die cloud voor assurance betekent.

Behoefte aan assurance

Onlosmakelijk met cloud computing, net als met de ‘klassieke uitbesteding’, is er het punt van kwetsbaarheid: is alles beschikbaar en wat gebeurt er verder met mijn data? Anderzijds is de kwetsbaarheid bij een professionele externe serviceprovider wellicht kleiner dan bij een onprofessionele interne IT-afdeling. Hoe dan ook, de vraag doet zich voor op welke wijze gebruikers zelf nog voldoende grip hebben op de IT-uitbesteding en op basis waarvan zij hun verantwoordelijkheid inhoud kunnen geven. Het zal duidelijk zijn dat dat verschillend is met de aard van de dienstverlening. Bij IAAS-oplossingen zijn de risico’s nog redelijk beperkt en heeft de gebruikende organisatie zelf nog middelen om voor een belangrijk deel voor de betrouwbaarheid maatregelen te treffen. Aan de andere kant, bij SAAS-oplossingen in een publieke cloud zijn de mogelijkheden erg beperkt.

Er zijn al veel waarschuwende vingertjes geheven over de veiligheid en vertrouwelijkheid van data in de cloud! Ook al komen er soms ook positieve berichten over cloud computing (zie bijgaand kader), het zijn uitzonderingen en zij roepen veel kritiek over zich heen. Toch vindt cloud computing nu al veelvuldig plaats en blijft de vraag op zijn plaats welke zekerheid een uitbestedende partij nog heeft.

Als er eens een keer een storing of datalek is bij clouddiensten staan de sceptici op hun achterste benen: zie je wel, die cloud is onveilig en onbetrouwbaar! Ondertussen sleutelen ze rustig door aan hun server in de kelder. Die server die bij elkaar opgeteld dagenlang per jaar offline is en waar elke scripkiddie naar binnen kan wandelen.

Die sceptici kunnen roepen wat ze willen, de cloud is veiliger en betrouwbaarder dan servers on the premise, aldus Google. Het is net als de veiligheid van vliegen versus de veiligheid van autorijden. Een vliegtuigongeluk is heftig, maar zeldzaam, uiteindelijk zijn de risico’s bij autorijden vele malen groter.

Bovendien is de cloud van Google extra veilig ten opzicht van de concurrentie, juist door die verregaande decentralisatie. Google slaat niet alleen bestanden redundant op, het hakt de bestanden in versleutelde snippers die letterlijk overal en nergens staan.

Bron: Webwereld.nl; artikel Vijf zegeningen van de Google-cloud

Gepubliceerd: 15 januari 2011

Auteur: Andreas Udo de Haes

http://webwereld.nl/de-vijf/105395/vijf-zegeningen-van-de-google-cloud.html

Risico en controleframeworks

Hoewel het aantal cloud computing-gerelateerde incidenten relatief klein lijkt in vergelijking met traditionele IT, kan de impact van een incident groot zijn, omdat een beveiligingsincident bij een cloud service-dienstverlener bijna altijd meerdere organisaties (afnemers) raakt. Er zijn diverse rapporten en artikelen geschreven over beveiligingsrisico’s rond cloud computing, onder andere NIST, CSA en ISACA hebben hierover gepubliceerd. Een recent en breed geaccepteerd rapport binnen Europese overheden en organisaties is dat van ENISA[In het tweede kwartaal van 2013 verwachten we de MSc-scriptie van Peter van Ulden getiteld ‘Security in the Cloud’. Het resultaat van deze scriptie is een cloud control-framework gebaseerd op de cloud computing-beveiligingsrisico’s gedefinieerd door ENISA, dat gebruikt kan worden ter ondersteuning bij het maken van op cloud computing-beveiliging gebaseerde beslissingen.], het ‘Cloud Computing Security Risk Assessment’. In dit rapport worden de unieke cloud computing-beveiligingsrisico’s uitgebreid belicht en beschreven. ENISA heeft de risico’s verdeeld in drie categorieën: ‘beleid & organisatie, technische risico’s en juridische risico’s’.

Voor de standaard beveiligingsrisico’s van IT zijn standaarden als ISO 27001/2 en Cobit de facto bepalend. Deze standaarden zijn gericht op traditionele IT-oplossingen en sluiten niet goed aan bij de nieuwe beveiligingsrisico’s die cloud computing met zich meebrengt. Hoewel er nog geen algemeen geaccepteerde specifieke cloudstandaarden op de markt zijn, zijn er wel organisaties die een poging daartoe doen of eraan werken. Enkele voorbeelden hiervan zijn:

  • CSA – Cloud Controls Matrix

    Het CSA CCM levert een controleframework dat een grondig inzicht geeft in de beveiligingsconcepten en -principes gerelateerd aan de CSA-richtlijnen. De fundering van de Cloud Controls Matrix zijn andere door de industrie geaccepteerde beveiligingsstandaarden, regelingen of frameworks, zoals onder meer ISO 27001/2, ISACA COBIT en NIST. Het CSA CCM is erop gericht om op de traditionele manier achteraf assurance af te geven over een bepaalde periode.
  • Het ISO/IEC 27017 is in ontwikkeling en betreft een specifieke invulling van de ISO 27002 voor de cloudomgeving. Op korte termijn zal deze standaard nog niet beschikbaar komen.

Assuranceproducten

In Nederland was al decennia geleden een goed product ontwikkeld en beschreven in de NIVRA-serie Automatisering en Controle en met name in NIVRA-geschrift 26, Deel 4 Mededeling door de accountant met betrekking tot de betrouwbaarheid en continuïteit van geautomatiseerde gegevensverwerking. Dit geschrift gaf al een duidelijke richtlijn voor een mededeling ten behoeve van derden. Tegenwoordig kennen we binnen het accountants- en IT-auditorsdomein de opvolgers in de vorm van de internationale standaarden ISAE 3000 en ISAE 3402. Hoewel de standaarden bedoeld zijn als richtlijnen voor het doen van mededelingen ten behoeve van derden bij uitbesteding van diensten zijn er geen inhoudelijke normen voorgeschreven waaraan die diensten van de dienstverleners moeten voldoen. Die moeten dus uit andere bronnen komen. Bekend is in dit kader het Studierapport ‘Normen voor de beheersing van uitbestede ICT-beheerprocessen’, uitgegeven door NOREA en PvIB, dat bedoeld is voor zowel de serviceprovider, de klantorganisatie als de IT-auditor. Hoewel dit Studierapport in de praktijk met grote regelmaat wordt gebruikt, stamt het nog uit een periode waarin cloud computing bepaald geen gemeengoed was en derhalve is de inhoud van dit rapport hierop niet afgestemd.

Zoals in de vorige paragraaf is aangegeven, is er inmiddels een aantal publicaties die wel normenstelsels voor cloud computing bevatten. Alleen geldt daarvoor ook dat integrale toepassing nauwelijks realistisch is uit het oogpunt van de kosten die gemoeid zijn met het laten beoordelen van de beheersingsmaatregelen door een externe IT-auditor. De vraag komt dan ook op voor welke onderwerpen een klantorganisatie behoefte heeft aan een assurancerapportage van een onafhankelijke IT-auditor en welke vorm van rapportage daarvoor het meest geschikt is.

In de praktijk is het meest gangbare assurancerapport nog steeds het ISAE 3402 (SOC 1)-rapport. Dit is de opvolger van SAS 70 en is specifiek gericht op controls rond financial reporting. De focus in dit soort rapporten ligt vooral op het kwaliteitsaspect betrouwbaarheid. De kwaliteitsaspecten continuïteit, security en privacy die in het kader van cloud computing meer relevant zijn, passen minder goed in de scope van een dergelijk rapport en zijn deels zelfs expliciet uitgesloten. In de Verenigde Staten wordt daarom in toenemende mate gebruikgemaakt van het zogenaamde SOC 2-rapport waarin juist expliciet aan deze aspecten aandacht wordt besteed (‘Security, Availability, Confidentiality, Processing Integrity en Privacy’). In Nederland kan een SOC 2-rapport worden uitgebracht onder de internationale ISAE 3000-standaard. Het voordeel van SOC 2 is dat hierin expliciet controledoelstellingen en een set van minimale normen zijn benoemd zodat een marktstandaard is gezet. Natuurlijk kan ook van de ‘kale’ ISAE 3000-standaard gebruik worden gemaakt, waarbij vervolgens een normenstelsel wordt ingevoegd dat of gebaseerd is op een normenstelsel dat al door de serviceprovider is opgesteld of bijvoorbeeld is afgeleid uit één van de kenmerkende cloud-normenstelsels (zie vorige paragraaf).

Naast de bovengenoemde ISAE-assurancerapportages wordt in cloudverband ook gewezen op de ISO 27001/2-standaard, die met name security als kenmerk heeft. In elk geval is het praktisch mogelijk om in een assurancerapport ook een mapping op te nemen naar de meest bekende standaarden, zodat de gebruiker kan zien welke elementen in het rapport zijn afgedekt.

Hoewel niet exclusief voor cloud computing is een korte beschrijving opgenomen van de sterke en zwakke punten van de verschillende meest gebruikte assurancerapportages, te weten ISAE 3000 algemeen, ISAE 3000 / SOC 2 en ISO 27001/2. Zie ook het artikel van Ronald Koorn en Suzanne Stoof in deze Compact.

C-2013-2-Gils-t01

Tabel 1. De sterke en zwakke punten van ISAE 3000 algemeen, ISAE 3000 / SOC 2 en ISO27001/2.

Hoewel dit overzicht oppervlakkig en verre van compleet is, geeft het enig houvast bij de achtergrond. In de wandelgangen wordt wel gesteld dat de ISAE-normen vrijer zijn te definiëren dan de ISO-normen (voorgedefinieerd), maar dat de controle op de naleving van de beheersingsmaatregelen bij ISAE strenger is dan bij ISO.

Deze standaarden hebben als nadeel dat ze tamelijk star zijn. De ontwikkeling van de standaarden duurde jaren en aanpassingen op de standaarden navenant, hoewel de normenkaders wel voor iedere audit aangepast kunnen worden. Ook het resultaat is tamelijk star. Veelal wordt gerapporteerd in perioden van een jaar en bij ISO zelfs drie jaar.

Het doel van dergelijke rapportages is tweeledig: vooraf dient goed nagedacht te worden over de noodzakelijke beheersingsmaatregelen in relatie tot de dienstverlening. In de praktijk leidt dat veelal tot een kwalitatief beter doordacht stelsel van interne controle. Achteraf wordt vastgesteld of de beheersing van het gewenste niveau is geweest. Ook dat is feitelijk een preventieve maatregel, want achteraf vertellen dat een beheersingsmaatregel in het verleden niet goed heeft gefunctioneerd is niet zo zinvol: of het kwaad is al geschied en dat heeft de klantorganisatie dan al zelf ervaren of het gebrekkig functioneren heeft geen kwaad tot gevolg gehad en dan maakt het over het afgelopen jaar ook niet meer uit. Kortom, de doelstelling van dergelijke onderzoeken is toekomstgericht: eerst het verbeteren van het stelsel van interne beheersing en vervolgens vaststellen of bevindingen uit het verleden aanleiding zijn voor de toekomst om verbeteringen in de processen en/of hulpmiddelen aan te brengen.

De vraag doet zich nu voor of de periodieke ‘zekerheid’ van de huidige assurancerapportages toereikend is voor de doelgroep, veelal de gebruikersorganisaties van de clouddienstverlening. Vraagtekens kunnen worden geplaatst bij de lange doorlooptijd (veelal een jaar) en bij de inhoud.

Dynamisering

In de vorige paragraaf is de vraag opgekomen of gebruikersorganisaties van clouddiensten nog behoefte hebben aan assurancerapportages die tot een jaar teruggaan. In toenemende mate zal dit niet meer het geval zijn. De assurancestandaarden houden overigens het frequenter rapporteren niet tegen maar geven er ook geen expliciete richtlijnen over. Ook nu komt het in de praktijk voor dat reeds per kwartaal wordt gerapporteerd.

C-2013-2-Gils-01

Figuur 1. Dynamiseren door frequenter te rapporteren.

Op zich zullen de kosten slechts heel beperkt toenemen, want nog steeds wordt uitgegaan van een jaarlijkse audit, waardoor de waarnemingen zich over een jaar verspreiden. Wel zal ieder kwartaal een deel van de jaarlijkse controleactiviteiten moeten plaatsvinden, dus mogelijk zal de controlefrequentie iets omhoog gaan. De rapportages zijn afkomstig van de laatste vier kwartalen, zij omvatten dus wel steeds de bevindingen over een heel jaar, maar kunnen uit meerdere auditjaren komen. Eventuele tekortkomingen uit een eerdere periode kunnen door het management worden toegelicht en de auditor kan aangeven vanaf welk kwartaal de tekortkomingen zijn opgelost of niet meer voorkomen. Dit maakt het voor de lezer heel transparant, want de opvolging van tekortkomingen wordt hierdoor duidelijk zichtbaar gemaakt.

De vraag is of deze vorm van dynamiseren voldoet aan de behoeften van de uiteindelijke gebruiker.

Hierbij zijn er twee gedachtelijnen te onderkennen:

1. Vertrouwen en assurance

Deze gedachtegang sluit enigszins aan met de jaarrekeningcontrole. Door het jaar heen publiceert de organisatie (en publiceren los daarvan ook bijvoorbeeld veel analisten) allerlei gegevens die niet van een accountantsverklaring zijn voorzien, maar toch veelvuldig door stakehouders worden gebruikt. In dat licht lijkt het jaarverslag met de accountantsverklaring een late bevestiging van wat al door het jaar heen is gebeurd. Maar het geeft wel het beeld dat de organisatie over kwalitatief goede interne procedures beschikt om door het jaar heen ‘betrouwbare’ signalen af te geven.

In de cloudomgeving betekent dit dat jaarlijks bijvoorbeeld een ISAE 3000 / SOC 2-rapport wordt afgegeven en door het jaar heen de cloudprovider (ongecontroleerde) informatie over de kwaliteit van de dienstverlening verstrekt, bijvoorbeeld door periodieke Service Level Rapportages of accountmanagementgesprekken. Voor grotere groepen gebruikers kan natuurlijk ook gedacht worden aan dashboards op het internet.

De toereikendheid van deze gedachtelijn is dat enig vertrouwen onontbeerlijk is in de relatie tussen uitbestedende partij en serviceprovider en dat daarmee de tussentijdse berichtgeving wordt geaccepteerd totdat het tegendeel wordt bewezen. En voor dat bewijs geldt dan de periodieke assurancerapportage door een onafhankelijke derde partij. In dat kader zou overigens het proces van periodieke informatieverstrekking niet misstaan in de scope van het assuranceonderzoek.

2. Continuous auditing

Een andere gedachtelijn is dat zowel de serviceprovider als de klanten behoefte hebben aan een continu inzicht in de kwaliteit van dienstverlening en dat de serviceprovider de beste kwaliteit levert door daar heel transparant in te zijn. Ook weer in de vergelijking met de accountantsverklaring bij de jaarrekening: hoewel de accountant vaak het stelsel van interne controle (‘key controls’) beoordeelt, wordt een uitspraak gedaan over de getrouwheid van de jaarcijfers, niet de controls. Anders gesteld, ook voor de assurance bij cloudprocessing kan er behoefte zijn aan inzicht in concrete cijfers (KPI’s) naast assurance over (key) controls. Zeker bij IT-serviceproviders liggen veel kwaliteitsaspecten in systemen vast en is het met beperkte tooling niet zo’n grote opgave op een bijna continue wijze de beschikbare informatie te analyseren (‘continuous monitoring’) en te rapporteren in heldere dashboards, bijvoorbeeld op het internet. Het is daarbij mogelijk dat de externe auditor deze wijze van informatie verzamelen, analyse en rapportage met grote frequentie beoordeelt (‘continuous auditing’) en dat op enigerlei wijze ook kenbaar maakt. Hoewel daar nog geen goede voorbeelden van zijn, zijn vormen als web-seals hierbij denkbaar.

Deze vorm van assurance is vooral cijfermatig (‘substantive’) en geeft niet echt inzicht in de interne beheersingsmaatregelen. Daarmee wijkt zij dus af van de ‘controls’ assurance die wordt gerapporteerd in ISAE- en ISO-standaarden. Maar niet alle behoeften van gebruikers lenen zich voor substantive testing. In figuur 2 zijn voorbeelden gegeven van onderwerpen die zich goed lenen voor cijfermatige reporting en onderwerpen die meer passen bij de traditionele wijze van controls-assurancerapportage. Ook hier kan dus naast de dashboards nog een (beperkte) ISAE 3000 / SOC 2-rapportage worden opgeleverd.

C-2013-2-Gils-02

Figuur 2. Voorbeelden van onderwerpen voor rapportage via dashboards resp. traditionele controls testing.

In de ultieme cloudsituatie moeten serviceprovider en externe auditor in staat zijn de ‘assurance on demand’ te leveren waarvoor continuous monitoring/auditing steeds meer zal opkomen.

Voorbeelden van dashboards zijn op het internet te vinden, bijvoorbeeld http://outageanalyzer.com (zie figuur 3), of http://www.sciencelogic.com/product/technologies/public-cloud (zie figuur 4), of het voorbeeld in figuur 5, waarbij niet de cloudprovider zelf het dashboard publiceert maar andere partijen (Unified monitoring van Nimsoft).

C-2013-2-Gils-03

Figuur 3. Outage Analyzer.

C-2013-2-Gils-04

Figuur 4. Amazon Web Services Dashboard.

C-2013-2-Gils-05

Figuur 5. Unified Monitoring van Nimsoft.

Subserviceorganisaties

Naast dynamisering komt ook bij cloud computing vaak de vraag op over hoe om te gaan met subserviceorganisaties, oftewel organisaties waaraan de cloudprovider zelf weer heeft uitbesteed. Lang niet iedere cloudprovider besteedt diensten uit aan andere (sub)serviceproviders. Dan is er dus ook geen probleem en zal het assurancerapport alle relevante diensten en controls bevatten en kan de auditor die ook bij de cloudprovider controleren.

Indien er wel sprake is van uitbesteding door de cloudprovider geven de standaarden hiervoor de opties van ‘Carved out’ of ‘Inclusive’. Ingeval de cloudprovider niet de verantwoordelijkheid kan nemen voor de controls van de subserviceorganisatie, dan wel dat het de auditor niet toegestaan is de controls bij de subserviceprovider te controleren, dient ‘Carved out’ te worden toegepast. In dat geval zijn de diensten en controls van de subserviceprovider niet in scope bij de beoordeling van de cloudprovider. Voor de gebruiker van het rapport van de serviceprovider kan dit leiden tot een ‘blinde vlek’ in de totale keten en daarmee in zijn beeld van de totale beheersing. Mogelijk dat de subserviceprovider zelfstandig een assurancerapport uitbrengt, dat alsnog de blinde vlek voorkomt. In de praktijk betekent dit dat door de assurancevraag bij één partij vaak de hele keten van partijen wordt betrokken en in dat kader valt op dat steeds vaker juist – in tegenstelling tot de behoefte – de ‘Carved out’-methode wordt toegepast. Als compensating control zien we in het geval van carve out wel dat additionele controls worden opgenomen bij de cloudprovider, waaruit moet blijken dat de dienstverlening van de subserviceorganisatie wordt gemonitord. Denk daarbij weer aan service level agreements, periodieke terugkoppeling, etc. Zeker als de keten van uitbestedingen langer wordt en de dienstverlening in verre landen plaatsvindt, wordt het probleem steeds groter. Geen enkele assurancestandaard voor cloud computing heeft hier een oplossing voor en door de open markt voor cloud computing kan er ook geen systeem van regulering à la PCI-DSS van de grond komen, waarbij alle organisaties die creditcardgegevens opslaan aan die richtlijnen moeten voldoen.

Indien het krijgen van assurance over de hele keten echt van belang is, zal de uitbestedende partij dat nu van tevoren moeten overzien en eisen moeten stellen aan de cloudprovider over het wel of niet uitbesteden door de cloudprovider c.q. over de assurance die de cloudprovider bij uitbesteding door de hele keten heen kan bieden.

Conclusie

De opkomst van cloud computing leidt tot nieuwe behoeften op het gebied van verstrekking van assurance over de clouddienstverlening, met name over de beveiliging, privacy en beschikbaarheid. Meer fundamenteel is de vraag of assuranceverstrekking in staat is mee te bewegen met de ontwikkelingen. In zijn ultieme vorm is cloud computing zo dynamisch dat assurance in de traditionele vorm een belemmering kan gaan worden.

Dynamisering kan deels voor oplossingen zorg dragen, zeker voor die controls die niet praktisch zijn uit te drukken in actuele KPI’s of dashboards. Voor assurance voor diensten die wel in actuele KPI’s of dashboards zijn vast te leggen, lijken oplossingen in de vorm van continuous monitoring en auditing goed mogelijk.

Voor assurance over een hele keten van uitbestedende partijen staat de keten van cloudproviders en ook de beroepsgroep nog voor een uitdaging. Cloudproviders zullen niet in staat zijn (of niet willen zijn) door de hele keten heen assurance af te dwingen en daardoor zal de auditor dat ook niet kunnen doen. Indien wel assurance in de keten wordt geborgd doordat iedere partij een eigen assurancerapport oplevert, is er mogelijk voor de auditor van de uitbestedende partij een regiefunctie weggelegd om vast te stellen dat alle assurancerapporten bij elkaar het juiste beeld voor de oorspronkelijke uitbestedende partij opleveren.

Een mogelijke oplossing, die door cloudproviders nu wordt onderzocht, is de zekerheid niet meer bij de controls te zoeken maar de zekerheid te verbinden aan de datasets van de cliënt. Deze datasets kunnen uniek worden geïdentificeerd en zodanig opgeslagen dat ongeautoriseerde wijzigingen direct zichtbaar worden gemaakt. De technische mogelijkheden hiertoe zijn reeds ontwikkeld rond het dataverkeer en ook de mogelijkheden op gebied van encryptie zijn reeds bekend. Een andere mogelijkheid is het zoeken van zekerheid bij het systeem van de cloudprovider. Deze dient een systeem te hebben waarmee wordt bijgehouden waar de data van de cliënt zich bevindt. Dit systeem dient dan de waarborgen te bevatten dat het kwaliteitsaspect rond bijvoorbeeld security en privacy voldoende wordt afgedekt. Voor de beschikbaarheid dienen dan additionele maatregelen te worden getroffen, bijvoorbeeld door dubbele opslag bij verschillende ketens. Voordat deze oplossingen betrouwbaar en controleerbaar werken doet de uitbestedende partij er goed aan zich af te vragen welke risico’s gelopen worden door uitbesteding aan cloudproviders en welke assurance vereist is om de eigen verantwoordelijkheid nog te kunnen dragen. Indien de cloudprovider niet in staat is die assurance door de keten heen te kunnen verstrekken, zal de uitbestedende partij er verstandig aan doen niet met deze serviceprovider in zee te gaan c.q. beperkingen te eisen in de wijze waarop de cloudprovider met de diensten voor de uitbestedende partij mag omgaan en dat in een assurancerapport te laten controleren.

Bronnen

  • Diverse normenstelsels voor cloud assurance
    • CSA Cloud Security Alliance Framework
    • ENISA: Cloud Computing: Information Assurance Framework
    • ISACA: IT Control Objectives for Cloud Computing
    • The draft of the ISO/IEC 27017 (Cloud Security)
  • ISACA: Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives (2009)
  • KPMG-publicaties:
    • Audit and Compliance in the Cloud
    • IT Attestation in the Cloud
    • Service Organization Controls – Managing Risks by Obtaining a Service Auditor’s Report
    • Service Organization Reporting – Changes Ahead
    • Cloud Posters
  • Cloud security (SURF), waarin kritische noten inzake assurance (ISO en ISAE)
  • DNB: Circulaire cloud computing
  • Article 29 Data Protection Working Party: Opinion 05/2012 on Cloud Computing (European privacy)
  • P.C. (Peter) van Ulden, Security in the cloud, Security controls of IT solutions in the cloud, Master thesis Information Sciences, Vrij Universiteit Amsterdam, March 2013

Nieuwe ontwikkelingen IT-gerelateerde Service Organisation Control-rapportages

In de Verenigde Staten zijn nieuwe richtlijnen ontwikkeld voor assurancerapporten met betrekking tot de beheersing van IT-processen. Dit artikel geeft een toelichting en gaat in op hoe deze toegepast kunnen worden in Nederland, vanuit het perspectief van

  • de gebruiker (ontvanger van het rapport);
  • de samensteller van het rapport (IT-serviceorganisatie);
  • de auditor van het rapport.

Inleiding

Service Organisation Control (SOC)-rapport 2 en SOC-rapport 3; nieuwe begrippen met de volgnummers 2 en 3. De nummering maakt duidelijk dat er wordt voortgeborduurd op de SOC 1. Verdergaan in coderingen: SOC 1 is de opvolger van SAS 70. De namen zijn helaas niet zelfverklarend. Voor het begrijpen van de inhoud van de begrippen SOC 1, SOC 2 en SOC 3 is een bestudering van de achterliggende documentatie een vereiste. Echter, lang niet iedereen die ermee in aanraking komt is een professional die zich de tijd heeft gegund om SOC 2 en SOC 3 in detail te begrijpen. Hierdoor kunnen misverstanden en teleurstellingen ontstaan vanuit een verkeerde perceptie, waarbij de richtlijnen in werkelijkheid net wat anders in elkaar steken dan wordt gedacht. Eigenlijk zouden de richtlijnen meer in lijn moeten liggen met de natuurlijke perceptie van de gebruiker van assurancerapporten; dit zou veel misverstanden voorkomen. Maar helaas, het ontbreekt aan betere alternatieven. In dit artikel zullen de auteurs niet ten strijde trekken, maar uitleggen waar het om gaat. Mogelijk zijn SOC 2 en SOC 3 niet helemaal wat de verschillende partijen verwachten, maar blijken ze uiteindelijk toch wel goed te gebruiken.

Service Organisatie Control-rapport

De letters SOC staan zoals hiervoor gemeld voor ‘Service Organisation Control’. Dit helpt u waarschijnlijk nog niet echt op weg. Hiervoor moeten wij terug naar de bron van het begrip. Zoals bekend, is de USA SAS 70-standaard vervangen door ISAE 3402, opgesteld door de International Auditing and Assurance Standards Board ([IFAC09]). Landen kunnen deze standaard ongewijzigd overnemen of aangepast invoegen in hun lokale set van audit- en assurancestandaarden. In de Verenigde Staten is de standaard ingepast in de bestaande set van standaarden onder de codering SSAE 16. Tegelijkertijd heeft het Amerikaanse instituut van accountants (AICPA) de standaard de merknaam SOC 1 ([AICPA13]) gegeven. Vanuit de Verenigde Staten is er veel promotie om de ISAE 3402-rapporten aan te duiden met SOC 1 in plaats van een verwijzing naar de standaard zoals in het verleden met SAS 70 het geval was.

De soorten SOC-rapporten zijn door een nummer onderscheidend gemaakt. ISAE 3402 / SOC 1-rapporten kunnen uitsluitend betrekking hebben op beheersingsmaatregelen die een (indirecte) relatie hebben met de financiële verslaglegging van de uitbestedende organisatie. Dit is zo in ISAE 3402 gedefinieerd. De standaard geeft aan dat in een situatie waarin er geen sprake is van een op de financiële verantwoording gerichte scope, gebruik moet worden gemaakt van assurancestandaard ISAE 3000. Waarbij wordt aangegeven dat het rapportagemodel van ISAE 3402 onder de algemene standaard ISAE 3000 kan worden gebruikt.

In lijn met SOC 1 heeft het Amerikaanse instituut van accountants in samenwerking met het Canadese instituut van accountants (CICA) een SOC 2-handleiding opgesteld voor rapportages met een specifiek IT-gerichte scope. Het is geen standaard maar een handleiding, die qua rapportageformaat en reviewwerkzaamheden verwant is aan de op ISAE 3402 gebaseerde SOC 1-handleiding ([AICPA11/1]). De handleiding SOC 2 is niet direct gerelateerd aan een specifieke standaard maar een toepassing van de algemene USA assurance standard AT 101, min of meer het equivalent van ISAE 3000.

De volgende in de rij is SOC 3. Dit rapport is een re-branding van Trust services-producten voor rapporten met betrekking tot serviceorganisaties. SOC 3 wordt gekenmerkt door een beperktere rapportage en de mogelijkheid tot een brede publicatie.

Nu de herkomst van de naam bekend is, volgt de uitleg over SOC 2 en SOC 3. Nadere informatie over SOC 1 (ISAE 3402) is te vinden in de recent verschenen KPMG praktijkgids 4, Service Organisatie Control-rapport, ISAE 3402 ([KPMG12]).

C-2013-2-Boer-t01

Figuur 1. De verschillen tussen SOC 1, SOC 2 en SOC 3. Bron: KPMG trainingsmateriaal.

Assurancerapport, de basisuitleg

De nu volgende basisuitleg is bedoeld om eenieder eenzelfde referentiekader te geven. Dit voorkomt misverstanden door verschillen in het begrip.

Verantwoordelijkheid voor de correcte uitvoering van een proces moet door de uitvoerder kunnen worden gedragen. Ten aanzien van eigen werk is dit niet zo moeilijk, daar is hij/zij zelf bij. Het wordt moeilijker als het werk door anderen wordt uitgevoerd. De verantwoordelijkheid moet dan worden gedragen door het uitvoeren van controles op de geleverde dienst/product en op basis van vertrouwen. Over het algemeen zijn geleverde tastbare producten goed op hun kwaliteit te beoordelen, bij diensten ligt dit meestal moeilijker. Afhankelijk van het belang van de dienst zal er behoefte zijn aan inzicht in de controlestructuur gericht op het voorkomen en tijdig herstellen van fouten.

De meest voor de hand liggende oplossing is om op bezoek te gaan bij de serviceorganisatie en zelf vast te stellen dat het proces onder controle is. Dit heeft een groot praktisch bezwaar. Het is in strijd met het realiseren van efficiëntievoordelen en het ontbreken van inhoudelijke kennis en ervaring om de controles te testen maakt deze vorm van controle moeilijk uitvoerbaar. Een oplossing is een onafhankelijk deskundige te vragen de controles te testen en hierover te rapporteren in de vorm van een assurancerapport. Dit kan in opdracht van de uitbestedende organisatie of in opdracht van de uitvoerende organisatie. Door als de uitvoerende organisatie (de serviceorganisatie) het initiatief te nemen houdt zij de regie over de reviews in handen. Het lijkt financieel voordeliger als het initiatief bij de uitbestedende organisatie ligt, maar dat ligt in de praktijk anders. Het coördineren van deze reviews, het toegang geven tot informatie over de uitgevoerde controles en het afstemmen van de bevindingen kost veel tijd. Ook dient rekening te worden gehouden met tijd voor de afstemming van het rapporteren om te voorkomen dat er door de reviewer een rapport wordt uitgebracht dat een negatiever beeld schetst dan de werkelijke situatie, hetgeen ook weer kan leiden tot extra vragen vanuit de opdrachtgever. Argumenten genoeg om als serviceorganisatie zelf het initiatief te nemen om tot een algemeen geaccepteerd assurancerapport te komen. Voor een review van een ISAE 3402 / SOC 1-, SOC 2- en SOC 3-rapport is de opdrachtgever altijd de serviceorganisatie.

Het uitbesteden van processen die van invloed zijn op de financiële verslaglegging kwam op gang bij de opkomst van de automatisering. IT[In het verleden Electronic Data Processing (EDP) genoemd.] was complex maar leidde tot een enorme efficiëntie. Op IT-services gerichte organisaties pakten deze dienstverlening op. Gezien de complexiteit en moeilijke schaalbaarheid wordt veelvuldig gebruikgemaakt van deze IT-serviceorganisaties. Accountants liepen er bij de controle van de jaarrekening tegenaan dat een deel van de beheersingsmaatregelen binnen de (uitbestede) IT-omgeving lag. Om in een situatie van uitbesteding zekerheid te krijgen over opzet, bestaan en werking van de voor de volledigheid en juistheid van de financiële verantwoording noodzakelijke beheersingsmaatregelen werd een rapport van een onafhankelijke auditor gevraagd ter bevestiging van de betrouwbaarheid van de verwerking. In de praktijk werden deze rapporten dikwijls aangeduid met ‘TPM’, wat staat voor ‘Third Party Mededeling’. Het is een verouderde en ongedefinieerde aanduiding; een term die heden ten dage dan ook niet meer kan worden gebruikt.

In het begin van deze eeuw vaardigden de Amerikanen de Sarbanes Oxley-wet uit. De wet leidde er onder andere toe dat beursgenoteerde bedrijven naast de jaarrekening ook een In-Control-verklaring moeten publiceren. Een verklaring die gebaseerd moet zijn op een gestructureerd en aantoonbaar internecontroleproces. De accountant moet de juistheid van de door het management afgegeven In-Control-verklaring beoordelen. Bij uitbesteding van delen van het bedrijfsproces kan, overeenkomstig aan de Sarbanes Oxley-wet gerelateerde auditstandaarden, een SAS 70 (later gevolgd door SOC 1 / ISAE 3402) gelden als onderliggende informatie om de beheersing van het uitbestede proces aan te tonen. Als eigen omspannende controls ontbreken zijn er slechts twee mogelijkheden: het zelf testen van de controls bij de serviceorganisatie of het opvragen van een SOC 1-rapport.

Veel aan de Amerikaanse beurs genoteerde bedrijven maken gebruik van serviceproviders buiten de Verenigde Staten respectievelijk sommige multinationals met een hoofdvestiging buiten de Verenigde Staten hebben ook een beursnotering in Amerika. Door het verplichte karakter van een assurancerapportage bij uitbesteding is de SAS 70-standaard, gevolgd door SOC 1 / ISAE 3402, breed in de belangstelling komen te staan. Het werd een de-factostandaard die ook werd gebruikt in uitbestedingsrelaties die geen enkele band hadden met de Verenigde Staten en die in Nederland de oude ‘TPM’ verdrong.

De beperking dat een SAS 70 volgens de standaard alleen betrekking kan hebben op beheersingsmaatregelen die een (indirecte) relatie hebben met de jaarrekening uitbestedende organisatie (de gebruikersorganisatie), werd dikwijls op een creatieve wijze opgelost. Zo ook de beperking dat de kwaliteitsaspecten continuïteit en compliance geen onderdeel uit kunnen maken van een SAS 70-rapport. Buiten de Verenigde Staten kon deze vrijheid worden veroorloofd omdat bijvoorbeeld vanuit de Nederlandse regels bezien uiteindelijk werd gewerkt onder de veel ruimere ISAE 3000-assurancestandaard. Hoewel het rapport met deze ruimere scope mogelijk onterecht de titel SAS 70 droeg, was het toch een volwaardig assurancerapport.

ISAE 3402 beperkt zich, gelijk SAS 70, tot een scope gerelateerd aan de financiële verslaglegging van de gebruikersorganisatie. De standaard is duidelijk. Artikel 3 stelt dat als er geen verband is met beheersingsmaatregelen met betrekking tot de financiële verslaglegging, de standaard niet van toepassing is. De standaard geeft concreet aan dat dan de algemene assurancestandaard ISAE 3000 van toepassing is. Hier is geen ontkomen aan!

Introductie SOC 2 en SOC 3

De ISAE 3402-standaard geeft aan dat het uitgewerkte rapportage- en assurancemodel ook gebruikt kan worden onder de algemene assurancestandaard, in de USA AT 101[AT 101 – Attest engagements in which a certified public accountant in the practice of public accounting is engaged to issue or does issue an examination, a review, or an agreed-upon procedures report on subject matter, or an assertion about the subject matter that is the responsibility of another party.], daarbuiten ISAE 3000[ISAE 3000 – Assurance engagements other than audits or reviews of historical financial information.]. Het Amerikaanse instituut van accountants heeft dit samen met zijn Canadese collega’s opgepakt en een assurancehandleiding ontwikkeld voor geautomatiseerde gegevensverwerking. Zij hebben dit in de markt gezet onder de naam ‘Reporting on Controls at a Service Organisation, relevant to security, availability, processing integrity, confidentiality, or privacy (SOC 2)’ ([AICPA11/2]).

In tegenstelling tot ISAE 3402 / SOC 1 ligt het normenkader vast in de SOC 2 / SOC 3-handleidingen. Het in de handleidingen opgenomen normenkader moet minimaal worden gevolgd. Het weglaten van onderdelen moet in het rapport worden gemotiveerd, bijvoorbeeld omdat ze niet van toepassing zijn. De beheersingsdoelstellingen zoals we deze onder ISAE 3402 kennen, zijn uitgewerkt in ‘Principles and Criteria’. Deze principles and criteria zijn niet nieuw. Ze komen overeen met de criteria en principles behorend bij door de AICPA en CICA ontwikkelde Trust Services Principles, Criteria and Illustrations ([AICPA12]).

Audittechnisch gezien zijn SOC 2 en SOC 3 gelijk. Ze zijn beide gebaseerd op the Trust Services Principles and Criteria. Het verschil is de rapportage en de verspreidingskring.

Een SOC 2-rapport is voor gebruik door een vooraf gedefinieerde groep gebruikers (gesloten verkeer), gelijk ISAE 3402 / SOC 1. Dit is over het algemeen het management van de organisaties waarvoor de in het rapport opgenomen processen zijn uitgevoerd en partijen die de betreffende organisaties controleren (accountants, toezichthouders). Ook de opbouw van het rapport is gelijk aan het format dat vastligt in ISAE 3402 / SOC 1.

Een SOC 3-rapport is een verkorte rapportage en heeft geen beperkingen in de gebruikerskring. Een auditor kan echter een SOC 3-auditorsreport slechts afgeven als voldaan is aan specifieke condities. Zo mag er geen sprake zijn van een ‘carve out’ en mogen er geen bevindingen zijn die aanleiding zouden geven voor kwalificaties in een SOC 3-auditorsrapport. Het te publiceren rapport heeft een karakter van een certificaat. Onder specifieke voorwaarden is publicatie op het internet mogelijk met gebruik van een SOC 3-beeldmerk (seal).

SOC 2- en SOC 3-rapporten kunnen betrekking hebben op een rapportagemoment (type I) of betrekking hebben op een rapportageperiode (type II). Hoewel niet zo strikt geformuleerd is onder normale omstandigheden de rapportageperiode een tijdvak van zes tot twaalf maanden. Onder bijzondere omstandigheden is een kortere tijdsperiode mogelijk. Het criterium is dat het rapport voor de gebruiker van toegevoegde waarde moet zijn en dat er geen misverstand mag kunnen ontstaan over de aard van de verstrekte zekerheid.

C-2013-2-Boer-02

Figuur 2. Criteria voor de keuze van het juiste SOC-rapport. Bron: http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/serviceorganization’smanagement.aspx.

Principles and Criteria

Het algemene assuranceraamwerk[NBA Stramien, NOREA assuranceraamwerk, IFAC assurance frame work.], de basis voor het uitvoeren van assuranceopdrachten door auditors, geeft aan dat een assurancerapport gebaseerd moet zijn op uitgangspunten (in het Engels criteria, in de standaard vertaald met het Nederlandse woord ‘criteria’ in de betekenis van benchmarks) die voldoen aan de kenmerken: relevantie, volledigheid, betrouwbaarheid, neutraliteit en begrijpelijkheid. In ISAE 3000 (de algemene assurancestandaard) ligt vast dat de kenmerken (criteria) van de rapportage aan deze vereisten moeten voldoen. ISAE 3402 vult de criteria specifiek in, waarmee het een ISAE 3402-rapport wordt. De verplichte systeembeschrijving, beschrijving van de transactieverwerking, beheersingsdoelstellingen/beheersingsmaatregelen, beschrijving van de controleomgeving komen direct voort uit de gedefinieerde criteria. De SOC 2-handleiding geeft aan dat de ISAE 3402-criteria van toepassing zijn en geeft een nadere concretisering voor de beheersingsdoelstellingen in de vorm van ‘Principles and Criteria’ Let hier op dat met criteria hier net wat anders wordt bedoeld. De ‘Principles and Criteria’ zijn in het Nederlands het beste aan te duiden met de normen waaraan de processen moeten voldoen.

SOC 3 is gebaseerd op dezelfde ‘Principles and Criteria’ die al eerder werden gebruikt voor de assuranceproducten WebTrust en SysTrust.

De gedefinieerde principles and criteria hebben betrekking op het beheersen van IT-infrastructuur, software, gegevens-/informatieopslag en de hierop betrekking hebbende handmatige en geautomatiseerde uitvoeringsprocedures.

De principles and criteria betreffen de volgende kwaliteitsaspecten:

  • Security

    ‘The system is protected against unauthorized access (physical and logical)’
  • Availability

    ‘The system is available for operation and use as committed or agreed’
  • Processing integrity

    ‘System processing is complete, accurate, timely and authorized’
  • Confidentiality

    ‘Information designated as confidential is protected as committed or agreed’
  • Privacy

    ‘Personal information is collected, used, retained, disclosed, and destroyed in conformity with the commitments’

Deze kwaliteitsaspecten zijn gedetailleerd uitgewerkt in de Trust Services Principles ([AICPA12]).

Het SOC 2- / SOC 3-rapport kan betrekking hebben op één of meer kwaliteitsaspecten. De principles and criteria met betrekking tot ‘Security’ vormen de basisset, die terugkomt bij de principles and criteria bij de overige vier kwaliteitsaspecten.

De principles and criteria zijn toegelicht met beheersingsmaatregelen: ‘illustrative controls’. Dit zijn voorbeelden respectievelijk suggesties. De review heeft betrekking op de werkelijk in de organisatie geïmplementeerde beheersingsmaatregelen. Voor het determineren van de beheersingsmaatregelen (controles) binnen de betreffende serviceorganisatie en om deze af te zetten tegen de principles and criteria is diepgaande IT-auditkennis en -ervaring nodig. Na het vaststellen van het aanwezig zijn van de juiste en volledige set van beheersingsmaatregelen is de volgende stap het uitvoeren van testen om vast te stellen dat de beheersingsmaatregelen zijn geïmplementeerd (type I) respectievelijk dat deze gedurende de rapportageperiode hebben gewerkt (type II).

SOC 2

De uitgangspunten (de principles and criteria) zijn voor een SOC 2- en SOC 3-rapport gelijk. Ook de werkzaamheden van de auditor om tot een assurancerapport te komen verschillen niet. Het verschil tussen SOC 2 en SOC 3 is de lay-out van de rapportage en de beoogde gebruikerskring.

De SOC 2-werkwijze en het rapportageformaat zijn vastgelegd in de AICPA guide ‘Reporting on controls at a service organisation’ ([AICPA11/1]). Deze guide bestaat uit de onderdelen:

  • Planning van de review
  • Uitvoeren van de review
  • Rapportering.

In de bijlagen van de handleiding staan voorbeelden van de management assertion en het auditors report opgenomen.

De opzet van de guide lijkt sterk op de, volledig op ISAE 3402 gebaseerde, SOC 1 guide ([AICPA11]). Het SOC 2-rapport krijgt hierdoor dezelfde ‘look and feel’ als het ISAE 3402 / SOC 1-assurancerapport. Het rapport bevat, kort samengevat:

  • Auditors report
  • Management assertion
  • Systeembeschrijving
  • Beschrijving van de algemene beheersingsmaatregelen (control environment)
  • Beheersingsdoelstellingen (afkomstig van Trust Services Principle and Criteria), beheersingsmaatregelen, door de auditor uitgevoerde testen en eventuele testbevindingen
  • Eventuele aanvullende informatie, deze valt buiten de scope van de testwerkzaamheden van de auditor.

Een SOC 2-assurancerapport is uitsluitend bestemd voor een gedefinieerde gebruikerskring. Deze wordt genoemd in het auditors report. Over het algemeen zal deze gebruikerskring zich beperken tot organisaties die gebruik hebben gemaakt van de service binnen de scope van het rapport. Bij een type 2-rapport zullen dit de organisaties zijn die gedurende de rapportageperiode gebruik hebben gemaakt van de services die binnen de scope van het rapport vallen en eventueel hun accountants en/of toezichthouders. Serviceorganisaties willen meestal ook de mogelijkheden hebben om het rapport te kunnen verstrekken aan potentiële gebruikers. Op zich is er geen bezwaar tegen om dit op voorhand toe te staan onder de conditie dat aan deze lezersgroep voorafgaande aan de verstrekking wordt gevraagd te bevestigen dat zij geen rechten aan het rapport kunnen ontlenen. Het rapport heeft immers betrekking op een periode waarin delen van processen van de potentiële relatie (nog) niet betrokken zijn in de scope van de review. Natuurlijk kan zonder meer de toezegging worden gedaan dat als zij klant worden, de door hen uitbestede processen in de scope van de review betrokken zullen worden.

SOC 3

De werkwijze en de te gebruiken teksten voor een SOC 3-rapportage zijn opgenomen in TSP Section 100 – Trust Services Principles, Criteria and illustrations for Security, Availability, Processing Integrity, Confidentiality and privacy. SOC 3 is een rebranding van WebTrust en SysTrust ([AICPA12]). Deze handleiding bestaat uit de principles and criteria, aanwijzingen systeembeschrijving en voorbeelden van management assertions en auditors reports. Het accent ligt op de te hanteren normen (principles, criteria and illustrations). De handleiding geeft nauwelijks aanwijzingen voor de wijze waarop de review moet worden uitgevoerd. Het uitgangspunt is de professionele werkwijze van de auditor. De aanwijzingen in de SOC 2-handleiding ten aanzien van het plannen en de uitvoering van een review moeten worden gezien als codificatie van een als in de professionele praktijk gevolgde werkwijze en zijn derhalve goed bruikbaar voor SOC 3-reviews.

Een SOC 3-rapport is bestemd voor eenieder die er kennis van wil nemen. Deze ongedefinieerde verspreidingskring brengt een aantal specifieke eisen met zich mee. Zo mag er geen carve out van subserviceorganisaties zijn toegepast en het auditors report mag geen kwalificaties bevatten. De rapportage is beperkter dan SOC 2-rapportage. Een type 2-rapportage kan met gebruik van een beeldlogo worden gepubliceerd op internet. Teruggaand in uw herinnering, dit is het model dat overeenkomt met het oude WebTrust/SysTrust. SOC 3 is niet meer dan een re-branding van deze producten. Overigens komt re-branding niet in de plaats van WebTrust en SysTrust. De assurance product brandings komen dus niet te vervallen.

Een SOC 3-rapport is alleen geschikt voor gebruikers die zekerheid willen hebben ten aanzien van de naleving van de principles and criteria binnen een serviceorganisatie, maar geen behoefte hebben aan een nadere onderbouwing. Is er wel behoefte aan een nadere onderbouwing, bijvoorbeeld voor de inpassing in het eigen control framework, dan is SOC 2 het geëigende rapportagemodel.

Publicatie op het internet

Voor de publicatie van een SOC 3-rapport op het internet wordt een verkort rapportagemodel gebruikt. Een model dat sterk lijkt op een certificaat. Dit kan ook. De gebruikte principles and criteria staan vast, de scope is eenduidig, en er mogen geen kwalificaties in het oordeel zijn.

Om gebruik te kunnen maken van het SOC 3-seal moet de auditorganisatie een licentie hebben. Voor de logistieke afhandeling zorgt het Canadese instituut voor accountants (CICA). Om publicatie te realiseren neemt de serviceauditor contact op met CICA voor het maken van de licentieafspraken. Voor de Nederlandse praktijk kan hierbij verwezen worden naar de door NBA als beroepsorganisatie gemaakte afspraken. Na het effectueren van de licentieafspraken tussen de lokale auditorganisatie en CICA kan de auditor rapporten aan CICA zenden om deze op hun server te publiceren. De serviceorganisatie plaatst het beeldmerk (WebTrust / SysTrust / SOC 3) op zijn website met een link naar de CICA WebTrust-server. Zie voor een voorbeeld http://www.godaddy.com met een link onder aan de site. Voor het gebruik van het seal worden door CICA aan de auditor licentiekosten doorbelast.

C-2013-2-Boer3a

Figuur 3. SOC 2 Guide.

Publicatie op het internet, met of zonder seal, heeft invloed op afspraken die de auditor met de serviceorganisatie zal maken. Zo zullen er afspraken gemaakt moeten worden over de tijdsduur dat het rapport op het internet toegankelijk is en over het eerder verwijderen van de publicatie op het moment dat er fundamentele veranderingen zijn waardoor de inhoud van het rapport niet meer aansluit op de actuele situatie. Let wel, de SOC 3-assurancerapportage geeft alleen een oordeel over een in het verleden liggende periode. Alhoewel het formeel niet kan, ontleent de gebruiker er toch zekere waarborgen voor de toekomst aan, de auditor moet hier rekening mee houden om misverstanden te voorkomen. Bij wijziging van de omstandigheden zal er (vervroegd) een nieuw assurancerapport moeten komen. Wordt het rapport niet vervangen of wordt het niet verwijderd dan kan de gebruiker in de veronderstelling verkeren dat de betreffende principles and criteria nog steeds worden gerealiseerd. De auditor zal de afspraken aangaande de publicatie vastleggen in de engagement letter of een specifieke release letter. De procedures aangaande het AICPA/CICA-webseal zijn vastgelegd in de ‘International Seal Usage Guide’ ([AICPA/CICA04]).

SOC 1, SOC 2, SOC 3 en andere rapportagevormen

Serviceorganisatierapporten zijn er in vele soorten. Het ISAE 3402 / SOC 1-rapport is gericht op beheersingsmaatregelen die van invloed zijn op de financiële verslaglegging van de uitbestedende organisatie. Dit is vastgelegd in een wereldwijd geaccepteerde standaard die weinig ruimte laat voor een eigen invulling. De kracht hiervan is dat de verwijzing naar de standaard aangeeft wat de gebruiker kan verwachten.

C-2013-2-Boer-03

Figuur 4. Webseals. Bron: www.webtrust.org.

Het Amerikaanse en het Canadese instituut van accountants hebben op basis van het ISAE 3402 / SOC 1-rapport rapportages ontwikkeld gericht op het geven van assurance over IT-gerelateerde processen met betrekking tot de kwaliteitsaspecten beveiliging, beschikbaarheid, betrouwbaarheid, vertrouwelijkheid en/of privacy onder de naam SOC 2 en SOC 3. Hetgeen in detail uitgewerkt is in een handleiding. Ook hier geldt weer dat door het gebruik van de aanduiding SOC 2 of SOC 3 precies bekend is wat verwacht mag worden.

Er is wel een verschil tussen enerzijds ISAE 3402 / SOC 1 en anderzijds SOC 2 / SOC 3. De laatste is een handleiding om een algemeen herkenbare maar ook specifieke invulling te geven aan de algemene assurancestandaard ISAE 3000[In Nederland door NBA en NOREA geïmplementeerd als NV COS 3000 respectievelijk richtlijn 3000.]. Het is geen keurslijf. De ISAE 3000-standaard geeft de elementen aan waaruit een assurancerapport opgebouwd moet zijn. Maar biedt binnen deze kaders veel keuzes ten aanzien van de mate van zekerheid, de opbouw van de rapportage, en de invulling van de normenset. Onderdelen uit de SOC 2 / SOC 3-handleiding zoals de opbouw en de gedefinieerde principles and criteria kunnen worden gebruikt om tot een passend assurancerapport te komen. Let wel op dat een rapport slechts een SOC 2 / SOC 3-rapportage genoemd kan worden als het geheel aan de richtlijnen voldoet. SOC 2 / SOC 3 zijn door middel van een US Service Mark beschermde producten.

Het voordeel van het gebruik SOC 2 / SOC 3 is dat het rapport voor de opdrachtgever simpel te benoemen is en voor de gebruiker direct herkenbaar zal zijn. Hetgeen van grote waarde is als het rapport gebruikt wordt in relatie tot breed gebruikte producten als IT-cloudservices.

C-2013-2-Boer-05

Figuur 5. SOC 1 vergelijken met SOC 2 en SOC 3. Bron: KPMG trainingsmateriaal.

Review door de auditor

De SOC 2 / SOC 3-rapportage wordt opgezet door de serviceorganisatie en wordt beoordeeld door de auditor. De auditor beoordeelt de toereikendheid van de systeembeschrijving en de beschreven beheersingsorganisatie gegeven de scope, waarna hij vaststelt dat de beschrijving overeenkomstig de werkelijkheid is op het rapportagemoment bij een type 1-rapport of gedurende de rapportageperiode voor een type 2-rapport. Ten aanzien van de controls stelt de auditor vast of deze toereikend zijn voor de van toepassing zijnde principles and criteria gevolgd door testen gericht op het vaststellen van een toereikende implementatie bij een type 1-rapport en de effectieve werking bij een type 2-rapport. In een SOC 2-rapport worden, gelijk als bij ISAE 3402 / SOC 1, de uitgevoerde testen in het rapport gedocumenteerd.

Het spreekt voor zich dat het genoemde beoordelingswerk alleen uitgevoerd kan worden door auditors die voldoende in de materie zijn onderlegd. Zowel ten aanzien van assurancerapportages als ten aanzien van de realisatie van de betreffende kwaliteitsaspecten in de IT-omgevingen waar de rapportage betrekking op heeft. Geconcretiseerd, bij uitstek het werkterrein van register IT-auditors, de RE.

De testen bestaan uit interviews, observaties, inspecties en het herhaald uitvoeren van beheersingsmaatregelen. SOC 2 / SOC 3 is hierin niet anders dan andere assurancerapporten. De handleiding geeft een template voor het auditorsrapport. Bij gebruik van deze template buiten de Verenigde Staten moet er een verwijzing in zijn opgenomen naar ISAE 3000 of de lokale implementatie (in Nederland NV COS 3000 / Richtlijn 3000).

Let op, de managementbewering is een verplicht rapportageonderdeel van een SOC 2 / SOC 3-rapport. Hierin geeft het management aan dat het rapport aan de criteria van de SOC 2 of SOC 3-handleidingen voldoet en dat de beschreven situatie overeenkomstig de werkelijke situatie is. Ook voor dit onderdeel geldt dat in de handleidingen een model managementbewering is opgenomen en dat dit model gebruikt moet worden wil er sprake zijn van een SOC 2- of SOC 3-rapport. De managementbewering is de verantwoordelijkheid van het management. De auditor spreekt zich, als bij ISAE 3402 / SOC 1, niet uit over de getrouwheid van de managementbewering, alhoewel hij wel vast moet stellen dat het management voldoende basis heeft om tot de bewering te komen.

Conclusie

SOC 2 / SOC 3-assurancerapportages bieden kansen voor het uniformeren van op IT-processen gerichte assurancerapportages. Een wereldwijde uniformiteit maakt de rapportages ook goed toepasbaar in een internationale werkomgeving.

De kort en krachtige SOC 3-rapportages sluiten bijzonder goed aan bij IT-cloudservices, ofwel ‘assurance in de cloud’. De aard van clouddiensten brengt met zich mee dat de gebruiker niet geïnteresseerd is in de details, een verkorte rapportage zal dus voldoen. Cloudservices kennen over het algemeen geen landsgrenzen, een internationaal herkend en erkend assuranceproduct past hier uitermate goed bij.

Een SOC 2-rapport past bijzonder goed als de gebruiker inzicht wil hebben in de verwerkingsprocessen en de beheersingsmaatregelen, en daar waar een ISAE 3402 door het ontbreken van een relatie met de financiële verslaglegging niet past.

Een tegenwerping voor het gebruik van deze producten zou kunnen zijn dat het Amerikaanse producten zijn. Maar de ervaring leert dat een in de Verenigde Staten breed gedragen product door de grote verbondenheid van de Verenigde Staten met de rest van de wereld al snel een internationaal karakter gaat krijgen. Vooral als er geen alternatieven voorhanden zijn. Doordat SOC 2 / SOC 3 goed kan worden ingepast in de ISAE 3000-standaard is er geen enkel beletsel om de SOC 2-handleiding voor assurancerapporten en Trusted services principles, criteria and illustrations (TSP 100) buiten Amerika en Canada te gebruiken. Het geeft een framework voor concrete rapportage en de op specifieke IT-kwaliteitscriteria gerichte normen geven een goede invulling van de inhoudelijk lege assurancestandaard ISAE 3000. In de Verenigde Staten en Canada is het wellicht een keurslijf, maar daarbuiten kunnen de SOC 2- en SOC 3-handleiding worden gebruikt om tot op maat gemaakte assurancerapporten te komen. Maatwerk, dat door het gebruik van een generieke handleiding als basis, waarborgen in zich heeft ten aanzien van kwaliteit en herkenbaarheid van het rapport.

Bronnen

[AICPA/CICA04] AICPA/CICA, International Seal USAGE Guide, 2004 (http://www.cica.ca/resources-and-member-benefits/growing-your-firm/trust-services/item10817.pdf).

[AICPA11/1] AICPA, guide Service organisations applying SSAE No. 16 Reporting on controls at a service Organisation (SOC 1), New York, May 2011.

[AICPA11/2] AICPA, guide reporting on controls at a service organisation relevant to Security Availability. Processing, Integrity, Confidentiality or Privacy (SOC 2), New York, May 2011.

[AICPA12] AICPA, TSP Section 100 Trust Services principles, criteria and illustrations for security, availability, processing integrity, confidentiality, and privacy, New York 2012.

[AICPA13] AICPA Service Organization Control Reports Logos, http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/soclogosinfo.aspx, maart 2013.

[IFAC09] IFAC, international auditing and assurance standards board, ISAE 3402, Assurance Reports on Controls at a Service Organization, New York, 2009.

[KPMG12] KPMG, praktijkgids 4, Service Organisatie Control-rapport, ISAE 3402 Amstelveen 2012.

Grip op de kwaliteit van software

Software rukt (nog) steeds verder op in samenleving en bedrijfsleven. Softwarefouten kunnen daarbij grote impact hebben, voor de reputatie en het budget van de onderneming of overheid. Het op goede wijze ontwikkelen van software is een keuze die niet alleen om inzet en volwassenheid vraagt van de softwareontwikkelaars, maar ook van hun leidinggevenden en het management! Er zijn goede en efficiënte hulpmiddelen beschikbaar om de softwarekwaliteit te meten en te beïnvloeden. Dat leidt tot effectievere software die voor lagere kosten kan worden gerealiseerd en gebruikt!

Inleiding

De noodzaak voor software van goede kwaliteit is in het digitale tijdperk van vandaag groter dan ooit. Vooral omdat kwalitatief slechte software kan leiden tot kapitaalverlies, gegevensverlies en imagoschade. Zoals bijvoorbeeld blijkt uit een incident bij de Knight Capital Group in de zomer van 2012: door een mislukte upgrade van hun trading software verloor men gedurende 44 minuten 10 miljoen dollar per minuut. Het verhaal, onder andere door de New York Times gerapporteerd ([TNYT12]), heeft de managers van de hele wereld wakker geschud over een onderwerp dat normaal weinig media-aandacht krijgt: softwarekwaliteit.

Softwarekwaliteit heeft vele aspecten; één daarvan die vaak het nieuws haalt is beveiliging en betrouwbaarheid van gegevens. Een voorbeeld van een niet-betrouwbare applicatie troffen wij aan bij een ziekenhuis dat tien jaar probleemloos draaide met de software totdat opeens drie dagen aan patiëntengegevens zoek waren. De ontwikkelaars van de software vonden één niet correct afgehandelde foutsituatie in de software en hebben dit probleem verholpen. Achteraf bleek dat een duct tape- of ‘houtje-touwtje’-oplossing. Onderzoek van de auteurs toonde daarna aan dat er nog meer mogelijkheden aanwezig waren die konden leiden tot ongewenst gegevensverlies.

Een ander belangrijk aspect van softwarekwaliteit is de performance. Ter illustratie, voor iedere 100 milliseconden dat een klant minder hoeft te wachten bij het laden van Amazon.com stijgt de omzet met 1%! ([King08]).

Met het goed uitvoeren van een software-implementatie kan veel geld worden bespaard; een kortere doorlooptijd leidt immers direct tot lagere projectkosten. Veel vooruitgang is er daarom geboekt met gestandaardiseerde projectaanpakken zoals Prince2 en MSP, maar in de praktijk blijkt een te sterke sturing op tijd en budget de overhand te hebben, het softwarekwaliteitsaspect blijft vaak onderbelicht. Uiteraard is kwaliteit een onderdeel van deze methoden, maar vooral vanuit een procesmatig oogpunt, de feitelijke invulling van de kwaliteitstesten wordt niet verder uitgewerkt.

Veel projecten beperken zich tot een serie van testen aan het einde van het project en dan alleen op die kwaliteitsaspecten van software die aan de buitenkant waarneembaar zijn, zoals vooral functionaliteit, en in beperkte mate integratie en performance.

Door deze in de praktijk gegroeide aanpak ontstaan twee risico’s. Het eerste is een projectrisico: door te testen aan het einde van het project worden fouten vaak te laat in het proces gevonden, waardoor de impact op de einddatum groot is. Het tweede risico is subtieler en wordt ‘technische schuld’ genoemd. De voorbeelden aan het begin van deze inleiding zijn het gevolg van technische schuld. Dit betekent dat de software ogenschijnlijk goed werkt, maar onder de motorkap niet op een optimale manier is gerealiseerd. Vaak op ongewenste momenten leidt dat eens tot problemen.

Men noemt het schuld omdat er vaak op korte termijn een voordeel wordt behaald door inzet van suboptimale, tijdelijke, oplossingen met het plan om dit later te corrigeren. Het daadwerkelijk corrigeren van deze tijdelijke oplossingen (aflossen van de schuld) laat vaak lang op zich wachten. Naast deze bewuste technische schulden zijn onbewuste technische schulden, ofwel defecten – het systeem doet niet wat ervan verwacht wordt – ook een bron van geldverspilling. In een onderzoek van Jones en Bonsignour ([Jone12]) is aangetoond dat in elke fase van softwareontwikkeling, te beginnen bij het uitwerken van een idee, defecten worden geïntroduceerd en dat hoe later in de tijd de problemen worden opgelost, hoe hoger de kosten zijn. Door het uitstellen van het inlossen van de technische schuld lopen dus ook de kosten verder op. Deze kosten zijn in zekere zin te vergelijken met intrest op een schuld, alleen zijn de percentages fors hoger dan in de huidige financiële markten gebruikelijk is.

Het is duidelijk van groot belang om inzicht te hebben in en sturing te geven aan de kwaliteit van software, maar zoals aangegeven verloopt dit vaak nogal ad hoc. In dit artikel presenteren we een raamwerk voor softwarekwaliteit en de mogelijkheden om kwaliteitsaspecten eenvoudig te meten en, door herhaling, mogelijk verbetering aan te tonen. Uit praktijkvoorbeelden zal blijken hoe nuttig de toepassing van het raamwerk kan zijn.

Softwarekwaliteitsraamwerk

Wat is softwarekwaliteit? Hoe wordt de kwaliteit van software getoetst? Is software van goede kwaliteit als het bedrijfsprocessen ondersteunt? Of wanneer gegevens op een veilige en betrouwbare wijze zijn verwerkt? Is de software voor de eindgebruiker makkelijk te gebruiken? De behoefte om alle relevante vragen in kaart te brengen en meetbaar te maken heeft geleid tot een kwaliteitsstandaard voor software, namelijk de ISO-standaard 25010 ([ISO]), die de opvolger is van de ISO 9126-standaard. De ISO 25010-standaard is verdeeld in acht aspecten die op hun beurt onderverdeeld zijn in aantal subaspecten (zie figuur 1). De ISO 25010-standaard geeft een raamwerk om de kwaliteit van een stuk software in kaart te brengen. Net als voor de meeste raamwerken geldt dat voor een individueel systeem niet alle aspecten even belangrijk zijn. Bijvoorbeeld de beveiligingseisen voor een publieke internetapplicatie zoals internetbankieren zijn natuurlijk strikter dan voor een lokaal draaiend administratiepakket. Wel moeten beide applicaties in een hoge mate betrouwbaar zijn als het gaat om de kwaliteit van gegevens.

C-2013-2-Amoraal-01

Figuur 1. De aspecten en subaspecten van de ISO 25010-standaard.

De ISO 25010-standaard is zeer uitgebreid gedocumenteerd en bevat ook methoden om veel van de gedefinieerde kwaliteitsaspecten te meten. Wat ontbreekt is een normering die aangeeft wanneer een score op een aspect als ‘goed’ of ‘slecht’ mag worden beschouwd. Dit is niet heel verwonderlijk, het is namelijk lastig, zo niet onmogelijk, om normen vooraf te bepalen omdat deze zeer van de context afhankelijk zijn. Wel zijn er benchmarks beschikbaar voor een aantal aspecten, zoals bijvoorbeeld onderhoudbaarheid. Maar ook mét deze benchmarks moet een beoordeling van de kwaliteit met zorg worden gemaakt; een vergelijking tussen systemen met een andere context is vragen om verkeerde gevolgtrekkingen. Om hieraan tegemoet te komen is er een aantal best practices gedefinieerd voor verschillende applicaties en platformen die binnen de context van de ISO 25010-standaard vallen.

In elk gesprek over softwarekwaliteit hoort ook de discussie over prijs-kwaliteitverhoudingen een rol te spelen. Wat zijn de kosten van een defect? Wat zijn de kosten om de kwaliteit echt te verbeteren? Wat zijn de (onderhouds)kosten als we vanuit de huidige situatie doormodderen? Er bestaat een groot verschil bij de analyse wanneer deze vragen worden beantwoord voor bijvoorbeeld vliegtuigsoftware waarbij mensenlevens op het spel staan, of spelsoftware voor een flight simulator.

Maar elke discussie over softwarekwaliteit moet uiteindelijk vooral over de software zelf gaan. Want alleen met kennis van de software zelf zijn zinnige afwegingen over de kwaliteit te maken. Dat sluit aan bij de praktijk dat vaklui, die ‘software engineering’ als ambacht zien, in staat zijn om herhaalbaar op een succesvolle wijze software te maken. Deze vaklui accepteren dan ook alleen kwaliteitstoetsen die de techniek en context van het product in beschouwing nemen.

Naar de bron

Meten is weten, maar wat bedoelen we precies wanneer we spreken over het meten van software? Wanneer ontwikkelaars spreken over software bedoelen ze altijd de broncode, zie het kader voor een voorbeeld. Deze broncode is het meest bepalend voor de kwaliteit van de software. De code beïnvloedt direct vijf van de acht kwaliteitsattributen (‘Functional Suitability’, ‘Performance Efficiency’, ‘Reliability’, ‘Security’, ‘Maintainability’). Zeker de onderhoudbaarheid (‘Maintainability’) is gebaat bij goede code. Met onderhoudbaarheid bedoelen wij de inspanning die nodig is om onderhoud en uitbreidingen op de software uit te voeren. Voor kosteneffectief onderhoud is het noodzakelijk dat de structuur en architectuur van de software inzichtelijk zijn en de broncode goed leesbaar is en begrijpelijk is gedocumenteerd. Anders gezegd, er is sprake van weinig of geen technische schuld.

Wat is broncode?

Simpel samengevat is een applicatie niks anders dan een set instructies in een voor een machine begrijpelijke taal die door de computer wordt uitgevoerd. Deze machinetaal is afhankelijk van de specifieke computerhardware en dusdanig complex dat deze onbegrijpelijk is voor mensen. Om het schrijven en ontwikkelen van een applicatie te vergemakkelijken, te versnellen en onafhankelijk te maken van de hardwarekeuzes, zijn er over de jaren heen verscheidene programmeertalen ontwikkeld die meer op mensen gericht zijn. Elk van deze talen heeft een vergelijkbare uitdrukkingskracht, maar heeft zijn eigen woordenboek, grammatica en bijzonderheden; vergelijk dit met natuurlijke talen zoals Engels ten opzichte van Nederlands. Deze programmeertalen zijn ook continu aan het doorontwikkelen; vergelijk het toevoegen van woorden als ontvrienden aan de Nederlandse taal.

De bestanden met tekst, geschreven in één van deze programmeertalen, noemen we broncode. Een simpel voorbeeld van broncode is de volgende regel tekst geschreven in de programmeertaal Python, een voorbeeld van een mensgerichte taal. Deze regel zorgt dat de tekst ‘Hello World’ op het scherm wordt weergegeven, ofwel wordt geprint op het scherm.

print ‘Hello World’

Om een indruk te geven van de complexiteit van de machinetaal die hieraan ten grondslag ligt volgt hieronder de machinetaal die nodig is om hetzelfde resultaat te bereiken wanneer dit programma wordt uitgevoerd op een Intel machine (x86-architectuur).

section .data

str: db ‘Hello world!’,

str_len: equ $ – str

section .text

global _start

_start:

mov eax, 4

mov ebx, 1

mov ecx, str

mov edx, str_len

int 80h

mov eax, 1

mov ebx, 0

int 80h

De kwaliteit van de broncode bepaalt dus in belangrijke mate de kwaliteit van de software. Om de kwaliteit van de broncode te toetsen zijn er veel geautomatiseerde hulpmiddelen voor vrijwel elk platform beschikbaar waarmee veel inzicht, zeker rond het aspect onderhoudbaarheid, is te verkrijgen. Deze hulpmiddelen zijn vaak nagenoeg gratis en geven veel nuttige en objectieve informatie over de kwaliteit van de broncode. Deze hulpmiddelen lezen automatisch de broncode, verzamelen kengetallen en toetsen de broncode tegen relevante ‘good practices’ ten aanzien van spelling, grammatica en schrijfstijl. In figuur 2 geven de omcirkelde stukken bijvoorbeeld aan dat er sprake is van een groot stuk software dat bestaat uit ruim 600.000 regels broncode en deze voldoen voor 87,2% aan de voor deze taal van toepassing zijnde grammatica- en stijlregels.

C-2013-2-Amoraal-02

Figuur 2. Samenvattende uitkomsten van geautomatiseerde hulpmiddelen voor een broncodeonderzoek.

We komen in onze praktijk weinig klanten tegen waar het (project)management dit soort (objectief) inzicht in de kwaliteit van de broncode heeft. Vaak zien wij dat enkel de betrokken programmeur haar/zijn code leest en beoordeelt. In onze praktijk voeren we dus als startpunt altijd een eenvoudige broncodescan uit met behulp van de relevante hulpmiddelen, om in korte tijd al veel inzicht in de kwaliteit van de broncode te krijgen. Dit inzicht wordt daarna door ons geïnterpreteerd, beschreven en voorzien van concrete aanbevelingen om de kwaliteit van de software te verbeteren. Het is onze ervaring dat de objectiviteit en meetbaarheid van deze aanpak veel inzicht en begrip geeft bij het (project)management, de gebruikersorganisatie en de softwareontwikkelaars.

Systeemarchitectuur – patronen en structuur

Goed werkende software komt niet alleen door goede broncode. Een applicatie bestaat vaak uit een samenspel van meerdere standaardcomponenten zoals een database, een webserver, enz. De keuze voor de specifieke componenten en de inrichting daarvan zijn uiteindelijk ook heel belangrijk voor een correcte werking van de applicatie. Het geheel van componenten en hun samenhang in relatie tot de applicatie wordt ook systeemarchitectuur genoemd. Bij de keuze van de systeemarchitectuur spelen aspecten zoals beveiliging, audit-trails, performance en gegevensuitwisseling met anders systemen een grote rol. Het moge duidelijk zijn dat bij het opstellen van de systeemarchitectuur keuzes en afwegingen moeten worden gemaakt ten aanzien van deze aspecten. Een goede systeemarchitectuur zorgt ervoor dat het voor de programmeur eenvoudig is om haar/zijn taken uit te voeren. Hoe eenvoudiger het programmeerwerk wordt gemaakt, hoe groter de kans dat het werk van goede kwaliteit is.

Voorbeeld van een systeemarchitectuur en dependencydiagram

C-2013-2-Amoraal-03

Figuur 3. Typische systeemarchitectuur van een webapplicatie met de programmeertaal Ruby.

Software van enige omvang dient gestructureerd te zijn opgezet; de gekozen structuur wordt software- of systeemarchitectuur genoemd. Door het systeem in verschillende componenten op te delen blijft de broncode in de componenten, door de scheiding van taken (‘separation of concerns’), eenvoudig. Dit bevordert de onderhoudbaarheid van het systeem! De weergave van de systeemarchitectuur maakt het verder mogelijk om met belanghebbenden over ontwerpbeslissingen te spreken.

Uit de broncode blijkt of de ontwikkelaars zich aan de systeemarchitectuurafspraken houden. Veelvuldig komen, zoals in het in figuur 4 weergegeven vereenvoudigd ‘dependencydiagram’, overtredingen aan het licht. Deze overtredingen hinderen altijd de onderhoudbaarheid en kunnen ook de betrouwbaarheid, performance en schaalbaarheid in gevaar brengen!

C-2013-2-Amoraal-04

Figuur 4. Een dependencydiagram geeft de afhankelijkheden van de softwarecomponenten weer. In het geïmplementeerde (MVC-) patroon horen visualisatie en businesslogica niet in één component te zijn opgenomen!

Maar als een systeemarchitectuur goed kan zijn, dan komt het ook voor dat de systeemarchitectuur niet effectief is ingericht. Een eenvoudig voorbeeld kwamen we tegen bij de review van het maatwerk op een standaard-CRM-pakket. Dit webgebaseerde standaardpakket had een horizontale schaalbaarheidsstrategie waarbij bij een toenemend aantal gebruikers eenvoudig additionele hardware kan worden ingezet voor de applicatiecomponent om de extra vraag op te vangen. Het aangebouwde maatwerk volgde echter een andere schaalbaarheidsstrategie door de applicatielogica binnen de database te programmeren. Door deze keuze zal bij een toenemend aantal gebruikers ook additionele hardware voor de databasecomponenten moeten worden ingezet. De gebruikskosten nemen hierdoor extra toe!

Genoemd voorbeeld geeft wederom aan waarom de afwijkingen van kwaliteitsstandaarden en architectuur van een systeem tegenwoordig vaak technische schuld worden genoemd. De ‘technische schuld’ an sich verhindert vaak de werking van een systeem niet. Wel dienen additionele kosten te worden gemaakt om de werking voor langere tijd te borgen. In dit voorbeeld wanneer op termijn het aantal gebruikers toeneemt.

Grip?

Kwaliteit inbedden in een project betekent vroeg defecten vinden en technische schuld aflossen, ofwel eerder in het project meten, testen en oplossen. Gevolg is een kwalitatief beter resultaat, kortere doorlooptijd en lagere kosten. Een additioneel voordeel van weinig defecten en technische schuld is dat men frequenter en met kortere doorlooptijden aanpassingen kan doorvoeren (en met minder desastreuze effecten als bij Knight Capital Group).

Een werkwijze van frequenter en geautomatiseerd testen, die ook goed aansluit bij de thans veelgebruikte Agile ontwikkelmethoden, is de DevOps-methode. In deze methode wordt er gestreefd naar goede samenwerking en informatie-uitwisseling tussen de ontwikkel- en de operationsorganisatie. Deze samenwerking, waar ook de naam DevOps symbool voor staat, wordt vormgegeven door gezamenlijke tooling, procesautomatisering en goede afspraken. Kenmerkend in deze aanpak is ook dat er veelvuldig kleine stukken software in gebruik worden genomen (en dus niet maar een of twee releases per jaar zoals in veel organisaties nog gebruikelijk is). Dit leidt tot een systeem met de gewenste lenigheid om snel fouten te corrigeren en aan nieuwe wensen te voldoen.

Let wel, deze aanpak garandeert geen foutloze software. Foutloze software is wellicht ook een utopie; zeker in een zakelijke omgeving waar het gevoel van urgentie voor softwarekwaliteit vaak te laat ontstaat om de daarvoor noodzakelijke resources en inspanning tijdig te mobiliseren. Maar door in staat te zijn (snel) ontwikkelde software in gebruik te nemen worden investeringen (eerder) te gelde gemaakt. En daar de gezamenlijke tooling de technische schuld inzichtelijk maakt worden hoge beheerlasten voorkomen!

Ook als de aandacht voor softwarekwaliteit niet vanaf het begin aanwezig is heeft het zin om de code te gaan onderzoeken en de kwaliteit in kaart te brengen. We troffen in een project dat al zes jaar liep een stuk software aan waarvan, zoals zo vaak, niemand wist hoe groot het was. Het bleek een omvangrijk stuk software met een grote ‘technische schuld’ – onder meer slecht leesbare en complexe code, veel afwijkingen van de architectuur en gebruik van (zeer) verouderde standaardsoftware. Het project had op dat moment geen tijd voor grote verbeterslagen, maar aandacht voor softwarekwaliteit voorkwam dat het probleem groter werd. Sterker nog – in relatieve mate werd de code door de tijd beter. Dit had ook een effect op de ‘oplostijd’ van de gevonden defecten. In figuur 5 is de kwaliteitsverbetering te zien (de software is hier hetzelfde als die in figuur 2). Het aantal regels code neemt toe van 570.000 naar 610.000; tegelijkertijd neemt de mate waarin de code voldoet aan de regels ook toe van 85,5% naar 87,2%. Deze verbetering wordt uitsluitend veroorzaakt doordat (vrijwel) alle toegevoegde regels aan de codeerstandaarden voldoen!

C-2013-2-Amoraal-05

Figuur 5. Ontwikkeling van het systeemvolume (in effectieve broncoderegels, eLoc) en een samenvattende kwaliteitsmetriek. Uit deze gegevens kan worden geconcludeerd dat, vanaf de start van de metingen, de kwaliteit van de broncode beter wordt.

Als iets belangrijk is dan moet daar vroegtijdig, en vanaf voldoende hoog (project)managementniveau, aandacht en urgentie aan worden gegeven. Voor veel zaken is kwaliteitsmanagement in organisaties vanzelfsprekend. Dit zou ook moeten gelden voor softwareontwikkeling en onderhoud. De praktijk wijst ook uit dat als de aandacht ontbreekt de kwaliteit vaak tegenvalt. In dit artikel is aangetoond dat het goed mogelijk is om op verschillende aspecten de kwaliteit transparant in kaart te brengen. In veel succesvolle trajecten gebeurt dat ook. Uiteindelijk helpt inzicht om succesvol de eindstreep te passeren met een goede blik op de ‘technische schuld’; een schuld die hoe dan ook gedurende het gebruik moet worden afgelost.

Conclusie

Problemen rond het maken en onderhouden van specifieke software zullen zeker het komend decennium niet verdwijnen. Een aantal software-incidenten haalt de publiciteit waarbij vaak de kosten van het incident zijn in te schatten. Matige softwarekwaliteit zorgt echter ook voor projecten die langer lopen en hogere onderhoudskosten. We voeren daarom in dit verband de term technische schuld in om duidelijk te maken dat softwarekwaliteit een zakelijk perspectief heeft.

Organisaties doen er daarom verstandig aan niet van kwaliteitsproblemen weg te kijken. Inzicht in de kwaliteit van software geeft de mogelijkheden om verbeteringen sneller te realiseren, lagere (onderhouds)kosten en betere houdbaarheid van de software. Het zo vroeg mogelijk adresseren van softwarekwaliteitsproblemen blijkt het meest efficiënt. Omdat ook inzicht in de softwarekwaliteit relatief eenvoudig, met geautomatiseerde hulpmiddelen, is te verkrijgen kan op feiten gebaseerd kwaliteitsmanagement worden ingericht.

Dit is alleen te bereiken met voldoende aandacht door (project)management voor softwarekwaliteit. De uitdaging is om het inzicht te krijgen dat software van goede kwaliteit aantoonbare waarde heeft voor de onderneming!

Bronnen

[ISO] ISO/IEC 25010:2011: Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE).

[Jone12] Capers Jones & Olivier Bonsignour, The Economics of Software Quality, Addison-Wesley 2012, ISBN 978-0-13-258220-9.

[King08] Andrew B. King, Website Optimization, O’Reilly Media, Inc., 2008, ISBN 978-0-596-515-08-9.

[TNYT12] The New York Times, Knight Capital Says Trading Glitch Cost It $440 Million, 2 August 2012, http://nyti.ms/NnZL8r.

#areyouincontrol?

Hoe enorm de kracht van social media is, heeft één van de machtigste zakenbanken onlangs moeten ondervinden. Goldman Sachs verloor door social media in één dag 2 miljard dollar aan beurswaarde. Om een organisatie te behoeden voor de potentiële gevaren van social media wordt in dit artikel inzicht gegeven in de risico’s van social media en de wijze waarop men zich hiertegen kan bewapenen. Om als organisatie ‘in control’ te zijn moeten vier aandachtsgebieden worden afgedekt. Een auditor speelt een cruciale rol bij het bepalen en toetsen van de in dit artikel genoemde risico’s en set aan beheersingsmaatregelen.

Inleiding

Hoe enorm de kracht van social media is, heeft één van de machtigste zakenbanken, namelijk Goldman Sachs, onlangs moeten ondervinden. Een ‘onschuldige en hardwerkende’ bankier Smith geeft een interview aan de New York Times. Het felle en kritische opiniestuk illustreert deze machtige zakenbank als een stel aasgieren peuzelend aan een karkas. Smith, die reeds zijn ontslag ingediend heeft, zet op zijn Facebook een link naar het onlineartikel. Binnen een paar uur is het stuk drie miljoen keer aangeklikt, opiniemakers twitteren het nieuws en wereldwijde weblogs reageren met ‘nog nooit grotere inkomensval voor Goldman’. In het huidige glorietijdperk van social media gaat het nieuws in een mum van tijd als een lopend vuurtje de wereld over. Goldman is compleet verrast en verliest die dag 2 miljard dollar aan beurswaarde.[Het Financieele Dagblad, 17 maart 2012, ‘Vampierinktvissen, aasgieren en muppets bij zakenbank Goldman Sachs’.]

Social media staan vandaag de dag prominent op de agenda van elke bestuursvoorzitter. Zij worden ondersteund door zowel beleidsmakers als consultants om wegen te vinden om de applicaties als Facebook, Wikipedia, YouTube en Twitter winstgevend in te zetten. En met succes; onderzoek heeft uitgewezen dat sterke merken een directe correlatie hebben met enerzijds een goede financiële prestatie en anderzijds een brede inzet van sociale media.[Engagementsdb, The world’s most valuable brands? Who’s most engaged? Ranking the Top 100 Global Brands.]

Om de organisatie te behoeden voor de potentiële gevaren van social media wordt in dit artikel inzicht gegeven in de risico’s van social media en de wijze waarop men zich hiertegen kan bewapenen. De beheersing van deze risico’s is een primaire verantwoordelijkheid van het lijnmanagement, maar ook speelt de auditfunctie een belangrijke rol. Hoe kunnen zij de organisatie toetsen, zodat aan de directie inzicht wordt gegeven over de mate van beheersing? Dit artikel moet een leidraad zijn om social media in organisaties op een beheersbare wijze in te richten, zodat u niet midden in de nacht badend van het zweet wakker wordt en denkt dat uw organisatie 2 miljard minder waard is.

Double-edged sword

Social media wordt door veel bedrijven angstig bezien als een double-edged sword. Hoe pluk je de vruchten van de mogelijkheden die de organisatie de beloofde boost bezorgen, terwijl de risico’s als wolven op de loer liggen? Organisaties moeten ook waken voor de negatieve impact en risico’s van deze nieuwe ontwikkeling. Opdroging van verkopen, schending van privacy, afbraak van vertrouwde merknamen, om maar een paar voorbeelden te noemen. Zoals het voorbeeld van Goldman Sachs laat zien, kan de impact in de miljarden lopen.

Als eerste dient gezegd te worden dat men social media niet links kan laten liggen, de laissez faire-methode is ook niet het antwoord. Social media is een must; het vereist een duidelijke visie wat de organisatie met social media wil bereiken. Kiezen voor een ad-hocaanpak vergt veel minder resources dan wanneer gekozen wordt om social media in te zetten als enige business driver. Deze laatste vraagt naast afstemming met de strategie van de organisatie, ook senior commitment en een voortdurende alignment van systemen, processen en cultuur. De gemaakte keuze bepaalt het financieel gewin.

‘Elk voordeel heb een nadeel’

Aan deze nieuwste ontwikkeling kleven ook risico’s met (financiële) negatieve implicaties. Overall gezien vormt reputatieschade één van de zwaarste risico’s in termen van moeilijk te corrigeren. Mensen vormen de sleutelpositie voor de reputatie van de organisatie. Wat te denken van de onderlinge communicatie waarbij de organisatie geschaad kan worden? Ongepast, lasterlijk en onjuist taalgebruik kan vervelende consequenties hebben voor de organisatie. Een conversatie wordt geïnitieerd en men reageert snel en open op elkaar, echter dit kan ook escaleren of een geheel andere wending krijgen. Dit levert hoe dan ook schade voor de organisatie op, opmerkingen van bijvoorbeeld klanten (of (ex-)werknemers) kunnen een eigen leven gaan leiden en zo de reputatie en merkbeleving schade toebrengen. Vaak is de persoon die een en ander geïnitieerd heeft al uit beeld en had hij of zij die negatieve intentie totaal niet.

Verkeerd gebruik social media

Op korte termijn kunnen social media leiden tot reputatieschade; de gebruikers van social media zetten de organisatie in een kwaad daglicht; dit kan snel verergeren als meerdere gebruikers meedoen. Het kan zelfs opgepakt worden door de media (consumentenprogramma’s en/of documentairemakers).

Op lange termijn kan het gebruik van social media leiden tot financiële schade; consumenten associëren de organisatie negatief; omzet en winst verminderen, in het ergste geval gaat de organisatie failliet.

Daarnaast mag het social netwerk van een onderneming niet gehackt worden door bijvoorbeeld malware. Malware staat voor ‘malicious software’. Dit is een verzamelnaam van kwaadwillende software die zich verspreidt in de programmatuur van de computer. Malware in relatie tot bijvoorbeeld Facebook zorgt ervoor dat het virus zich verspreidt onder gelinkte klanten, partners of andere contacten. Dergelijke aanvallen op Facebook en Twitter zorgen namelijk ook voor permissie aan de gelinkte gebruikers en data. Het ‘posten’ van berichten in naam van een werknemer of door een werknemer inclusief een linkje kan desastreuze gevolgen hebben voor de onderneming.[Mortleman, Social Media strategies, Computer fraud & Security.]

De internationale beroepsvereniging ISACA[De Information Systems Audit and Control Association (ISACA) is een internationale beroepsvereniging in de vakgebieden IT-governance, IT-auditing, informatiebeveiliging en risicomanagement van automatisering. Zij is wereldwijd actief in 160 landen, met meer dan 86.000 constituties.] heeft de risico’s van het gebruik van social media geclassificeerd in een viertal aandachtsgebieden:[ISACA, Social Media: Business Benefits and Security, Governance and Assurance Perspectives, May 2010.]

1 Social-media-inzet als businesstool

Bedrijven zetten social media steeds vaker in als businesstool. Hiermee worden social media benut als communicatiemiddel voor geïnteresseerden en potentiële consumenten. Maar wat als het communicatiemiddel niet helemaal juist gebruikt wordt?

2 Social-mediagebruik met toegang vanuit bedrijfsnetwerk

Social media worden steeds vaker uitgerold op bedrijfsmiddelen als laptop, iPad of mobiele telefoon. Dit zal in de toekomst verder worden uitgerold om het nieuwe werken in een flexibele kantoortuin mogelijk te maken. De bedrijfsapparatuur (computers en netwerk) wordt niet alleen gebruikt voor de bedrijfsapplicaties. Toegang via een browser wordt ook benut voor social media. Maar zijn met de introductie hiervan de gelinkte klanten dan nog wel veilig? Wat te denken van de bedrijfsgegevens en privacy van klanten?

3 Social-mediagebruik op mobiele telefoon

Het gebruik van social media wordt steeds persoonlijker en vindt steeds meer plaats op de mobiele telefoon. Social media worden hiermee laagdrempelig en het gebruik is daardoor explosief gestegen. Dit brengt echter ook specifieke risico’s met zich mee, hetgeen bevestigd wordt in de securityonderzoeken naar deze devices. Problemen hebben vaak te maken met de vele social-engineeringpogingen om informatie te achterhalen van gebruikers om zodoende ook toegang te krijgen tot het bedrijfsnetwerk. Wat te doen als de mobiele telefoons gestolen of verloren raken? Liggen de gegevens van de organisatie dan ook op straat of nog erger bij de concurrent?

4 Persoonlijk gebruik vanuit huis

Een laatste en meer controversiële overweging is het gebruik van social media in huis op privécomputers. Het beheer van de privédevices kan vaak niet geregeld en gecontroleerd worden door organisaties. Hoe moet hiermee worden omgegaan?

Afhankelijk waar de organisatie social media voor gaat inzetten zijn de bovenstaande vier aandachtsgebieden van toepassing. Ieder aandachtsgebied kent zijn eigen risico’s, en deze dienen (of beter gezegd moeten) te worden afgedekt. Daarbij speelt een auditor een belangrijke rol. Hij kan aangeven welke risico’s daadwerkelijk spelen, wat de ernst van de risico’s is en welke wijze van afdekken aan te bevelen is, en kan een onafhankelijke toetsing uitvoeren of de risico’s ook daadwerkelijk afgedekt worden.

In control

Voor een organisatie is het belangrijk om ‘in control’ te zijn. Het refereert aan de accountantsterm ‘statement of control’, dit is een ‘kwaliteitscertificaat’ waarin de mate van beheersing van de bedrijfsvoering beoordeeld wordt door auditors. Het geeft aan in hoeverre het management grip heeft op zijn processen. In het statement wordt verwezen naar:

  • een set van normen waaraan de beheersing getoetst is;
  • de in de processen opgenomen interne controles;
  • de aangetroffen tekortkomingen en de oorzaken hiervan;
  • en de voorgenomen maatregelen om de knelpunten op te lossen.

Gezien het risico dat social media vormen, is het voor een organisatie wenselijk ‘in control’ te zijn en de tekortkomingen tot een minimum te beperken. Dit betekent dat alle vier ISACA-aandachtsgebieden van de social-media-inzet moeten worden afgedekt. Eerst dient een overallplan te worden opgesteld. Hierin worden de ‘regels’ opgenomen omtrent het beheer van social media. Zo’n plan wordt ook wel het strategisch plan genoemd.

C-2012-4-Braaksma-01

Figuur 1. Strategisch plan voor beheer van social media.

Om ‘in control’ op de vier risicogebieden te zijn moet allereerst een social media strategisch plan opgesteld worden. Succesvolle strategische plannen dienen niet alleen te focussen op de social-media-tooling, maar vooral op de relaties met consumenten in combinatie met de bedrijfsdoelstellingen (opgesteld in strategisch organisatorisch plan). Het besef moet doorgedrongen zijn dat de primaire aandachtsgebieden van social media sociologisch en psychologisch zijn en daaraan gekoppeld het secundaire: technologie en tooling. Een voorbeeld van het goed toepassen van het strategisch plan is het playbook van Cisco.[http://www.scribd.com/doc/33518678/Cisco-Social-Media-Playbook-Best-Practice-Sharing.]

Strategisch plan

Cisco heeft social media intern en extern geprofileerd. Zij heeft een Social Media Playbook geïntroduceerd; zij geeft daarmee aan hoe zij social media benadert voor de Cisco-organisatie: luisteren online, verzamelen van feedback en het leren van de ervaringen. Ondertussen wordt het playbook gezien als één van de best practices rond sharing en social-media-gebruik en -inzet.

De internationale beroepsvereniging van internal auditors IIA[Het Instituut van Internal Auditors Nederland (IIA) is de grootste beroepsvereniging van internal auditors in Nederland. De missie van IIA is om het beroep en vak internal audit in Nederland te ontwikkelen en te promoten en daarvoor internal auditors, management en andere belanghebbenden te ondersteunen bij een succesvolle invulling van de internal-auditfunctie. De hoofdtaken van IIA bestaan uit het profileren van het vak, kwaliteitsbewaking, belangenbehartiging en het delen van kennis.] heeft een boek uitgebracht met vereisten waaraan een strategisch plan ter beheersing van social media dient te voldoen.[P.R. Scott en J.M. Jacka, Auditing-Social-Media-A-Governance-and-Risk-Guide.]

C-2012-4-Braaksma-t01

Tabel 1. Social media strategisch plan.

Het social media strategisch plan dient door relevante stakeholders opgesteld te worden; daarbij valt te denken aan: Marketing, IT, Juridische Zaken en Compliance. Nadat de strategie is opgesteld, dient de uitvoering plaats te vinden, inclusief monitoring en terugkoppeling van de bevindingen. Dit laatste dient uitgevoerd te worden door de gedelegeerde verantwoordelijke van social media. Aan de auditor de taak om deze gehele managementcyclus te auditen.

Risk & beheersing

Het risico van social media valt niet op voorhand uit te sluiten door organisaties. Als organisatie kun je niet zelf bepalen of je meedoet met social media of niet. Immers, dat wordt bepaald door de ‘internetwereld’. Met risico wordt in deze context bedoeld de potentiële gevaren van social media die de organisatie kunnen bedreigen in haar bedrijfsvoering. De potentiële gevaren kunnen door beheersingsmaatregelen zo goed mogelijk worden gemitigeerd. Daarbij wordt, voor zover mogelijk, de waarschijnlijkheid en impact van een risico tot het minimum beperkt. Zoals eerder besproken zijn social media een enorme kans voor de organisatie, maar heeft dit fenomeen twee kanten (double-edged sword).

In tabel 2 wordt per aandachtsgebied het risico voor de organisatie genoemd. Daarachter worden in een kolom de mogelijke beheersingsmaatregelen genoemd. Deze laatste beheersingsmaatregelen dient een organisatie in te voeren om in control te zijn. Aan een auditor de taak om de beheersingsmaatregelen te toetsen op inhoudelijkheid.

C-2012-4-Braaksma-t02a-klein

Tabel 2. Risico’s voor de organisatie per aandachtsgebied (deel 1). [Klik op de afbeelding voor een grotere afbeelding]

C-2012-4-Braaksma-t02b-klein

Tabel 2. Risico’s voor de organisatie per aandachtsgebied (deel 2). [Klik op de afbeelding voor een grotere afbeelding]

Conclusie

Worden social media gehanteerd als middel om financiële prestaties van de organisatie te verbeteren? Wordt er overwogen social media in te zetten, maar is er twijfel over het double-edged sword? Dan wordt aangeraden om eerst een strategisch plan op te stellen om op social media ‘in control’ te zijn en te blijven. Daarbij is een auditor van toegevoegde waarde en kunnen de risico’s en beheersingsmaatregelen in de huidige inrichting onder de loep worden genomen. Een auditor kan dat doen aan de hand van een normenkader dat specifiek van toepassing is op de situatie van de organisatie. De auditor kan het social-mediaproces ondersteunen en helpen beheersen. Aangeraden wordt dit minimaal eenmaal per jaar uit te voeren, zodat de organisatie niet net als Goldman Sachs op de voorpagina van Het Financieele Dagblad verschijnt …

Een sleutelrol voor Internal Audit in sustainability

Voor steeds meer bedrijven hangt het ondernemingssucces af van de mate waarin ze duurzaam opereren weten te verankeren in bedrijfsprocessen en de organisatiecultuur en de wijze waarop ze hierover extern communiceren. Dat vraagt om uitstekende externe voelhoorns die signalen oppikken en een vertaling maken naar de interne organisatie en de externe verslaggeving. Op dit snijvlak van maatschappelijke thema’s en governance, risk en compliance is een rol weggelegd voor Internal Audit.

Inleiding

In januari 2010 berichtte The New York Times over een filiaal van kledingconcern H&M dat onverkochte kledingcollecties verknipte in plaats van de restanten te leveren aan daklozenorganisaties. Binnen de kortste tijd zwol de publieke verontwaardiging hierover aan op Twitter en Facebook. Burgers keurden de actie en masse af – zeker ten tijde van de barre kou en de economische crisis. H&M liep flinke reputatieschade op, onder andere doordat het bedrijf dagenlang niet adequaat communiceerde op de social media platforms. In de nasleep van het incident werd door experts vooral gewezen op het belang van een adequate communicatiestrategie in dergelijke gevallen. Dat is natuurlijk volkomen terecht, maar de vraag dringt zich ook op of (en hoe) het incident te voorkomen was.

Het eenvoudige antwoord op die vraag is ja. Wat daarvoor nodig is, is dat alle medewerkers van bedrijven als H&M de waarden op het gebied van duurzaamheid – vaak opgenomen in gedragscodes – toepassen in hun dagelijkse werkzaamheden. Als duurzaam opereren de normaalste zaak van de wereld wordt, dan is het onwaarschijnlijk dat een dergelijk incident nog plaatsvindt. Duurzaamheid moet dus systematisch in processen worden verankerd en geïnternaliseerd in de cultuur.

Dat is echter wat kort door de bocht, want zo’n volledige integratie gaat nog vele jaren duren en is in elk geval voor de meerderheid van de ondernemingen nu nog niet aan de orde.

Zolang duurzaamheid nog niet voor iedereen een vanzelfsprekendheid is, is er aanvullende actie nodig om dergelijke problemen te voorkomen. Veel bedrijven realiseren zich dat ook terdege en investeren in het opzetten van een duurzaamheidsbeleid en het houden van stakeholderdialogen. Hiermee krijgen ze scherper zicht op (de onderstroom van) maatschappelijke ontwikkelingen en daarmee ook op de vraag welke issues er de komende tijd veel aandacht zullen krijgen. Door met stakeholders te communiceren over hun zorgen en aanbevelingen krijgen ze goed zicht op wat deze stakeholders specifiek verwachten van hun operaties en kunnen daarop beter inspelen. In veel gevallen is het duurzaamheidsjaarverslag een belangrijk middel in de communicatie met de diverse stakeholdergroepen.

Het nut van deze activiteiten hangt echter sterk af van de vraag of organisaties er ook daadwerkelijk in slagen de wensen van stakeholders te vertalen naar hun organisatie. Als het alleen bij een operatie voor de bühne blijft en niet leidt tot zelfreflectie is het resultaat nihil en kan het zich zelfs als een boemerang tegen de organisatie keren.

Verankering van sustainability

Voor veel bedrijven is het volstrekt duidelijk dat met duurzaamheidsaspecten in de bedrijfsvoering rekening gehouden dient te worden. Uit wereldwijd KPMG-onderzoek onder bijna vierhonderd senior executives blijkt dat nog maar vijf procent van de bedrijven van mening is dat een sustainabilitystrategie voor hun bedrijf niet noodzakelijk is ([KPMG11a]).

De wijze waarop bedrijven proberen duurzaamheidsaspecten te integreren in de bedrijfsvoering lijkt veelal langs de volgende lijnen te lopen. Een stafafdeling (vaak met een oorsprong in corporate communications, public affairs, of indien al aanwezig de milieuafdeling) onderzoekt wat duurzaamheid voor het bedrijf precies betekent, agendeert de relevante thema’s en probeert het belang voor en de rol van de verschillende businessfuncties (bijvoorbeeld operations, supply chain, HR) duidelijk te maken.

Dat belang wordt veelal op een hoger niveau ook herkend. Onder andere versterking van de ‘brand’, risk management, verankering in de IT-systemen en kostenreductie worden gezien als belangrijke ‘drivers’ om duurzaamheid in de bedrijfsvoering te integreren. Daarnaast wordt duurzaamheid in toenemende mate gezien als een bron van innovatie ([KPMG11]). Toch slagen bedrijven er nog niet altijd in de bedrijfsvoering dusdanig aan te passen dat alle kansen worden gegrepen en risico’s gemitigeerd, zoals ook het voorbeeld van H&M aantoont.

De sustainabilityfunctie blijkt nog niet altijd voldoende in staat de benodigde verankering in de organisatie tot stand te brengen. Weliswaar vervult zij intern veelal een sterke ambassadeursfunctie en zet ze ontwikkelingen in gang, maar het zit niet altijd in haar macht en aard om processen te veranderen, aspecten te integreren in de interne en externe verslaggeving of risicomanagement te implementeren. Men mist hiermee implementatiekracht en wordt door het management ook niet altijd in die hoek geplaatst.

Behoefte aan centrale afdeling: Internal Audit?

Organisaties hebben, naast de duurzaamheidsafdeling, dan ook behoefte aan een centrale afdeling of functie die zich nog meer richt op de kwaliteit van de ’embedding’ van duurzaamheid en die rapporteert over de mate waarin het in de genen van de organisatie en haar mensen zit. In het geval van H&M had zo’n functie kunnen vaststellen dat er in tijden van economische crisis waarschijnlijk veel maatschappelijke verontwaardiging is over verkwisting. Men had de werkwijze rondom restanten nog eens kritisch tegen het licht kunnen houden of kunnen communiceren over het belang van het voorkomen van verkwisting.

Wie zou die rol op zich kunnen nemen? Het ligt dan ook voor de hand dat Internal Audit hier een actieve rol vervult, als specialist op het gebied van interne beheersing en risicomanagement. Internal Audit heeft immers de vaktechnische en bedrijfskennis voor een objectieve beoordeling van risico’s en kan dat ook ontwikkelen op het vlak van duurzaamheid. Volgens de ‘officiële’ definitie van het Institute of Internal Auditors (IIA) heeft Internal Audit het thema risk management – dat direct op de geschetste uitdaging aansluit – ook in de portefeuille: ‘Internal auditing is an independent, objective assurance and consulting activity designed to add value and improve an organization’s operations. It helps an organization accomplish its objectives by bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk management, control, and governance processes.’ ([IIA])

Duurzaamheid is een kernthema voor veel bestuurders en in de vluchtige ‘120 tekens cultuur’ kan snel grote (reputatie)schade ontstaan als gevolg van incidenten. Ondernemingen zetten dan ook steeds meer in op de preventie van incidenten door assurance en advies van Internal Audit. De focus ligt hierbij op onderliggende processen, systemen en interne controle. De internal auditor kijkt met andere woorden naar het borgen van duurzaamheid in de processen van de organisatie. Ook het IIA meent overigens dat de internal auditor dit thema met verve moet oppakken. In het paper Governance in duurzaamheid is een aantal conclusies getrokken over de rol die Internal Audit op het gebied van Corporate Social Responsibility (CSR) kan spelen ([IIAN11]). Op deze plaats lichten we er drie uit:

Betrokkenheid van Internal Audit bij CSR neemt toe

De betrokkenheid van de Internal Audit bij CSR is de afgelopen jaren steeds verder toegenomen. In de toekomst neemt dit alleen maar verder toe doordat de maatschappelijke relevantie van CSR groter wordt en organisaties hun strategie hierop laten aansluiten. De internal auditor zal daardoor steeds meer prioriteit geven aan de werkzaamheden op het gebied van CSR. Het implementeren en beheersen van CSR binnen organisaties is in ontwikkeling. Audit van CSR ontwikkelt zich in lijn met de evolutie van CSR als auditobject.

Internal audit heeft ruime toegevoegde waarde bij CSR

Aangezien CSR zich sterk ontwikkelt, is de scope van de werkzaamheden van de internal auditor op het gebied van CSR ruim; naast de audits wordt vooral ook een adviesrol ingevuld. De internal auditor zal met zijn expertise belangrijke toegevoegde waarde leveren aan het proces van definiëren van beleid en criteria, normen stellen, beheersingsmaatregelen bepalen, uitkomsten meten, vastleggen en rapporteren. Alle ontwikkelingsfasen zoals de totstandkoming van de opzet, de implementatie in de organisatie en het versterken van de operationele effectiviteit lenen zich bij uitstek voor een goede bijdrage van de internal auditor.

Verdere integratie van CSR in de bedrijfsprocessen is noodzakelijk

De integratie van de CSR in de bedrijfsprocessen, de IT-systemen, de business controls frameworks en het risicomanagement moet verder groeien. De belangrijkste CSR-risico’s zijn reputatie- en compliancerisico’s. Internal Audit is, gezien de expertise van de bedrijfsprocessen en -risico’s, bij uitstek geschikt om de daaraan gerelateerde auditwerkzaamheden uit te voeren.

Deze drie conclusies laten aan duidelijkheid niets te wensen over. Duurzaamheid wint aan belang, en daarmee nemen gerelateerde risico’s op gebieden als reputatie en compliance toe. Een internal auditor kan zijn toegevoegde waarde ondubbelzinnig laten zien als hij in staat is om de externe signalen op dit gebied te vertalen naar de interne beheersing. Het management heeft in deze tijd tenslotte steeds meer behoefte aan een goed oordeel van Internal Audit over de effectiviteit van de beheersing en de afstemming van het raamwerk van beheersingsmaatregelen op de bedrijfsactiviteiten en externe ontwikkelingen.

Daarbij gaat het niet alleen om het beoordelen van structuren, (IT-)systemen, procedures en controles maar (vooral) ook om het beoordelen van de soft controls in een organisatie. Internal Audit heeft tot taak – afhankelijk van de invulling van het audit charter – om (aanvullende) zekerheid te geven over de kwaliteit van de corporate governance en internal control. Dat vereist ten aanzien van het thema duurzaamheid ook dat men erop toeziet dat de organisatiecultuur in overeenstemming is met de doelstellingen en de context van de duurzaamheidsstrategie. Auditors kunnen daartoe bijvoorbeeld periodiek de cultuur van de organisatie toetsen – een assessment van de soft controls – of bij veranderingstrajecten nagaan of adequaat wordt ingespeeld op de omgeving.

Belangrijke ontwikkelingen die de rol van de internal auditor verder vormgeven

De internal auditor heeft dus een kans om de missing link tussen het opvangen van externe signalen en interne beheersing in te vullen. Wat daarvoor nodig is, naast de gebruikelijke objectiviteit, is dat de internal auditor beschikt over de vereiste kennis en competenties. Er is kennis nodig van de relevante thema’s en – waarschijnlijk nog belangrijker – een proactieve houding. Duurzaamheid – en de verslaggeving erover – is voortdurend in ontwikkeling en dat geldt ook voor de verwachtingen van stakeholders en het belang van bepaalde issues. Alleen wie deze ontwikkelingen tot op het bot begrijpt kan ze vertalen naar de interne beheersing ervan. En daarmee op zijn minst bijdragen aan het voorkomen van incidenten zoals deze bij H&M optraden.

Ontwikkeling 1: Belang kwaliteit informatie in duurzaamheidsverslaggeving neemt toe

Zoals geschetst vergt een goede borging van sustainability in de organisatie dat signalen van stakeholders rond duurzaamheidsthema’s worden herkend en dat hierover de dialoog met de stakeholders wordt gevoerd. Daarmee halen bedrijven belangrijke informatie op om hun bedrijfsvoering te verbeteren, maar zijn zij ook in staat hun reputatie en imago te beïnvloeden.

Voor veel bedrijven speelt duurzaamheidsverslaggeving een centrale rol in de dialoog met de stakeholders. Hierbij wordt het begrip duurzaamheidsverslaggeving breder uitgelegd dan alleen het uitbrengen van een duurzaamheidsjaarverslag. Meer en meer kiezen bedrijven ervoor om met behulp van de mogelijkheden die het internet hen biedt de informatie uit het duurzaamheidsverslag toe te snijden op de wensen van de individuele stakeholdergroepen. De trend van het integreren van duurzaamheidsjaarverslagen en financiële jaarverslagen toont daarbij aan dat hierbij ook nadrukkelijk de stakeholders in de financiële wereld in beeld zijn.

Uit recent onderzoek van KPMG ([KPMG11]) blijkt dat 95 procent van de grootste bedrijven in de wereld (Global Fortune 250) rapporteert over duurzaamheid. Voor de honderd grootste bedrijven in 34 landen is dat aandeel inmiddels 69 procent. Voor deze bedrijven is de belangrijkste drijfveer voor sustainability reporting hun reputatie of ‘brand’.

Het moge duidelijk zijn dat het voor bedrijven dus van groot belang is dat de informatie in hun verslag een juiste weergave geeft van de werkelijkheid. Als dat niet het geval is zijn er twee risico’s te onderscheiden: onder- en overwaardering van de duurzaamheidsprestaties. Dit wordt geïllustreerd in figuur 1.

C-2012-1-Draaijer-01

Figuur 1. Balans tussen duurzaamheidsprestaties en -communicatie (bron: KPMG00]).

Indien een bedrijf de prestaties op duurzaamheidsgebied onvoldoende voor het voetlicht weet te brengen bij de belangrijkste stakeholders, loopt het het risico gezien te worden als een partij die haar maatschappelijke rol onvoldoende invult. Daarmee zou het bedrijf over zich kunnen afroepen dat het door een gebrek aan informatie door NGO’s in een negatief daglicht wordt gesteld. Een andere mogelijkheid is dat het bedrijf kansen in de markt laat liggen, doordat het in vergelijking met concurrenten er onvoldoende in slaagt om de maatschappelijke voordelen van zijn producten naar voren te brengen.

Het schetsen van een te rooskleurig beeld heeft andere nadelen. Hoewel in eerste instantie wellicht een ‘groen imago’ verworven kan worden, zullen door diverse stakeholders al snel de daadwerkelijke duurzaamheidsprestaties grondig worden geanalyseerd. Als blijkt dat het bedrijf zich hierbij te mooi heeft voorgedaan, zullen de daaropvolgende beschuldigingen van ‘green washing’ de reputatie geen goed doen. En zoals bekend ‘komt vertrouwen te voet, maar gaat het te paard’.

Al met al zal het bedrijven er dus veel aan gelegen zijn om hun prestaties in het duurzaamheidsverslag op een gebalanceerde wijze weer te geven. Uit het KPMG-onderzoek blijkt dat bedrijven dan ook serieus aandacht geven aan de kwaliteit van de informatie in het verslag. Zo neemt het aandeel van verslagen die extern geverifieerd zijn, over de jaren toe. Bijna de helft van de Global Fortune 250-bedrijven heeft informatie in het duurzaamheidsverslag extern laten verifiëren. Daarnaast laat het onderzoek zien dat een derde van de Global Fortune 250-bedrijven en een vijfde van de top 100 grootste bedrijven in 34 landen restatements van hun eerder gepubliceerde duurzaamheidsdata bevatten, wat wijst op een beweging van continue verbetering.

Ontwikkeling 2: Behoefte aan verdere diepgang externe assurance

Tevens geeft een toenemend aantal bedrijven hun externe-assuranceprovider opdracht om de assurance bij de duurzaamheidsinformatie met een grotere diepgang te verrichten. De meeste duurzaamheidsinformatie wordt tegenwoordig nog gecontroleerd met als doel het verkrijgen van een ‘beperkte mate van zekerheid’ (‘Review’). Een aantal koplopers vindt dat echter niet meer voldoende. Doordat de informatie die gecontroleerd wordt een steeds belangrijkere rol heeft in de bedrijfsvoering (de prestaties maken bijvoorbeeld deel uit van de C-level remuneratiecriteria) of direct een economische waarde vertegenwoordigt (denk aan CO2-emissies in emissiehandel) willen deze bedrijven een controle met een ‘redelijke mate van zekerheid’. Dit is het niveau van zekerheid dat ook voor de financiële jaarrekening wordt toegepast.

Het percentage restatements in de verslagen is wel vele malen hoger dan wat gebruikelijk is in financiële verslaggeving. En hoewel voor veel van de bedrijven de ‘restatements’ een resultante van kwaliteitsverbetering ten gevolge van externe-assuranceprocessen zijn, blijkt tevens dat voor bijna de helft van de bedrijven in het KPMG-onderzoek er geen zichtbare ‘board level’ verantwoordelijkheid voor of betrokkenheid bij de totstandkoming van het duurzaamheidsverslag was. Ook was er bij minder dan twintig procent van de onderzochte bedrijven sprake van het gebruik van een IT-systeem ter ondersteuning van de rapportage van de duurzaamheidsinformatie.

Het moge duidelijk zijn dat de internal auditor in het toetsen van de beheeromgeving en het tot stand komen van de duurzaamheidsverslaggeving een belangrijke rol moet spelen. Door middel van audits zal de internal auditor de beheersingsmaatregelen van de processen en systemen in kaart dienen te brengen en te toetsen aan de geldende normen. Net als voor de financiële rapportageprocessen zal voor de duurzaamheidsprocessen hierbij ook de nadruk komen te liggen op beheersing in de IT-systemen (application controls, autorisaties, functiescheiding, etc.). De internal auditor begrijpt als geen ander de beheersingsmaatregelen in de systemen of processen en moet hier dus op aangehaakt zijn.

Ontwikkeling 3: Integratie van financiële en duurzaamheidsverslaglegging

In het verlengde van de vorige ontwikkeling zullen de duurzaamheids- en financiële verslaglegging verder worden geïntegreerd. Naast het integreren van het rapportageproces (en alle beheersingsmaatregelen daarbinnen), zal dit ook gelden voor de structuren die gelden voor de financiële verslaglegging. Hierbij kun je denken aan het zogeheten ‘line of defense’-model voor het leveren van assurance.

In dit model heeft het management (first line) naast het opstellen van de sustainabilityrapportage ook een belangrijke taak bij het aantonen van de kwaliteit hiervan. Hierbij zal de werking van controls binnen de bedrijfs- en rapportageprocessen en systemen worden getest. De sustainabilityafdeling is hier niet altijd bekend mee, wat normaal gesproken wel geldt voor de financiële afdeling.

De externe auditor (third line) wil steunen op de bedrijfs- en rapportageprocessen en -systemen, zeker indien de organisatie overgaat naar een ‘redelijke mate van zekerheid’.

Het moge duidelijk zijn dat de internal auditor een rol moet nemen (second line) tussen het management en de externe auditor. Niet alleen om het financiële rapportagemodel te spiegelen (en hierdoor ook te integreren), maar ook omdat de internal auditor het management kan ondersteunen in het aantonen van de kwaliteit van deze processen.

Ontwikkeling 4: Sustainability reporting systems

Een aantal ontwikkelingen op het gebied van sustainability reporting maakt dat de rol van de internal auditor ook op dit gebied steeds belangrijker wordt. Zoals net aangegeven, zijn steeds meer bedrijven actief in het integreren van de informatie uit hun duurzaamheidsverslag in het reguliere jaarverslag. Daarbij is het vanzelfsprekend belangrijk dat de niet-financiële data net als de financiële data op efficiënte wijze worden verzameld en betrouwbaar zijn. Hiervoor gaan bedrijven op zoek naar IT-oplossingen die dit mogelijk maken. Veelal wordt er op dit moment nog gekozen voor separate, specifiek op duurzaamheidsinformatie gerichte systemen, maar de verwachting is dat met het verder integreren van duurzaamheidsaspecten in de bedrijfsvoering, ook de rapportageprocessen en -systemen verder worden geïntegreerd. In beide gevallen is er voor de internal auditor een rol weggelegd om de kwaliteit van het verzamelen, aggregeren en rapporteren van de sustainabilitygegevens te beoordelen.

In deze Compact zijn bovenstaande ontwikkelingen ook in andere artikelen verder uitgewerkt.

De rol(len) van de internal auditor op het gebied van sustainability

Dit alles bevestigt het eerder geschetste beeld van de noodzaak om sustainability verder in organisaties te borgen. Daarmee zal ook de kwaliteit van rapportage als vanzelfsprekend naar een volgend niveau worden gebracht. Zoals ook wordt geïllustreerd door figuur 2, kan de internal auditor in dit speelveld van borging en verantwoording een uitstekende rol vervullen. Enerzijds als verschaffer van assurance, al dan niet in samenspel met de externe-assuranceprovider. Anderzijds in een meer adviserende rol, waarbij vanzelfsprekend de onafhankelijkheid in acht dient te worden genomen. Internal Audit heeft tenslotte de vaktechnische en bedrijfskennis voor een objectieve beoordeling van risico’s en kan dat ook ontwikkelen op het vlak van duurzaamheid.

C-2012-1-Draaijer-02-klein

Figuur 2. Mogelijke rollen van de internal auditor (bron: IIAN11]).[Klik hier voor grotere afbeelding]

Naast de primaire assurance- of adviesrol van Internal Audit, kunnen internal auditors ook op specifieke thema’s hun toegevoegde waarde inbrengen. Een thematisch onderzoek is daarvan een goed voorbeeld. De invulling ervan is sterk afhankelijk van het karakter van de organisatie en de sector waarin men opereert. In het geval van een bank is het denkbaar dat internal auditors regelmatig bepaalde thema’s onderzoeken. Daarmee kunnen zij zichtbaar maken hoe maatschappelijke thema’s de bedrijfsvoering raken. Voorbeelden van thema’s zijn bijvoorbeeld klimaatverandering, palmolie, waterschaarste en de ‘blootstelling’ van de bank in bijvoorbeeld haar beleggingen of kredieten. In het geval van een retailer kunnen heel andere thema’s relevant zijn. Internal auditors zullen zich dan bijvoorbeeld richten op de effecten van schaarste van grondstoffen, mensenrechten of veiligheid op (de continuïteit van) de toeleveringsketen.

Concreet zien we voor de komende jaren een aantal taken op de internal auditor afkomen. Bij de zogenaamde frontrunners op het gebied van sustainability assurance zien we dat er een takenpakket voor de internal auditor gevormd wordt. Voor de komende jaren heeft de internal auditor een mooie uitdaging. Behoeften die veel genoemd worden zijn:

  • ‘challenging partner’ voor management met betrekking tot beheersing van sustainabilityonderwerpen;
  • review van integriteit van sustainability KPI’s voor interne sturing en externe rapportage;
  • monitoren van de juiste verankering van sustainability binnen de organisatie;
  • begeleiden van organisaties van limited naar reasonable assurance op sustainabilitygebied;
  • het testen van het ontwerp en de werking van beheersingsmaatregelen op het gebied van sustainabilityprocessen;
  • assurance / advies op de implementatie van een sustainability reporting system.

Conclusie

Voor bedrijven is er nog veel te winnen op het gebied van duurzaamheid. Daarvoor is het essentieel dat de organisatie is afgestemd op de kansen en risico’s die het thema biedt en dat de stakeholders in verslaggeving van informatie worden voorzien. Nu bij veel bedrijven de duurzaamheidskansen en -risico’s steeds beter bekend zijn, wordt het tijd de integratie in de bedrijfsvoering verder te organiseren. Daarbij moet de Internal Audit-functie een rol gaan vervullen. De combinatie van bedrijfskennis en ervaring met advies over en assurance bij controls en processen maakt dat de internal auditor uitstekend geëquipeerd is om bij te dragen aan het naar het volgende niveau brengen van de organisatie op het punt van duurzaamheid. Momenteel is sustainability nog niet een standaardaandachtspunt op de Internal Audit-agenda. Ontwikkelingen die genoemd zijn in dit artikel zullen daar op korte en langere termijn verandering in moeten gaan brengen.

Literatuur

[IIA] The Institute of Internal Auditors, http://www.theiia.org/guidance/standards-and-guidance/ippf/definition-of-internal-auditing/

[IIAN11] Instituut van Internal Auditors Nederland en Nederlandse Beroepsorganisatie van Accountants, Governance in duurzaamheid; Internal Audit en Corporate Social Responsibility, 2011.

[KPMG11a] KPMG International en Economist Intelligence Unit, Corporate Sustainability, a progress report, 2011.

[KPMG11b] KPMG International, KPMG International Survey of Corporate Responsibility Reporting 2011, November 2011.

Integrated Reporting

Niet-financiële informatie wint de afgelopen decennia aan belang. Steeds meer bestuurders zetten in op een duurzame strategie – vanuit het besef dat dit de beste manier is om op termijn de performance te optimaliseren – en willen dan ook dat de informatie op dit gebied minstens even goed is als de financiële informatie. Daar is echter nog een wereld te winnen, want de beheersing rondom niet-financiële informatiestromen staat nog in de kinderschoenen.

Introductie

In 1975 was 83 procent van de marktwaarde van ondernemingen nog te ‘verklaren’ vanuit de waarde van hun materiële vaste activa. In 2009 ligt dat percentage nog maar op negentien ([Ocea10]). Een beter bewijs dat er de afgelopen decennia echt wat is veranderd in de waardering van niet-financiële informatie is nauwelijks denkbaar. Het succes van ondernemingen – en daarmee ook hun waarde – wordt steeds afhankelijker van wat ook wel ‘zachte’ factoren worden genoemd: de manier waarop ze talent weten te organiseren, hun innovatiekracht, hun ethische standaarden, de manier waarop ze met mens en milieu omgaan, de wijze waarop ze zorgen voor ‘aarding’ in hun omgeving en andere factoren.

Deze belangrijke ontwikkeling maakt ook dat er andere eisen worden gesteld aan de manier waarop ondernemingen verantwoording afleggen over hun activiteiten. De realiteit is echter dat de externe verantwoording nog maar beperkt informatie geeft over de ‘nieuwe’ succesfactoren. Veel ondernemingen realiseren zich dat ook. Een klein deel van de ondernemingen is goed in staat om de eigen niet-financiële performance te monitoren.

Opkomst van Corporate Social Responsibility

Dat neemt niet weg dat er al veel gebeurt op het gebied van niet-financiële informatie in de externe verantwoording. Ondernemingen informeren de omgeving vooral steeds meer over de impact die hun activiteiten hebben op de maatschappij en over hoe zij werken aan een duurzame toekomst. De verslaggeving hierover – Corporate Social Responsibility (CSR) reporting – is de afgelopen decennia flink tot bloei gekomen en we staan nu voor de volgende stap: het combineren van CSR met de financiële rapportage. Deze integratie is een belangrijke stap in het volwassen worden van CSR en sluit aan op de ontwikkelingen in het denken over duurzaamheid: duurzaam opereren wordt terecht niet langer gezien als een ‘extraatje’, maar iets wat thuishoort in het hart van elke succesvolle langetermijnstrategie. De tijd dat duurzaamheid alleen gerelateerd werd aan mogelijke reputatieschade ligt inmiddels achter ons. Voor veel bedrijven is het een middel om meerwaarde te creëren voor aandeelhouders, werknemers en andere stakeholders. Helaas hebben we de afgelopen jaren ook gevallen gezien waarin het omgekeerde aan de orde is. Energieconcern BP zag de waarde van het bedrijf bijvoorbeeld imploderen na de explosie op de Deepwater Horizon en de daarmee gepaard gaande olievervuiling.

Integrated Reporting

De stap van de combinatie van CSR- en financiële informatie in verslaggeving is de eerste stap op weg naar het uiteindelijke doel van ‘Integrated Reporting’. Dat Integrated Reporting meer is dan het in elkaar schuiven van het CSR-rapport en het financiële jaarverslag, daar is iedereen het wel over eens. De uitdaging is veel meer het vinden van een nieuw concept waarin duidelijk wordt dat financiële prestaties en duurzaamheid onmogelijk los van elkaar kunnen worden gezien. Integrated Reporting gaat dan ook vooral om het verbinden van beleid op verschillende terreinen. Ook het International Integrated Reporting Committee (IIRC) heeft die visie ([IIRC11]): ‘Integrated Reporting combines the most material elements of information currently reported in separate reporting strands (financial, management commentary, governance and remuneration, and sustainability) in a coherent whole, and importantly:

  • shows the connectivity between them; and
  • explains how they affect the ability of an organization to create and sustain value in the short, medium and long term.’

Aan ambities ontbreekt het niet op dit gebied. Uit onderzoek van KPMG onder driehonderd Nederlandse ondernemingen blijkt dat bijna zestig procent van de onderzochte ondernemingen de komende jaren geïntegreerd over duurzaamheid gaat rapporteren. Eén op de vijf ondernemingen rapporteert op dit moment al geïntegreerd over duurzaamheid. De aandacht voor duurzaamheid binnen de bedrijven ontwikkelt zich in lijn hiermee, maar is in veel gevallen nog wel pril. Bijna dertig procent van de ondernemingen is op dit moment op geen enkele wijze met duurzaamheid bezig en ruim twintig procent ontwikkelt op dit moment beleid op het gebied van duurzaamheid. Van de andere helft van de bedrijven is bijna twintig procent bezig met de invoering van het ontwikkelde beleid. Slechts bijna dertig procent van de ondernemingen stuurt op dit moment op een aantal indicatoren of thema’s.

C-2012-1-Bartels-01

Figuur 1. Status duurzaamheid in Nederland (bron: KPMG).

Denkmodel

Hoe dan ook, de ontwikkeling om het financiële jaarverslag en het duurzaamheidsverslag samen te voegen is duidelijk ingezet. Omdat dit niet meer dan een eerste stap is op weg naar daadwerkelijke integratie, kent het concept van geïntegreerde verslaggeving nu nog geen eenduidige aanpak, modellen en definities. De voorstellen van het IIRC geven wel een goede denkrichting, door een waardenmodel te introduceren dat verder gaat dan alleen financiële waarden. Dit model dient centraal te staan bij het verschaffen van informatie door ondernemingen.

C-2012-1-Bartels-02

Figuur 2. Waardenmodel Integrated Reporting.

Principes van Integrated Reporting

De IIRC heeft de volgende principles opgenomen in haar eerste Discussion Paper, getiteld Towards Integrated Reporting ([IIRC11]):

Strategic focus

An Integrated Report provides insight into the organization’s strategic objectives, and how those objectives relate to its ability to create and sustain value over time, and the resources and relationships on which the organization depends.

Future orientation

An Integrated Report includes management’s expectations about the future, and other information to help report users understand and assess the organization’s prospects and the uncertainties it faces.

Connectivity of information

An Integrated Report shows the connections between the different components of the organization’s business model, external factors that affect the organization, and the various resources and relationships on which the organization depends.

Responsive and stakeholder inclusive

An Integrated Report provides insight into the organization’s relationships with its key stakeholders, how the organization anticipates their needs, and how and to what extent the organization understands, takes into account, and responds to different stakeholders.

Concise, reliable and material

An Integrated Report provides concise, reliable information that is material to assessing the organization’s ability to create and sustain value in the short, medium and longer term.

Interne beheersing van de informatievoorziening

Integrated Reporting levert niet alleen een uitdaging op voor de communicatie met de omgeving, maar nadrukkelijk ook ten aanzien van de interne informatieprocessen rondom de niet-financiële informatie. Het startpunt daartoe is een goede analyse van de mate waarin deze informatie (waaronder informatie over duurzaamheid) daadwerkelijk is geïntegreerd in de organisatie. Dat legt de basis voor geloofwaardige, betrouwbare en solide verslaggeving.

Betrouwbare niet-financiële informatie is van even groot belang als betrouwbare financiële informatie voor een goede beheersing en besturing. Op dit moment wordt deze relatief nieuwe informatiecategorie veelal (al dan niet handmatig en versnipperd) vastgelegd in separate toepassingen of spreadsheets. Het gevolg hiervan is dat deze informatie vaak minder snel beschikbaar is dan financiële informatie en een hoge foutgevoeligheid kent. Uit onderzoek van KPMG blijkt dat een derde van de 250 grootste ondernemingen ter wereld en meer dan een vijfde van de 100 grootste bedrijven in 34 landen jaarlijks correcties (moeten) maken op hun gerapporteerde duurzaamheidsinformatie ([KPMG11]).

Organisaties staan dan ook voor de uitdaging de beheersing rondom niet-financiële informatie naar het niveau te brengen zoals dat ook voor financiële informatie wordt gehanteerd. Het in figuur 3 weergegeven model biedt daartoe de samenhangende bouwblokken en koppelt de waardebepalende factoren aan de missie en strategie van de onderneming.

C-2012-1-Bartels-03-klein

Figuur 3. KPMG holistic Governance Risk and Controls model.[Klik hier voor grotere afbeelding]

Waardebepalende factoren koppelen aan missie en strategie

De koppeling tussen niet-financiële, ‘zachte’ factoren en de waarde van de onderneming is een essentiële eerste stap. Hoewel veel leidinggevenden ‘by heart’ de tien belangrijkste factoren zullen weten, blijkt het in praktijk lastig het verband te leggen tussen de waarde van de onderneming en de factoren die die waarde bepalen (de ‘value drivers’). Het formuleren van daadwerkelijk meetbare indicatoren en/of doelstellingen is nog lastiger. Dit heeft naar onze ervaring vooral met onwennigheid te maken. Ondernemingen zijn de afgelopen decennia alleen maar meer getraind in het rapporteren en sturen op financiële parameters.

Verantwoordelijkheden borgen in gehele governance

Duurzaamheidsinformatie wordt in veel gevallen langs aparte lijnen en ad hoc (één keer per jaar) verzameld voor het externe verslag. Er wordt niet of nauwelijks op gestuurd en de informatie is niet ‘onderworpen’ aan de governance die wel van toepassing is op financiële informatie. Dit verdient verbetering door aanpassing van:

  • de structuur van management en toezicht, inclusief de daarmee samenhangende verantwoordelijkheden ten aanzien van de kwaliteit van niet-financiële informatie;
  • de interne-governancestructuur met rollen, verantwoordelijkheden en procedures. Dit betreft de volledige lijn, van operationeel management tot en met Raad van Commissarissen.

Risicomanagement en monitoring

De waarde van een onderneming heeft een duidelijke relatie met niet-financiële informatie en het is dan ook niet meer dan logisch dat juist de niet-financiële informatie – op basis van de value drivers zoals die in een eerder stadium zijn bepaald – onderdeel gaat uitmaken van Enterprise Risk Management. Het gaat immers om factoren die de strategie, doelstellingen en continuïteit van de onderneming kunnen bedreigen of verstevigen. Risicomanagement moet zich richten op de risicobepalende ontwikkelingen, ’emerging risks’, de relatie tussen risico’s en organisatieonderdelen of -processen, verantwoordelijkheden en scenarioanalyse. Energiebedrijf Shell brengt bijvoorbeeld al jaren langetermijnscenario’s voor energiezekerheid in kaart en past daarop de strategie aan.

Monitoring richt zich voornamelijk op het zeker stellen dat de controls die zijn opgezet rondom niet-financiële informatie (zie hieronder) daadwerkelijk functioneren. Ook richt deze activiteit zich op het tijdig signaleren, opvolgen en bijsturen. Interne en eventueel externe assurance maken onderdeel uit van dit monitoringsysteem.

Integratie in de IT-omgeving

De IT-omgeving voor niet-financiële informatie staat bij veel organisaties nog in de kinderschoenen, zeker in vergelijking met het niveau dat er bestaat voor financiële informatievoorziening. Organisaties moeten dan ook nog forse stappen zetten. De verwachting is dat duurzaamheid en niet-financiële informatieprocessen uiteindelijk volledig geïntegreerd worden in de IT- en ERP-systemen binnen de organisaties. Momenteel ligt dat nog niet voor de hand als gevolg van de volgende factoren:

  • Gegevens over HR, Health & Safety en supply chain management zijn belangrijke bouwstenen van duurzaamheidsinformatie maar deze processen zijn vaak niet volledig geïntegreerd in het ERP-systeem.
  • De afdeling Duurzaamheid is vaak nog een ‘koninkrijk’ binnen de organisatie, waardoor de integratie op het gebied van processen, organisatie en IT-systemen beperkt is. Vaak wordt dan ook nog gekozen voor een specifieke applicatie voor duurzaamheidsverslaglegging en staat men minder open voor een geïntegreerde IT-oplossing.

Het artikel ‘Sustainability Reporting Systems’ gaat nader in op dit thema en geeft handvatten voor de verbetering van de rapportageprocessen voor niet-financiële informatie.

Borging in businessprocessen

Organisaties die willen sturen op niet-financiële informatie moeten kunnen rekenen op de continuïteit en betrouwbaarheid van deze informatie. Dit vraagt om een frequente verzameling – in lijn met het ritme van de besluitvormingsprocessen – en een effectieve beheersing. Het gaat onder andere om heldere regels en procedures die beschrijven welke informatie wordt verzameld en langs welke definitie, maar ook om de wijze waarop informatieverzameling en -verwerking verloopt. Last but not least is het ook zaak om de interne verantwoordelijkheden en controles goed op orde te hebben. Een volledige integratie van de noodzakelijke maatregelen (invoercontroles, bevoegdheden, aansluitingen en dergelijke) in de bedrijfsprocessen is daarbij het meest effectief en efficiënt.

Cultuur en gedragsbeïnvloeding

Een gewijzigde (of aanvullende) focus op niet-financiële informatie vraagt ook dat management en medewerkers doordrongen zijn van het belang van ogenschijnlijk niet-resultaatgerichte niet-financiële informatie. Dit betekent bijvoorbeeld dat het voltallige personeel zich bewust is van het belang van ‘details’ als het naleven van specifieke veiligheidsinstructies als het bijvoorbeeld gaat om een organisatie in de zware industrie. Men moet zich realiseren wat de invloed van niet-naleven kan zijn op de reputatie, de operatie en de waarde van de onderneming. Bewustwordingsprogramma’s op de relevante niet-financiële thema’s kunnen ervoor zorgen dat dit beklijft – uit onze ervaring is bekend dat dit vooral herhaling en vasthoudendheid vraagt.

Conclusie

Niet-financiële informatie wordt belangrijker en dat vraagt om kwalitatief hoogstaande borging. Die borging dient net zo sterk te zijn als rondom financiële informatie. Het model van governance & control dat wordt gebruikt voor financiële informatie kan ook worden toegepast op duurzaamheids- en andere niet-financiële informatie. Organisaties staan aan het begin van de ontwikkeling in die richting, vooral als het gaat om samenhangende inrichting in lijn met de risico’s en de visie van de onderneming. Er is nog een wereld te winnen.

Literatuur

[IIRC11] International Integrated Reporting Committee, Towards integrated reporting, IIRC Discussion Paper, 2011.

[KPMG10] KPMG, onderzoek naar integrated reporting, juni 2010.

[KPMG11] KPMG International, KPMG International CR Reporting Survey, 2011.

[Ocea10] Ocean Tomo, Ocean Tomo’s Annual Study of Intangible Asset Market Value, 2010.

Access Governance: een einde aan de worsteling rondom autorisatiemanagement?

Access Governance is een aanpak waarbij op een geautomatiseerde wijze autorisaties van een heterogeen applicatielandschap worden geanalyseerd met als doel de risico’s van ongeautoriseerde toegang te verminderen. Access Governance wordt ingezet als internecontrolemaatregel, maar kan ook onderdeel uitmaken van de interne of externe audit, waarbij de externe accountant steunt op de uitkomst van het Access Governance-proces en hiermee waarborgen krijgt omtrent de juistheid van de toegang tot de financiële systemen en onderliggende infrastructuur. Naast voornoemde aspecten wordt in dit artikel uitgelegd hoe Access Governance as a Service kan worden ingezet, wat inhoudt dat een organisatie de periodieke autorisatieanalyse uitbesteedt aan een externe partij. Dit model is ook toepasbaar in relatie tot de betrokkenheid van IT-audit bij de jaarrekeningcontrole. Daarnaast wordt de relatie tussen Access Governance en Identity & Access Management (IAM) gegeven.

Inleiding

Het afgelopen decennium is er bij veel organisaties aandacht geweest voor logisch toegangsbeheer. Deze organisaties zijn vaak gestart met een verbeterproject. Ondanks de toenemende aandacht voor toegangsbeheer worstelen nog steeds veel organisaties met dit onderwerp. Toegangsbeheer is veelal een aandachtspunt in de management letter (brief met bevindingen en aanbevelingen naar aanleiding van de jaarrekeningcontrole) van de externe accountant. Hierbij kan men zich afvragen waarom toegangsbeheer een terugkomend aandachtspunt is. Is het onderwerp niet relevant genoeg omdat er bijvoorbeeld voldoende compenserende maatregelen zijn ingericht en additioneel getoetst zijn waardoor bevindingen niet tot echte issues leiden? Of wordt de oplossing van het probleem als te complex ervaren? Beide spelen in ieder geval een rol. Het steunen op mogelijke compenserende maatregelen is echter risicovol. Een organisatie weet vooraf niet of deze maatregelen achteraf voldoende zijn. Daarnaast loopt de organisatie nog steeds risico’s dat (oud-)medewerkers (intern/extern) misbruik maken van een teveel aan autorisaties.

De perceptie dat het structureel verbeteren van logisch toegangsbeheer complex is en gepaard gaat met dure IAM-projecten en ondersteunende software is te begrijpen. IAM-projecten richtten zich vaak voor een groot gedeelte op automatisering van toegangsprocessen, waarbij de kwaliteit van autorisaties niet direct de benodigde prioriteit kreeg en het echte probleem dus niet voldoende werd opgelost. Wanneer er werd gekozen voor de implementatie van rolgebaseerde toegang (Role Based Access Control – RBAC), betekende dit vaak langdurige trajecten om tot een rollenmodel te komen dat passend was voor de gehele organisatie en in veel gevallen werden de doelstellingen niet gerealiseerd. Nu beoogt dit artikel niet om u als lezer volledig af te laten stappen van IAM en RBAC. IAM gecombineerd met RBAC is namelijk nog steeds een adequate methode om logisch toegangsbeheer verregaand te professionaliseren en te automatiseren. De doelstelling van het artikel is wel om u kennis te laten maken met een meer detectieve aanpak (Access Governance). Dit is een aanpak waarbij autorisaties periodiek worden beoordeeld tegen vastgestelde regels, zoals functiescheiding en autorisatiematrices. Vervolgens kan een organisatie op basis van de ambities/noodzaak besluiten om door te groeien naar een preventieve aanpak op basis van IAM en RBAC. De afwegingen tussen deze scenario’s worden verderop in het artikel toegelicht. Een toelichting op IAM is opgenomen in onderstaand kader.

IAM uitgelegd

IAM is een samenspel van beleid, processen en systemen om efficiënt en effectief het proces te beheersen waarin de toegang met betrekking tot applicaties wordt beheerd. In figuur 1 zijn de verschillende IAM-componenten schematisch weergegeven.

C-2011-2-Hart-01

Figuur 1. Het IAM-referentiemodel.

Het referentiemodel is opgebouwd uit de volgende IAM-processen:

  • Gebruikers- en autorisatiebeheer. Dit domein richt zich op de activiteiten gerelateerd aan het beheren van identiteiten (en daaraan gerelateerd de gebruikersaccounts) binnen de gebruikersadministratie. Het heeft betrekking op de gehele levenscyclus (initiële vastlegging, wijziging en verwijdering) van eindgebruikeraccounts. Daarnaast richt het gebruikersbeheer zich op het koppelen van organisatierollen (en specifieke autorisaties) aan geregistreerde identiteiten. Enerzijds geschiedt deze koppeling door het (automatisch) koppelen van afleidbare rollen op basis van attributen binnen de bronregistratie (bijvoorbeeld SAP HCM), anderzijds door het inrichten van een workflow/gebruikersinterface voor toekenning van rollen die niet afleidbaar zijn vanuit de bronregistratie (zoals taakgebaseerde of tijdelijke rollen).
  • Rollenbeheer. Dit domein richt zich op de activiteiten ten aanzien van het definiëren en beheren van organisatierollen, onder andere afgeleid van de administratie van de organisatie en via data-analyses. Via deze organisatierollen verkrijgt men toegang tot en binnen de applicaties. Omdat niet alle autorisaties via rollen zullen worden toegekend, worden binnen het rollenbeheer ook ‘losse’ autorisaties opgenomen in het autorisatiemodel. Dit betreft bijvoorbeeld applicatierollen.
  • Provisioning. Dit domein betreft het aanmaken dan wel verwijderen van accounts, en het toekennen dan wel afnemen van autorisaties voor deze accounts in de systemen. Provisioning kan zowel volledig geautomatiseerd als handmatig (met tussenkomst van een functioneel beheerder) plaatsvinden.
  • Monitoring en auditing. Dit domein richt zich op het controleren van de naleving van het van toepassing zijnde beleid en het vergelijken van de geïmplementeerde toegangsrechten (‘ist’) met de gewenste en/of geadministreerde toegangsrechten in het rollenmodel (‘soll’).

Access Governance uitgelegd

Access Governance is een efficiënt proces om de toegang met betrekking tot applicaties/systemen op een frequente basis te reviewen. Bij dit proces wordt gebruikgemaakt van analysesoftware. Verderop in dit artikel wordt de relatie tussen IAM en Access Governance verder uitgewerkt. Samenvattend kan worden gesteld dat Access Governance een detectief proces is om autorisaties te valideren en op te schonen. Hiermee is het een opmaat naar de implementatie van preventieve controles met IAM, zoals de implementatie van Role Based Access Control.

In figuur 2 is het Access Governance-proces schematisch weergegeven.

C-2011-2-Hart-02

Figuur 2. Autorisatieverificatieproces.

Het autorisatieverificatieproces beslaat grofweg drie fasen.

Fase 1. Data verzamelen en definiëren testregels

In de eerste fase wordt allereerst bepaald welke systemen/applicaties moeten worden bekeken. Vervolgens worden per applicatie de autorisatiedata geëxporteerd naar bijvoorbeeld een ‘comma separated file’, een zogenaamd plat tekstbestand. De export van de autorisatiedata kan uit verschillende bestanden bestaan, aangezien diverse informatie benodigd is, onder andere de koppeling van de autorisaties aan de accounts; het totaaloverzicht van beschikbare autorisaties.

De tweede stap is het verkrijgen van de persoonsgegevens uit de HR-administratie. Eén van de basale controles is namelijk het nagaan of ieder account te herleiden is tot een natuurlijke persoon uit die HR-administratie. Om te voorkomen dat te veel accounts niet gekoppeld kunnen worden, is het noodzakelijk dat de externe medewerkers ook in een bronregistratie zijn opgenomen. Dit mag een tweede, aparte registratie zijn. Uit deze controle komen altijd accounts naar voren die niet te koppelen zijn aan een persoon. Dit betreft namelijk de systeemaccounts die vaak benodigd zijn voor bepaalde functies in een applicatie. Overigens zouden deze systeemaccounts wel te verklaren moeten zijn en zou aan ieder systeemaccount een eigenaar moeten zijn toegekend die het account beheert, maar in de praktijk blijkt dit echter niet altijd het geval te zijn.

Om de autorisatieanalyse goed te kunnen verrichten, moeten zogenaamde bedrijfsregels worden opgesteld. Deze kunnen onderscheiden worden in generieke bedrijfsregels en applicatiespecifieke bedrijfsregels. De generieke regels zijn op iedere applicatie van toepassing. Hierbij kan worden gedacht aan:

  • Ieder persoonlijk account moet te herleiden zijn tot een natuurlijk persoon uit een bronregistratie, zodat activiteiten in de applicaties zijn te herleiden tot personen.
  • Er mogen geen test-accounts in de productieomgeving actief zijn, zodat test-accounts niet misbruikt kunnen worden voor daadwerkelijke transacties.
  • Er mag geen account met alle autorisaties zijn om te voorkomen dat hiermee functiescheiding wordt doorbroken.

De applicatiespecifieke regels worden opgesteld per applicatie. Deze regels zijn gebaseerd op eventuele reeds aanwezige autorisatiematrices of specifieke functiescheidingsregels. De eigenaar van de applicatie (applicatie- c.q. proceseigenaar) is verantwoordelijk voor de toegekende autorisaties in de applicatie. De applicatiespecifieke regels worden daarom afgestemd met de proceseigenaar. Bij dit afstemmingsproces is vaak ook functioneel beheer betrokken, maar uiteindelijk worden de regels goedgekeurd door de proceseigenaar. De applicatiespecifieke regels kunnen ook testen of functiescheiding over applicaties heen wordt nageleefd. Daarnaast kunnen ook specifieke regels voor IT-componenten (bijvoorbeeld de database en het besturingssysteem) worden gedefinieerd, zodat autorisaties uit het gehele applicatiedomein worden getest. De applicatiespecifieke regels richten zich voornamelijk op de non-SAP-omgeving, aangezien voor SAP al specifieke analysesoftware met voorgedefinieerde regels aanwezig is.

Fase 2. Uitvoeren analyse

De in de vorige fase gedefinieerde bedrijfsregels worden ingevoerd in de analysesoftware. Gecombineerd met de autorisatie- en HR-data die in de voorgaande fase zijn vergaard, wordt nu de geautomatiseerde analyse uitgevoerd. Op basis van de regels worden overzichten gegenereerd van zaken die afwijken van de ingevoerde bedrijfsregels.

Voordat de overzichten met afwijkingen in de rapportages worden verwerkt, worden de ruwe overzichten afgestemd met een functioneel beheerder. Op basis van deze afstemming worden de resultaten verder verfijnd. Hiermee wordt zoveel mogelijk voorkomen dat in de rapportage afwijkingen zijn opgenomen die ten onrechte als afwijking zijn geclassificeerd, bijvoorbeeld doordat een regel niet correct is gedefinieerd.

Fase 3. Rapportage en follow-up

In deze fase worden afwijkingsoverzichten verwerkt tot rapportages. In deze rapportages kan ook een vergelijking worden gemaakt met het aantal afwijkingen per regel ten opzichte van de voorgaande controle. Op basis van een dergelijk overzicht wordt eenvoudig inzicht verkregen in de voortgang van de follow-up, namelijk of de eerder geconstateerde afwijkingen zijn opgelost.

C-2011-2-Hart-03

Figuur 3. Voorbeeld van afwijkingsdashboard.

De terugkoppeling van de resultaten vindt plaats met de proceseigenaar. Deze persoon bepaalt of een afwijkende autorisatie verwijderd moet worden of dat een specifieke situatie als uitzondering wordt geaccepteerd. Dit dient dan uiteraard wel te worden vastgelegd. In de rapportage kan ook een risicoclassificatie worden opgenomen, zodat direct duidelijk is of en zo ja, hoeveel afwijkingen als hoog risico worden geclassificeerd. Voor deze afwijkingen kan worden besloten om na te gaan of het teveel aan autorisaties daadwerkelijk is misbruikt en of er compenserende maatregelen van toepassing zijn die het risico van ongeautoriseerde transacties verminderen. Dit is met name van belang indien in het kader van de financiële audit wordt gesteund op de periodieke autorisatieverificatie (het Access Governance-proces).

Op grond van de aard van de afwijkingen kunnen ook suggesties worden gedaan om het autorisatiemanagementproces te verbeteren om afwijkingen in de toekomst te voorkomen.

De belangrijkste kenmerken van Access Governance:

  • Analyse van een heterogeen applicatielandschap
  • Off-line analyse → geen online connectie met te analyseren applicatie nodig
  • Aanpak met focus, organisatie kan zich alleen richten op kritieke applicaties en gegevens
  • Schaalbaar van 1 – n applicaties
  • Praktische aanpak met direct resultaat
  • Aanpak is leverancieronafhankelijk en diverse softwarepakketten zijn beschikbaar voor analyse

Mogelijke verbeteringen bij vervolgiteraties

Access Governance heeft de meeste toegevoegde waarde als het verificatieproces periodiek wordt herhaald, bijvoorbeeld ieder kwartaal. In dat geval worden afwijkingen relatief snel opgemerkt en wordt het risico op misbruik kleiner. De eerste iteratie is normaliter de meest intensieve iteratie omdat dan het gehele proces moet worden opgezet en de bedrijfsregels moeten worden geïnventariseerd. De vervolgiteraties bieden daarom vaak ruimte voor verbetering van het verificatieproces door:

  • applicatiespecifieke regels met meer diepgang te definiëren;
  • een risicoclassificatie aan de bedrijfsregels toe te kennen.

Voordelen voor de (financial) auditfunctie

Traditioneel is het testen van de effectiviteit van logische toegangsbeheermaatregelen arbeidsintensief en vergt dit veel handmatig werk. Hierdoor is het testen van de toegangsbeheermaatregelen vaak meer een ad-hocproces waar de (financial) auditor slechts beperkt op kan steunen. In tabel 1 zijn de belangrijkste voordelen weergegeven.

C-2011-2-Hart-t01

Tabel 1. De voordelen van Access Governance.

Naast de bovengenoemde voordelen kan Access Governance ook als auditinstrument worden ingezet bij de verkoop of opsplitsing van bedrijfsonderdelen. Access Governance maakt namelijk inzichtelijk wie waartoe toegang heeft en op basis van de rapportages en autorisatieoverzichten kan worden bepaald welke rechten moeten worden ingetrokken van personeel dat na de splitsing of verkoop niet meer werkzaam is bij de organisatie.

Inrichten van Access Governance

Om te voorkomen dat autorisaties na één controleslag worden geschoond en er daarna weer vervuiling ontstaat die niet tijdig wordt opgemerkt, is het van belang om een periodiek controleproces in te richten. Op deze manier implementeert de organisatie een detectieve controlemaatregel op een structurele wijze.

Een organisatie kan ervoor kiezen om het controleproces intern te implementeren. In de praktijk blijkt dat de verantwoordelijkheid voor het faciliteren van dit process vaak bij een afdeling Risk Management of Security Management terechtkomt. De proceseigenaren zelf zijn verantwoordelijk voor de uitvoering van het proces en het laten doorvoeren van de benodigde autorisatiewijzigingen. Risk Management of Security Management heeft dan een bewakende rol om ervoor te zorgen dat het controleproces juist en tijdig wordt doorgevoerd en dat de proceseigenaar zich met name bezighoudt met de vaststelling van de bedrijfsregels en de follow-up van de rapportages (oplossen van de geconstateerde afwijkingen). De daadwerkelijke uitvoering kan afhankelijk van de capaciteit worden belegd bij de IT-organisatie of bij Risk dan wel Security Management. Voor het intern uitvoeren van het controleproces moet ook analysesoftware worden aangeschaft door de organisatie.

Een ontwikkeling die steeds meer in opkomst is, is het uitbesteden van de daadwerkelijke uitvoering van het controleproces: Access Governance as a Service. In dat geval blijft de organisatie wel verantwoordelijk voor de uitvoering van het controleproces en het feit of afwijkingen worden opgevolgd. De uitvoering van het gehele controleproces, inclusief het verkrijgen van data en het inventariseren van bedrijfsregels, wordt uitbesteed aan een externe partij. Groot voordeel van Access Governance as a Service is dat de organisatie zelf geen kennis hoeft op te bouwen in het controleproces en geen kennis hoeft te hebben van de analysesoftware. Tevens hoeft de organisatie niet zelf analysesoftware aan te schaffen en te beheren. Een derde punt is dat door de uitbesteding de organisatie er zeker van is dat het controleproces wordt uitgevoerd. Bij controleprocessen die intern worden uitgevoerd is het risico groter dat vanwege drukke werkzaamheden bepaalde controles niet of niet tijdig worden verricht.

Met name het aantal applicaties dat geanalyseerd dient te worden en hoe vaak, is bepalend voor de vraag of het verstandig is om het controleproces intern te beleggen of extern als Access Governance as a Service. Hoe meer analyses er moeten worden uitgevoerd, hoe hoger de investering voor uitbesteden wordt. Het is daarom raadzaam om bijvoorbeeld eerst een beperkt aantal applicaties te laten analyseren en op basis van de ervaringen de Access Governance-strategie te bepalen, waarin onder andere de volgende aspecten aan bod komen:

  • scope van de analyse (welke applicaties/systemen);
  • frequentie van de analyse;
  • belegging van de taken en verantwoordelijkheden voor de verschillende onderdelen uit het proces;
  • groeimodel richting preventieve maatregelen (IAM-implementatie).

Relatie Access Governance & Identity en Access Management

Zoals in het kader in het begin van dit artikel uitgelegd, is IAM een samenspel van beleid, processen en systemen om efficiënt en effectief het proces te beheersen waarin de toegang met betrekking tot applicaties wordt beheerd. Een brede IAM-implementatie behelst hierbij meerdere processen. Access Governance is voornamelijk een rapportageproces waarbij wordt beoogd op basis van afwijkingsrapportages de bestaande situatie van de geïmplementeerde autorisaties te wijzigen en in lijn te brengen met de geldende bedrijfsregels. Een groot voordeel van Access Governance ten opzichte van IAM is dat geen tijdrovende implementatie van een RBAC-model noodzakelijk is. Dit is met name voor organisaties waarbij de bedrijfsprocessen niet of in een beperkte mate zijn gestandaardiseerd een grote uitdaging.

In figuur 4 is Access Governance gepositioneerd ten opzichte van IAM.

C-2011-2-Hart-04

Figuur 4. Access Governance gepositioneerd ten opzichte van Identity & Access Management.

Vanuit Access Governance kan de organisatie stapsgewijs doorgroeien richting een IAM-implementatie waarbij meer preventieve maatregelen worden geïmplementeerd en steeds meer wordt opgeschoven richting continuous auditing omdat een IAM-voorziening continu inzicht kan geven in de juistheid van de geïmplementeerde autorisaties. Afwegingen om te bepalen of de stap van Access Governance richting een brede IAM-voorziening voldoende toegevoegde waarde biedt, zijn:

  • Is meer zekerheid nodig over de juistheid van de autorisaties, is de organisatie nog niet voldoende in control?
  • Biedt Access Governance voldoende basis voor de externe accountant en/of toezichthouders? Afhankelijk van het profiel van de organisatie en de wijze van inrichting van het controleproces kan dit voldoende zijn.
  • Is er behoefte aan automatisering van de processen om autorisaties sneller te laten verwerken?
  • Is er voldoende ‘pijn’ in de organisatie om het aanvraagproces verregaand te gaan aanpassen met workflows/gebruikersinterface voor aanvraagproces en rolgebaseerde toegang?

Het is van belang zich te realiseren dat het niet altijd de ambitie hoeft te zijn om een brede IAM-voorziening te implementeren. Voor sommige organisaties biedt een goed functionerend Access Governance-proces voldoende invulling aan de uitdagingen rondom logisch toegangsbeheer. Daarnaast zijn er nog tussenvormen mogelijk tussen Access Governance en een brede IAM-implementatie. Men kan bijvoorbeeld de bedrijfsregels die binnen Access Governance worden gebruikt ook hanteren in het aanvraagproces. De aanvragen worden dan vooraf getoetst tegen de bedrijfsregels om vervuiling te voorkomen. Ook kan het controleproces bijvoorbeeld verregaand worden geautomatiseerd, waarbij managers via een workflow aangeven of een afwijking moet worden ingetrokken of dat het een geaccepteerde uitzondering betreft.

Conclusie

Het aantoonbaar verantwoording kunnen afleggen over de juistheid van autorisaties is van belang voor organisaties en is voor veel organisaties een uitdaging. Access Governance is een aanpak waarbij autorisaties periodiek op een pragmatische wijze worden geanalyseerd. Op basis van de resultaten kan het teveel aan autorisaties worden geschoond. Met name de pragmatiek van de aanpak komt tegemoet aan de complexiteit van een brede IAM-implementatie waarbij de baten ten aanzien van de juistheid van de toegekende autorisaties op korte termijn uitblijven. Access Governance past goed binnen de financial audit omdat de aanpak de mogelijkheid biedt om specifieke applicaties diepgaand te analyseren op de juistheid van de autorisaties.

Ten slotte biedt een goed functionerend Access Governance-proces de basis om door te groeien richting een brede IAM-implementatie indien een organisatie hiertoe de ambitie heeft.

AudIT Innovation

How do I get more value from my SAP system? This was the title of a study conducted by KPMG Audit, IT Advisory and Tax, of organizations using SAP. Besides questionnaires and interviews, a series of round tables were organized. The research included topics relating to the optimization of SAP, such as centralization, business process management, VAT and financial audit innovation. The study was published in December 2009 in a limited edition ([KPMG09]) for the organizations involved.

This article primarily discusses the views of KPMG in the field of AudIT Innovation. It will describe developments in organizations and the reaction of their auditors to them. Then it provides feedback on the survey results, along with a summary of the round-table discussions.

Vision of KPMG

The prevalent audit approach has not changed substantially in recent decades. Of course, we now use computers, and there are digital files, but the core of the approach is still based on separate investigation of each legal entity (whether for consolidated purposes or not) and, where applicable, local statutory obligations. This is in sharp contrast to developments that we now see in companies, which are increasingly concerned with standardizing and centralizing their primary businesses. In general, there are two trends in IT that an innovative IT-driven control approach makes possible:

Increased use of IT: Companies are increasingly employing IT systems in support of their primary processes. This now goes beyond simply keeping a record of accounts (purchasing, sales, and finance) in an ERP system. The increased use of IT involves automating accounting procedures. Nearly all companies now have web shops or other online portals through which they communicate with customers and suppliers.

Centralization of IT: Particularly in large companies, there is a clear tendency and desire to reduce the number of different IT systems. New techniques make it possible to integrate large parts of a company within one IT system. While, in the past, almost every operating company had a separate IT system, now there is sometimes only one or a limited number of IT systems. Usually, computing is organized by business unit (division, business group) or geographic region (Europe, Americas, Asia).

Of course, the business cases behind these IT trends are not motivated by any desire to provide the external auditor with an innovative approach to IT control. The aim of organizations in centralizing IT systems is primarily to save costs and to standardize the processes supported by IT. Specifically, we see two points that might lead to innovation in an audit approach:

Top down: When organizations have central IT systems, the audit approach can also be centrally organized. The idea is that testing is no longer performed bottom-up in each legal entity but top-down for each IT system. The more legal entities are included in the central IT system (homogeneous control environment), the greater the synergy gains in the audit approach.

IT-driven: Because more processes are supported by IT systems, the transactional flows in an organization (e.g. purchasing, sales) are tested using the IT system. This involves a combination of control-oriented approaches (testing application controls) and substantive procedures. More detail on this subject is provided in the frame.

The financial auditor tries to perform an efficient and effective financial audit. Centralized data and (financial) processes enable routine transactional processes to be audited more efficiently. The auditor will require less time for manual checking of these processes and can focus on non-routine items. The auditor’s use of operational transaction and process controls often shows that the organization needs the insight that they provide. If an organization starts to monitor these controls and make them available, there will not only be a positive and continuous impact on the organization’s internal control system, but the auditor will also be able to use the same techniques. This approach is called continuous monitoring or continuous improvement ([KPMG08]).

AudIT: a three-stage approach

Broadly speaking, the AudIT approach is mirrored in the specific state of development in a given organization. KPMG has developed a maturity model that represents the growth of this AudIT approach (see Figure 1).

C-2011-0-Veld-01

Figure 1: Maturity model for AudIT approach

State 1: Multiple ERPs

The multiple ERP stage relates to organizations that have established a separate ERP or IT system for each country or each distinct corporation. It is often a limited IT control environment in which organizations do, in fact, implement general IT procedures, but little attention is given to automated controls within business processes. For audits of financial statements, the auditor often chooses a local substantive approach. The possibilities of working efficiently are limited, and there is a real risk of duplicating audit work in various countries. Ultimately the result may be suboptimal practice.

Stage 2: Central ERP

With cost reduction as a key incentive, many organizations have been centralizing their ERP systems. This often takes place in conjunction with the establishment of shared service centers. This centralization makes a top-down audit approach possible. There are fewer local procedures required for the execution of central processes, and insight is obtained centrally. Completeness of revenue can, for example, be centrally tested by determining if all sales orders in all countries have been properly carried out, invoiced and ultimately recorded in the accounts. Centrally verifying that (routine) transactions in the sales process are correctly and fully processed frees local auditors from having to execute any procedures concerning these items. The reduction in work might also entail a reduction in audit fees.

Stage 3: Continuous monitoring

The third stage of the audit maturity model is identified as continuous monitoring. This is a logical continuation of the previous stage, as the task of generating various insights into business processes passes from the auditor to the organization itself. This shift often arises from the need of the organization to have a continuous view of its internal control status. Special tools are often used to accomplish this continuous monitoring. So-called “rules” are defined in these tools, which the ERP system continuously analyzes for possible violation of the relevant rule. These exceptions are then reported to the responsible employee for further follow up. For the example mentioned in the previous stage, this would mean that any exceptions to the completeness of revenue could be immediately resolved.

In addition to solving problems before they develop further consequences, this approach also provides insight into the quality of the processes and controls. Analyzing the causes of problems on an ongoing basis makes it possible to modify the system in response to the analytical results as they occur, and thereby prevent future recurrence of similar irregularities.

The AudIT approach in practice

There is currently a clear transition between the traditional audit approach (multi ERPs) and the future audit approach (central ERP and continuous monitoring). In the traditional approach, local teams simply run through each item on the balance sheet. The local results are analyzed by the business unit or process teams before being forwarded to the central team (see Figure 2).

C-2011-0-Veld-02

Figure 2: Transition to AudIT approach

Future audits will make more use of centrally accessible SAP systems and either the manual or automated controls of a shared service center. An ERP-based audit approach is very efficient and effective. It is efficient because maximum use is made of automated controls and segregation of duties. Its effectiveness is due to the exposure of non-segregated duties and/or poorly functioning controls by means of data analysis with support from IT auditors.

The ERP-based audit approach focuses the audit explicitly on exceptions in routine processes. In addition, the financial audit and central teams will concentrate on non-routine processes such as valuations and analytical procedures. In extreme cases, the local teams will only verify the existence of assets and inventories. Besides efficiency gains, experience has shown that the AudIT approach creates more added value, enabling collaboration with the organization in identifying opportunities for business improvement.

Specific survey results

The interviews revealed that auditors were using the SAP system in performing audit procedures. Survey results (from a total of 31 organizations) also show that the organizations are at different stages of maturity (see Figure 3). For instance, most organizations are still using the multiple ERP approach (22). Most of them are already moving to centralized ERP, usually by means of centralization projects. Central ERPs are present in eight organizations. Only one organization is at an even higher stage of maturity, as it has implemented continuous monitoring. The potential for further optimization is certainly there.

C-2011-0-Veld-03

Figure 3: Results of the survey on the AuditIT approach

It is interesting to note the variety of IT audit procedures performed by the auditors involved in these organizations. In general, it is possible to distinguish how the auditor uses the SAP system in the audit by focusing on the following:

  • IT general controls (13 organizations)

    Testing of the so-called IT general controls (ITGC) and segregation of the duties involved in the process. These controls result, however, in little to no direct increase in audit efficiency.
  • IT application controls, in addition to ITGC (12 organizations)

    The use of IT application controls (ITAC) places the emphasis on testing the SAP configuration controls in the business processes. Frequently mentioned examples are the three-way-match and automatic invoicing. These controls can increase audit efficiency. However, the gain is often limited because only one specific flow of transactions is tested.
  • Data analysis, in addition to ITGC and ITAC (6 organizations)

    The use of data analysis makes it possible to control all the transactions in the SAP management system. In reviewing paid invoices, an organization can use three-way and two-way matching to identify the ones that were registered outside tolerances or entered directly into the accounts, taking into account the segregation of duties. Only a limited number of exceptions should be investigated further, just enough to test the extent of the pollution and obtain substantive audit evidence (positive assurance).

The frame displays a detailed case study showing how data analysis of the procurement process can be used to effectively identify and assess residual risks.

Combining the above insights allows us to conclude that the manner in which auditors use IT audit procedures often depends on the maturity of an organization. A multiple ERP approach allows auditors to primarily focus on ITGC and segregation of duties. Practices supplemented by ITAC and data analysis are less commonly used at this level. It is nevertheless striking that, despite the multiple ERP approach, data analysis is still used in the audit approach. This suggests that the audit approach has developed in advance of the maturity of the organization. In such cases, the auditor has a better understanding of SAP processes than the organization does, so that added value is generated by the auditor even at this level of maturity.

As the maturity of the organization increases, the use of IT audit procedures is adjusted by the auditor. As a consequence, relatively greater focus comes to be placed on ITAC and data analysis.

In summary, it can be said that auditors use IT audit procedures to provide added value to the audit and the organization at all levels of maturity. The further centralization of the organization will also lead to continued modification of the approach and, consequently, greater optimization of the audit approach.

Results of round tables

The round-table discussions on June 17 and July 9, 2009 were opened by citing a practical case study of continuous monitoring by Philips Electronics. It revealed that successful continuous monitoring not only provides better and more effective control but also more transparent business processes that enable potential process improvements to be identified. The result is improved collaboration with local units. The message delivered to local units should therefore be, “we are coming to help you improve,” instead of, “we are imposing even more central monitoring.” Continuous monitoring and continuous improvement thus go hand in hand.

During the round-table discussions, it was noted that the old and new audit approaches are, in principle, the same but that technology now makes auditing cheaper and faster. As a result, there is time available to better examine and understand anomalies. Such investigation did not take place in the past. However, continuous monitoring can also be seen as continuous auditing; the auditor can provide input throughout the year so as to largely prevent surprises at the end of the year. This clearly provides more added value and distinguishes the new approach from the old.

This new approach was appealing to most of the participants. The centralization and harmonization of IT and shared service centers are still regarded as challenges. Many divisions continue to work in their own way (locally oriented). “Company-dependency should be eliminated.” Management must make decisions about this issue, and enforce and implement them throughout the organization.

When asked whether continuous monitoring is only relevant to SOx organizations, the participants answered with a resounding “no.” The argument that “the auditor requires it” does not appear to promote the growth of continuous monitoring. The main thrust must be that organizations are longing for a continuous process: “better control is a useful by-product.” When these organizations become more aware of their processes, it often turns out that “SAP is still not being fully used to the best advantage.”

Compliance and control often have a negative connotation. It is important to emphasize the positive side, so these elements are seen as providing added value. One participant gave the example of assigning employees more responsibilities within the organization once they have their processes demonstrably better under control. Better process management also provides better management and control information.

The participants had different views on whether the auditor should be involved in such programs. The process should be primarily borne by the organization and not an “exclusive” responsibility for the auditor. On the other hand, the auditor may be used as a challenger to ensure that the process continues to make satisfactory progress.

Also discussed was the question why standard SAP BW did not support continuous monitoring or could be easily updated with the addition of this function. SAP BW is, however, mainly used for displaying financial and aggregated data. SAP BW currently offers no standard functionality for reporting anomalies in operational business processes. SAP does have other tools available for monitoring business processes. For instance, SAP offers the Business Process Monitoring module of the SAP Solution Manager, in addition to the Governance, Risk and Compliance (GRC) “Process Control” tool. Besides SAP, there are other organizations that provide tools for monitoring business processes.

Final word

Centralization of organizations (e.g. by establishing shared service centers) and centralized ERP systems not only yields cost savings for the organizations in question, but may also enable a subsequent innovative step in the financial audit approach.

The survey results show that the maturity of the audit approach is often associated with the degree of centralization in organizations. The described “bucket approach” reveals, however, that added value may also be gained by organizations that are locally oriented.

During the round-table discussions, it became clear that these organizations expect the auditor to adopt a proactive stance. Ultimately, all participants agreed that the new audit approach is a joint effort achieved by making the necessary changes in the audit approach, SAP systems and the organization. Only then can the new approach yield added value for the audit and the organization.

Practical example of data analysis in the AudIT

The “KPMG Bucket Approach” explained

Many companies are striving to automate as many of their routine processes as possible. The accounting treatment of purchases and sales is an example of this type of routine process. During financial audits of these processes, maximum use could therefore be made of the controls in the process enforced by IT (applicative controls) and controls that are supported by IT (data analysis).

Data analysis is a monitoring control of a detective nature, focused on all data processing in a given period (also known as “substantive testing”). This method of analysis provides insight into the situations where peculiarities in operations occur, defining their materiality in euros or indicating that further investigation is required. The applicative controls are therefore preconditions and preventive in nature. To illustrate the power of data analysis, a concrete example for the procurement process is elaborated below.

Fact-based auditing of the procurement process

Various workflows are distinguishable in the procurement process, each with its own risk. Identification of these risks results in the formulation of control objectives mainly focused on appropriate, timely and complete processing of goods received, invoices and payments.

C-2011-0-Veld-04

Figure 4: Process control in the procurement process on the basis of risk profiles for each flow

Partly due to the separation of duties in this process and the supporting applicative control, each workflow has its own residual risk. Combining the workflow with the subject of the study (goods received, invoices and/or payments) creates “buckets” of residual risks, each requiring its own investigation. At KPMG, this approach is known as the “Bucket Approach”. Figure 5 uses an example situation to further classify the “buckets” and the residual risks. The strength of this approach lies in the completeness with which all invoices and payments are evaluated. In this way, attention is not only paid to the material exceptions but support is also derived from the “positive assurance” resulting from a conclusion of the procurement process based on three-way and two-way-matches.

C-2011-0-Veld-05

Figure 5: Process control based on data analysis

In this example, ninety percent of the invoices with a value of fifty percent of the total procurement flow are directly entered and not linked to an order. No use is therefore made of the power of a control based on three-way and two-way matching. Apart from the increased internal control risk, manually approving all these invoices before making payment is extremely labor intensive.

Another noteworthy bucket is “blocked invoices,” having an acceptable final state with regard to materiality defined in euros and quantity. When entered into SAP, purchase invoices may be blocked for payment if the set tolerance limits on two-or three-way-matches are not met. In addition, invoices can also be manually blocked for payment. Further investigation of the “blocked invoices” in this example has led to the following conclusions:

  • The tolerance limits in SAP for maximum deviation from the amount of the placed order were set at one percent or € 50 per invoice.
  • 844 invoices matched with purchase orders (and a total value of € 89,908,445) were mistakenly blocked for payment and later made payable. A total of 4,090 purchase invoices matched with purchase orders were processed, implying that 21 percent of invoices were blocked for payment.

C-2011-0-Veld-06

Figure 6: Purchasing / Accounts Payable: two- / three-way matching exceeding tolerance (blocked invoices)

The issue confronting the organization was that the automatic authorization of invoices may result in unwanted financial losses, while the manual approval of invoices outside SAP is a disproportionately inefficient manner of processing invoices.

In the situation of the example, it was advisable to investigate the causes of blocked invoices and determine if it was possible to further reduce their number by, for example, promptly recording receipt of goods or adjusting tolerances.

Another discussion in financial auditing concerns the impact of segregation-of-duties conflicts (SOD conflicts). Data analysis can, for example, indicate the extent of any such conflicts involving receipt of invoices and their payment (see Figure 7).

C-2011-0-Veld-07

Figure 7: Segregation-of-duties conflicts (also known as SOD conflicts) involving invoices

  • Sixteen percent of purchases (€ 3,284,000) were implicated in SOD conflicts involving receipt of an invoice and the release of the same invoice for payment.

Non-segregation of the two duties may result in unwanted payment authorizations for invoices and subsequent financial losses. The financial transactions pertaining to SOD conflicts should be evaluated in terms of their undesirability. In addition, SAP segregation of duties involving the registration and release of invoices must be consistently implemented.

These examples illustrate, in a fact-based manner, that both internal control and the efficiency with which accounts are kept can be clearly improved.

Implementing such improvement would lead to a very specific and efficient centralized approach, generating a great deal of added value in the form of recommendations for specific process improvements. In this way, the knife cuts both ways.

Literatuur

[KPMG08] Governance, Risk, and Compliance Driving Value through Controls Monitoring, KPMG IT Advisory, 2008.

[KPMG09] Consolideren of Excelleren, ‘Hoe haal ik meer waarde uit mijn SAP-systeem?’, KPMG IT Advisory, December 2009.

Facts to Value

Decisions are increasingly being made on the basis of business cases built on quantitative data rather than qualitative factors and assumptions. In practice, organizations are displaying a growing appreciation of fact-based (bottom up) methods of gaining insight into business processes: facts to value. Data-mining tools, nowadays known as business intelligence tools, provide greater opportunities for using this approach effectively. The key to success lies in analyzing data, combining data and generating added value as a result. Data mining is being used for an increasing number of purposes, such as analysis of debtor payment and customer buying behavior, forensic investigations, resolving duplicate payments, process analysis and financial auditing. This article describes some successful examples of data mining, and its added value.

Introduction

In effect, data mining is nothing new. It has long been used to provide specifics about a variety of information issues: a good example of this is market research. With the emergence of data-mining solutions, often known as Business Intelligence (BI) solutions, how data is being used by government and industry has become a popular topic. A previously published study by KPMG ([KPMG09]) indicates that the business community is beginning to recognize the benefits and perhaps the need for data mining. Leading system vendors like SAP and specialized consultancy firms are offering ever more ready-made solutions, enabling businesses to perform any type of analysis by means of plug and play. The above KPMG research reveals that about thirty percent of companies surveyed use BI solutions. In addition, most companies that do not use business intelligence solutions plan to implement such solutions within three years. Nevertheless, it should be noted that BI use is still in its infancy. BI remains primarily the domain of a few (IT) specialists, and it is not often approached in a structured way.

The use of ERP systems and the growth toward “single instance” ERP gives companies access to massive volumes of data. As a result, an analysis of the aforementioned company data is extremely useful in providing insight into how the performance of business processes can be smoothly and effectively improved. The data can be used for multiple purposes, including:

  • improving business cases
  • increasing data quality and integrity
  • optimization of working capital
  • fraud detection
  • improving supply chain and inventory management
  • standardizing and optimizing use of the ERP system
  • more effective risk management by providing insight into the risks that a company runs

The government has also discovered the potential of data analysis. Recently, the Netherlands State Secretary of Education sent a letter to the Netherlands House of Representatives indicating a desire to investigate fraud involving the subsidy for childcare costs. The investigation meant establishing a line of communication between two government offices: the Netherlands Tax Administration and the Netherlands Employee Insurance Administration (UWV). Data mining makes it possible to obtain information required for the purposes of running the investigation in a very efficient and effective manner.

Data mining is also a promising and efficient way for companies and auditors to detect possibly unauthorized transactions that fall outside predefined criteria, effectively performing what the current market also identifies as continuous monitoring / continuous auditing. This may be used to keep track of overdrawn credit limits, percentage reductions in sales orders, timely delivery of orders and the volume of credit notes per day. Auditors are also beginning to see increasingly more opportunities for use. In some instances, they are already running software (plug-ins) in their customers’ transaction systems, or else periodically downloading data to detect irregularities over specific time frames. In this way, auditors can be certain about such financial audit items as the “Order to Cash” and “Purchase to Pay” audit cycles, as well as the corresponding balance sheet entries.

Figure 1 shows an example of a report for an external auditor. The report shows the extent to which purchase orders result in goods received and payment. It also reveals anomalies and unfulfilled purchase orders.

C-2011-0-Toledo-01

Figure 1: Example of a report for the external auditor

Successful practical examples

Successful practical examples relate generally to the analysis of fraud cases, process optimization, support for the financial audit and analysis of working capital. Cases involving analysis of working capital, the financial audit and investigation of fraud will be described in order below.

Analysis of working capital

In the current economic climate, companies are paying attention to the management of working capital items. Often companies manage their working capital based on figures in management information reports. There are common indicators for working capital:

  • Days Payable Outstanding (DPO): The weighted average of the difference between the actual payment date and invoice date
  • Days Inventory Outstanding (DIO): The weighted average between the value of the inventory and the turnover (average daily use) of that inventory
  • Days Sales Outstanding (DSO): The weighted average of the difference between the actual receipt of payment and the invoice date

The driving factors or the process performance indicators that affect working capital are often unclear, due to insufficient detail in the available management information. Using the available details in ERP systems makes it possible to determine DPO, DIO and DSO based on system design and actual transactions, enabling the relevant elements of all process steps to be included.

C-2011-0-Toledo-02

Figure 2: Example of a graphical representation of payment behavior

There are typical findings that result from performing a detailed analysis of working capital:

  • The actual payment date for invoices received deviates from the agreed payment period and the company’s policy concerning payment deadlines. For example, invoices are sometimes (or, in a few cases, are often) paid earlier than the payment due date, and discounts for early payment are not (or, are not fully) utilized.
  • Orders take place without requiring the use of preferred suppliers or the prices and the payment terms agreed in framework agreements.
  • The actual receipt of payment differs from the agreement made with the customer. Although ERP systems often have the capacity to undertake an automatic escalation for invoices long overdue, follow-up of outstanding invoices is often late and sometimes never initiated.
  • The frequency of invoicing is often not based on analysis. With a payment period of thirty days from the end of month, it makes no difference for the timing of payment if invoicing occurs at the beginning or end of a month. For a payment period of thirty days after delivery, it is understandably important to immediately send the invoice along with the delivered item.
  • In determining the minimum required inventory, no (or, insufficient) consideration is given to the characteristics of customers or suppliers. For example, the knowledge that a supplier tends to deliver orders early, late or incomplete is not used in determining the minimum required inventory, or high minimum product inventories are maintained for product groups with low sales.

Performing these initial technical analyses will provide all the necessary “food for thought,” even if discussing their results with process owners and executives can be confrontational. It is nevertheless important for such discussions to occur, as they enable these stakeholders to identify specific issues and actions for improvement. The ultimate goal is the optimization of working capital (and its “cash-to-cash cycle time”), thereby minimizing interest costs.

Financial audit

Introduction

Due to the impact of the Sarbanes Oxley Act and increasing scrutiny on corporate governance, public companies have come to place a great deal of emphasis on internal controls. The external auditor also uses the internal control procedures in the audit approach, partly because manual substantive procedures often entail high costs. If there are deficiencies in internal controls, a system-oriented approach, focusing on internal control over financial reporting, cannot always be applied. In such a case it is necessary to conduct substantive work, including additional sampling. Data mining may provide an enormous savings potential in this respect. Using data mining with large databases opens a wide range of possibilities for obtaining audit information about the entire population of data. In auditing jargon, this method is also known as Computer Aided Audit Techniques (CAATS). A number of tools already exist to support it, such as ACL and IDEA. These tools have been used in auditing for years by a number of enthusiastic office experts.

However, experience has shown that the use of CAATS is not always successful. Its implementation and its impact on auditing have been described in another Compact article ([Brou07]). Some relevant observations are:

  • Analyses often produce extensive anomaly reports (list work).
  • Completion of anomaly reports is time intensive.
  • The relationship between the analysis and audit evidence is often unclear.
  • A cost-benefit analysis for data analysis is often lacking because there is no clear relation to the audit approach.

Despite the above observations, the added value of CAATS for the financial audit is clear. The question now is how more added value can be created. Recently, auditors have acquired the necessary experience to be able to improve the effectiveness of the CAATS approach. Successful audits that use data mining have a number of similarities. They involve the following:

  • A clear link between the data analysis to be conducted and the audit approach, with the appropriate analysis for each audit cycle based on the audit approach.
  • Providing positive assurance rather than primarily reporting anomalies.
  • Optimal use of system centralization, with the data being tested from one central location, making it possible to increase efficiency.
  • Reuse of developed queries in subsequent years.

The approach to auditing the financial statements using data analysis or CAATS shall be further elaborated based on these principles. Below is an illustration of how this approach works for an organization that recently implemented a global SAP system.

The method in practice

A Dutch multinational has a global ERP environment, which makes it possible to conduct a central audit for all the processes in “Order to Cash” and “Purchase to Pay.” The auditor identifies key factors at this multinational, including that sales orders are entered completely and accurately, and that all orders result in goods being issued. In consultation with the external auditor, the following analyses are conducted:

  • Data entry
    • Entry of transaction data into master tables is analyzed by testing the parameter settings (input and probability controls);
    • Analysis of any changes to master data from previous periods;
  • Granted access rights and function segregation, after which investigations of transactions are conducted by staff with excessive rights;
  • Accuracy and completeness of the cash and product flows.

Figure 3 provides a graphic representation of the approach.

C-2011-0-Toledo-03

Figure 3: Schematic overview of an audit approach using data-mining tools

Below are two examples of the results of this data analysis.

Segregation of duties

In some cases, access authorizations are designed and implemented too broadly, causing conflicts in Segregation of Duties (SOD). These conflicts expose the organization to potential risks due to a failure to segregate responsibilities for tasks having control functions (e.g. the same person registering an invoice and releasing it for payment). Conducting a factual transaction-level analysis can establish whether any SOD-conflict actually has impact as well as the extent to which it exists. In the case being considered, the degree of SOD-conflict was low. In other words, although a gap in logical access rights did exist, the impact was limited. In addition, transactions could fairly easily be found and followed with little effort.

Payments to suppliers

Data mining can be used in an analysis of the central data warehouse environment to establish what is known as a “three-way match” (a reconciliation of order, receipt of goods and payment). The number of invoices not automatically matched with a purchase order / receipt of goods but ultimately payable is recorded in a standard anomaly list. However, this data analysis also reveals what the number of “good” payments was. In this manner, the anomaly list can be placed in perspective (materiality). Although follow-up was necessary in this case, it is conceivable that there are also cases where the entire list is no longer significant (not important to act on in the scope of the audit). During this analysis, a number of possible duplicate payments were detected, as well as abnormalities in the goods received, possibly due to incorrect record keeping in the warehouse.

These anomalies were then described to the audited organization for follow up. The organization worked with the external auditor to analyze the major anomalies and verify that no unauthorized transactions occurred.

The report has subsequently been completed in accordance with Figure 1.

This approach had a number of benefits for the auditor:

  • The audit could largely be performed from one location.
  • Data analysis could be performed in the planning phase, enabling risk analysis to be based on factual observations.
  • The auditor made further recommendations in the management letter regarding the optimization of business processes. These recommendations were drawn up based on analysis of the same data used for the financial audit.
  • The audit approach using data analysis was following the IT developments in the organization.
  • The approach led to a higher quality audit (full scope, rather than samples).
  • Based on the recommendations in the management letter, the organization has introduced a comprehensive improvement program in order to take a step toward continuous monitoring of exceptions and has tightened logical access control.
  • The auditor has received positive assurance for a large part of the transaction flow.
  • During this audit, the auditor was able to achieve the efficiency gains targeted in the audit proposal.

Investigation of fraud: printed discounts

A publisher issues a number of magazines. The main revenue streams for this organization are income from subscriptions and income from advertisements in the magazines. The company did not have any guidelines or controls concerning the discounts that sales staff could give advertisers. The sales staff kept a record of discounts in a custom application based on Oracle. The publisher had little documentation or knowledge regarding the programming of this custom application. During the financial audit, the auditor heard a rumor that some sales persons were granting discounts to certain advertisers with which they had developed personal relationships. In order to understand the nature and extent of the discounts given, the auditor decided to deploy a forensic data analyst.

Through interviews with staff and with the auditor, the forensic data analyst delineated the advertising process and identified the significant risks that it entailed. The forensic data analyst used data analysis to determine if significant risks actually existed in practice. The data analysis showed that over a hundred different types of discounts existed in the custom application and were actually being used by the sales staff. Furthermore, data analysis also revealed that the flow of credit notes was substantial and that invoices were often manually adjusted after the publication date of the advertisement. The above-mentioned rumor was, however, not supported by the data analysis; the amount or the percentage of discounts did not significantly vary among different sales employees.

The auditor used the results of the data analysis as audit evidence and as support for the management letter regarding the “Order to Cash” process on the advertising revenue stream. Based on the findings in the management letter regarding the advertising revenue stream, the publisher asked the forensic data analyst to assist in setting up a monitoring tool for the this revenue stream. The forensic data analyst assisted in building a dashboard for this publisher that used real-time data analysis to monitor the main risks involving the advertising revenue stream. Based on the findings in the management letter, the publisher also reduced the number of different types of discounts in the custom application. Moreover, the publisher had “application controls” built into the custom system so that credit notes had to be authorized and invoices could no longer be manually adjusted. All these measures have resulted in revenues from advertising rising by thirty percent.

Extraction and analysis process

The data analysis can be performed by using many different standard end-user solutions, ranging from Microsoft Office to advanced business intelligence solutions and monitoring tools. Regardless of the chosen technology, the user of the data mining solution must first define the analyses to be performed and then adapt them to the target environment.

Definition of the analysis is often done in a meeting or workshop with various stakeholders, such as internal audit, process owners, process managers, external auditors, and so on. The outcome of such a meeting is often a list of specifications and requirements that drives data extraction, analysis and reporting.

In adapting the analyses to the target environment (the core system), any application(s) and database(s) must also be investigated. This includes identifying which tables and fields are used, the currency in which certain fields are displayed, and whether fields include or exclude VAT.

Further, the data mining solution consists of three steps (see Figure 4):

  • data extraction (downloads)
  • data analysis
  • reporting and follow-up

C-2011-0-Toledo-04

Figure 4: Data extraction process

Based on the defined analysis and its adaptation to the target environment, a data request is defined, or a selection is made of the tables and fields that should be involved in the data extraction process. In addition to the fields directly mentioned in the report, it is important to include other fields that will be needed to perform the analysis, (e.g. invoice numbers or customer numbers, so multiple tables can be linked together).

Data extraction may occur in three different ways:

  • Execution of an SQL statement for the database. SQL software or database management software can be used to write an SQL statement to make selections directly from the database.
  • Using the application to undertake data extraction. Most applications have a function that allows data extraction to be performed from within the application.
  • Installation of special software. Several vendors have specifically written special software for data extraction on ERP systems in order to simplify the extraction process.

Each of these alternatives has its advantages and disadvantages. It is a good practice to pre-determine which extraction method is most appropriate for each analysis. An SQL statement can work very well in a single analysis and often functions very quickly, but it also requires detailed knowledge of SQL language and the database environment. Data extraction via the application also works well with a single analysis and usually requires less knowledge of SQL and the database, but the extraction is frequently launched in the end-user area of the application. This can affect the performance of the system, especially when large analyses are involved. Installing special software and using extraction profiles provides a good solution for cases involving repeated execution of standard queries. The extraction often takes place in the background with low priority, so that the performance of the system is not affected.

After the data has been extracted, import and analysis can begin. Determining the accuracy and completeness of the data extraction and importation is often overlooked, as a result of which potentially incorrect or incomplete data is used. In theory, there are several ways to ensure the accuracy and completeness of the imported data. The most powerful control involves reconciliation with a hash total. In practice, a hash total is often not available, and reconciliation must occur using standard reports, such as a trial balance.

Once these queries have been performed on the data, the actual analysis can start. The challenge then is to analyze the data and make connections so that data becomes information. The degree to which there was appropriate preparation will become apparent once the data analysis has been run and the initial results validated. The analysis often creates links between the various tables, counts and total values. If euros, British pounds and U.S. dollars are added together or no distinction is made between U.S. and European conventions regarding dates, you may experience unexpected results from the analysis. If not all key fields are recognized during the exploration of the system, linking different tables may fail or lead to strange results.

Thorough knowledge of the organization, systems and accounting procedures is a must in order to perform a good analysis. The process is laborious and requires constant attention. One example that illustrates how important it is to know the procedures is the story of a zealous assistant who, suspecting fraud, conducted an analysis of all bookings made on Sunday. This resulted in a huge list of bookings. The assistant brought it to his manager, who then had to process this list (investigating possible evidence of fraud). What was the ultimate result? Many batches were run on the weekend, and they generated bookings. The assistant’s list turned out to only contain these batches. Nothing improper was going on.

There is now extensive experience in presenting data. The management of an organization is often faced with information overload, making it difficult to distinguish main points from fine details. If the auditor provides management with a visual representation of the results of a data analysis (e.g. graphs and clear tables), the main points are, by definition, visible. By presenting management with graphs of, for example, the number of manual entries per location, credit invoices without receipt of goods, or products delivered to customers who have exceeded their credit limit, the auditor immediately gets management’s attention. Money is being thrown away. Such disruptions in the flow of money and goods requires a great deal of the auditor’s audit time, but the time expenditure can be reduced by data analysis. Employing data analysis with regard to these disruptions enables the auditor to kill two birds with one stone.

Stakeholders undoubtedly have different needs, but ultimately they always want to have the actual underlying data at their disposal, preferably by means of a management dashboard with drill-down functionality. Luckily, drill-down functionality is now technically possible, though not always available or achievable. An intermediate solution that the authors have come across in practice involves using three-layer reports: 1) complete dashboard, 2) display for each process and process step, and finally 3) detailed tables.

An auditor for an international organization compared processes at the various subsidiaries. Management was completely unaware of the differences between the various subsidiaries, which, once discovered, led to interesting discussions. Figure 5 contains an example of how to present the results to company management.

C-2011-0-Toledo-05

Figure 5: Example of a report for management and the external auditor

Lessons learned

The power of data mining is not only in data extraction but also in improving the interpretation and presentation of the data. The key to successful data analysis is:

  • The data analyst has a thorough knowledge of the client’s systems and accounting procedures, and generates a query on the basis of which truly important data is analyzed.
  • The results are presented in a clear manner appropriate to the information required by the user.
  • There is seamless cooperation between the person who has knowledge of the system, the data analyst, and the user, who has knowledge of the client’s auditing and accounting procedures.
  • Verifying imported data. On several occasions, practical experience revealed that work was performed on incomplete data resulting in time-consuming and unnecessary repetition. Since then, extensive verification processes have been part of the successful standard method.

Summary

The concepts of data mining and data analysis are not new. What is new is the realization that presenting the results of data analysis is key to its success.

The current state of the technology and the variety of available tools create a wide range of opportunities for converting data into added value or facts to value. Data analysis should, in our view, be a guiding principle in advising clients. Deployment of these tools (including data extraction) must be guided by customer demand and customer systems. Besides the possibilities for providing support for organizations, there is increasing interest and opportunities for employing data analysis during the financial audit. In certain cases, data analysis and data mining entail huge potential savings for the audit client due to their autonomous ability to determine the value cycle. It is also often possible to use data analysis to promote a system-based approach by determining the impact of common deficiencies in logical access control.

Literatuur

[Brou07] P.P.M.G.G. Brouwers RE RA, Brigitte Beugelaar RE RA and M. Berghuijs, Fact-finding en data-analyse, toepassingen in de praktijk, Compact 2007/3.

[KPMG09] KPMG 2009, Turning Data into Value – A KPMG Survey of Business Intelligence and Data Warehousing, 2009.

Establishing a Tax Control Framework: The utility and necessity of IT

The Dutch Tax Administration has developed a new approach to supervise tax paying organizations. It is called “horizontal supervision.” A vital element in this approach is the “Tax Control Framework.” This article will clarify why it is not only helpful but necessary to apply IT and ERP-systems when setting up a TCF.

Preamble

Prompted by the economic crisis, the interest in risk management has grown substantially. Traditionally, tax risks were not high on the agenda in the area of risk management. But times are changing.

The growing attention to tax by legal bodies and investors is primarily caused by the material impact tax has on the financial position of companies. Stakeholders, like investors, the Tax Administration and other supervising bodies, are asking for a new approach to coping with tax issues. What is at stake is more than complying with tax laws and regulations. Transparency, insight into fiscal risks and adequately controlling these risks are becoming more and more important. Apart from better understanding and controlling tax risks, this will enable companies to benefit from tax opportunities.

Besides the fact that companies are “in control” of their tax issues, it is important that this can be demonstrated to stakeholders, like the Audit Committee, the management and the tax authorities.

Among global tax authorities a similar trend is apparent. They are leaving the path of performing elaborate tax audits as in past years and are increasingly turning to current tax issues, control processes, tax strategies and tax risk management. This approach is shared and promoted by the Organization for Economic Cooperation and Development (OECD) ([OECD08]).

Tax authorities in many countries are refocusing their attention to developing similar initiatives:

  • US Compliance Assurance Program
  • Ireland Cooperative Approach to Tax Compliance
  • UK Compliance Risk Management
  • Australia Forward Compliance Arrangement
  • South Africa Enhanced Relationship Program
  • South Korea Horizontal Compliance for Corporations
  • China Large Business Taxation Department

In the following paragraphs, the concepts “horizontal supervision,” “compliance agreement” and “tax control framework” are explained in more detail. These concepts are the result of the increased attention to tax risks.

Horizontal supervision and compliance agreement

The Dutch Tax Administration describes the following in an announcement regarding horizontal supervision:

“Investigations in the past fiscal year were unsatisfactory for companies, but also for the Tax Administration whose objective is to deal with current tax issues. Sometimes, extreme positions were taken by the parties involved. There was little trust between the parties and little information was shared. Resolving a disagreement led to long delays and high costs for both sides. That did not contribute to enhancing compliance, which was one of the main objectives of the Tax Administration. In order to achieve the objective of enhanced compliance, the Tax Administration introduced horizontal supervision.”

In short, “horizontal supervision” means that the company and the Tax Administration approach each other differently. Trust, transparency and mutual respect are key. Horizontal supervision is in line with developments in the area of corporate governance.

The compliance agreement is the ultimate form of horizontal supervision. In such an agreement specifications are made about the way both parties will cooperate. If a company wants to apply for a compliance agreement, the Tax Administration expects that an adequate TCF is in place or that serious steps are being taken in order to implement a TCF within a reasonable time frame.

Because of horizontal supervision, the focus on a TCF has increased significantly. Often it is assumed that a TCF is a result of horizontal supervision. This is not true. Even companies that do not have a compliance agreement would benefit from implementing a TCF. Not because it is a recommendation from the tax authorities, but because they themselves believe that being in control of tax is essential for good business operations.

Tax control framework (TCF)

A TCF is a set of processes and internal control procedures (hereinafter referred to as “Controls”) ensuring that a company’s tax risks are known and controlled. A TCF is an important means to manage an organization’s overall tax matters.

In principle, it includes all the taxes applying to an organization: for example corporation tax, payroll tax, sales tax and excise duty. However, regulatory energy tax, gambling tax, environmental taxes, container taxes, car taxes, airfare taxes etc. should, where appropriate, also be incorporated into a TCF. The complete, accurate and timely submission of tax returns and payment of assessments also falls within the scope of a TCF.

The above-mentioned types of taxation have interfaces with almost all business processes. Closing a transaction and issuing an invoice, elements of the primary business processes, may impact upon corporation tax, sales tax and excise levies. A TCF is therefore an integral part of an overarching business control framework (BCF).

Because the audit approach of tax authorities is largely determined by the manner in which a company controls its tax and other processes, tax authorities must evaluate the design, implementation and effectiveness of the TCF. In the Netherlands, the Tax Administration has not imposed any minimum requirements on TCFs, but offers guidance for the creation of a good TCF. It has identified the COSO model as a logical starting point, since it is the international standard for setting up an internal control system and is already used by many companies for the creation of a BCF.

A TCF enables a company to achieve its operational and financial tax goals and to implement its tax strategy in a manageable and controllable manner. A TCF helps a company communicate clearly about tax issues with all its external and internal stakeholders.

Benefits of a TCF

A TCF should lead to fully functioning tax procedures. This has several advantages:

  • Work is up to date
  • Certainty about tax position (no more “surprises”)
  • Image improvement, increased stakeholder confidence
  • Efficient and effective control system for taxation
    • Improved quality of tax data
    • Faster reporting of tax
    • Better understanding of the tax situation, providing more insight into tax options
  • Fewer corrections during tax audits and lower audit costs

Additionally, a TCF is useful for much more than concluding a compliance agreement. While a compliance agreement is concluded with tax authorities and has national scope, a TCF can also be used internationally (as an integral part of a BCF), bringing all of an organization’s tax concerns “under control.”

Developing a TCF

The previous section described how a TCF covers all of an organization’s tax issues and how most business processes, often supported by different IT systems, have a direct impact on taxation. IT systems incorporate many control procedures designed to mitigate risks. The role of IT (and thus the involvement of IT consultants and auditors) is also essential in a TCF.

Designing, implementing and maintaining a TCF may involve the following phases. The role of IT is indicated for each phase.

C-2011-0-Peters-t01

Figure 1: TCF method

Phase 1: Planning

The aims and scope of a TCF are established in Phase 1. This involves such issues as the purpose for which the organization wants to use the TCF, the type(s) of tax on which the organization wants to place the primary focus, the decision to only use the TCF for one or more countries, etc. Another important concern is the establishment of a project team and formulation of the terms for controlling the TCF project (including project management and obtaining of resources). It is wise to first run a limited pilot. No specific IT activities are performed at this stage.

Phase 2: Insight

In Phase 2, a large number of cases are identified as a “baseline.” Not entirely voluntarily, we identify the tax strategy, the legal and tax structure, the main products/services and markets, the tax organization, tasks and responsibilities relating to taxes, the main types of taxes, the relevant business processes, IT systems (including authentication mechanisms) and other registries. This broad approach to the organization is required to identify where and how taxation affects the processes in the organization, so that a thorough tax risk analysis can be performed. It is also necessary to determine whether and, if so, to what extent these risks are covered by (automated) Controls.

Since “soft controls” have a major impact on the proper working of “hard controls,” they are also addressed. Examples are “tone at the top,” the motivation and training of employees, corporate culture, the presence of a code of conduct, compensation structure, leadership style, values and tax awareness. Tax authorities usually consider soft controls when assessing the TCF process in connection with the possible conclusion of a compliance agreement.

Eventually, the work in this phase finishes by identifying and describing internal Control deficiencies and prioritizing the next steps in the project to eliminate these defects.

IT has an active role at this stage in the analysis of processes and IT systems. When performing a risk analysis, it could be useful to have an IT auditor or consultant contribute his or her extensive experience.

Phase 3: Design

The design phase focuses on the (re)design of Control procedures. The performance of this task is of course linked to already existing procedures. Where possible, the procedures will be placed in the IT environment, mostly because automated Controls are more efficient and more effective than manual ones. This especially applies to procedures targeting risks in routine processes. For non-routine processes, such as mergers, acquisitions, IPOs or refinancing, an organizational, procedural approach is the more obvious route to take.

IT has an active role in identifying and determining existing and future Controls in tax-relevant IT systems.

Phase 4: Implementation

New and/or modified Control procedures are implemented in this phase, but not before agreeing on priorities in consultation with management and setting a schedule for improvement. “Key Controls” and obvious “control gaps” are first addressed, enabling an initial effort to generate major progress. Communication with all the employees and departments is crucial in this phase. If necessary, employees must be informed, instructed and/or trained. It goes without saying that the role of IT in this phase is also important for the successful implementation of an effective TCF.

Phase 5: Monitoring

Assessing the design, implementation and effectiveness of the Control procedures put in place for the TCF is essentially no different from assessing the implementation and effectiveness of other Controls that are part of the BCF. Wherever possible, this testing is incorporated into the management control processes (self assessment), the audit plan of the internal audit department and/or included in the audit of the external auditor.

While the implementation and effectiveness can, to a large extent, be assessed by direct observation, the repetition of procedures, procedural testing, line checks, etc., great importance is also attached to performing substantive file analysis and (mathematical) sampling of various elements. This enables critical items to be identified and monitored in an efficient manner. Tax authorities are familiar with these methodologies and will appreciate their value. IT will also play an important role in this phase.

The issue of materiality is relevant at this point. The standard of materiality employed by tax authorities is normally much lower than the one used on financial statements. However, the Netherlands Tax Administration notes in this regard that, in “low” level business processes, materiality hardly plays a role; control measures are not designed to ensure that only material items are subject to control. The low materiality standards of tax authorities seem reasonable considering the effectiveness of internal control procedures. The quantity of substantive (monitoring) activities to be performed is then greatly reduced, because a large part can be based on existing internal control procedures.

The findings arising from testing the implementation and effectiveness of a TCF together with changes in internal and external environments form the basis for continuous adjustments and improvements to the TCF.

Integration of a TCF and a BCF into a single platform

In its memorandum, the Netherlands Tax Administration states that a TCF should be regarded as part of a business control framework (BCF). Many companies have been experimenting with a BCF in response to regulations such as the Tabaksblatt Code and Sarbanes Oxley.

In practice, companies are still clearly finding it difficult to comply with such regulations and to demonstrate their compliance. An integrated BCF is set up to reduce the pressure to perform “testing” and “monitoring” activities to a degree that is acceptable to the business and, ultimately, to provide a “single view of risk” ([KPMG08]). This integrated BCF (Figure 2) will include all the Controls required to comply with relevant laws and regulations. In this way, Controls defined for different purposes are effectively and efficiently implemented.

C-2011-0-Peters-01

Figure 2: Integrated approach to TCF and BCF ([KPMG08])

Support by automated tools

A fully integrated BCF is often a complex whole, and an automated tool to monitor Controls may provide a means of handling the complexity. There are many software applications available on the market that deal with governance, risk and compliance. Specific TCF tooling is becoming more widespread.

KPMG Meijburg & Co. has worked with a risk management software company to develop an application that enables a TCF to be completely set up and managed (in-house management by the organization) and to be fully integrated with or expanded by new or existing risk management applications. This application is based on COSO and contains sample risks and Controls for virtually all tax resources. It furthermore responds to the requirements and demands of many clients as well as building on extensive practical experience. Figure 3 provides an overview of the tax risk management section of the application. Figure 4 shows one of its reporting capabilities, in which the “In Control” status is displayed for each entity, tax type and process.

C-2011-0-Peters-02

Figure 3: Tax Risk Management Section

C-2011-0-Peters-03

Figure 4: Reporting Section

The role of ERP systems

In recent years, companies have acquired a great deal of experience in setting up BCFs and, in many cases, bringing them to maturity. By this, we mean that the Controls in the initial BCF, which are primarily manual, are further developed to the point of being automated and becoming therefore often more efficient. A TCF can be immediately integrated into this development without having to go through the learning curve again.

It could be argued that tax controls are divisible into those that ensure the quality of the reporting processes and those that are incorporated into primary business processes and provide the input for the reporting process (see Figure 5). The latter mainly comprise procedures for providing assurance about the accuracy and completeness of this input. For instance, controls may be established to ensure that a VAT declaration is submitted on time to the authorities in various countries and with adequate checks and balances. In this case, the Controls pertain to the reporting process. In business processes, it is possible to guarantee, while considering the probability of error, that VAT codes can never be entered on sales orders manually but are always automatically defined by the system and based on decisive rules. As a result, the accuracy and completeness of the input for the VAT return is ensured by the decision logic. Figure 6 contains several examples of similar VAT risks and their corresponding application Controls.

In most modern ERP systems, the development of this logic is a matter of parameterization and master data management. Assessing the quality of the decision logic in this case is an important control. Testing or data analysis should first be used to establish that the decision logic is functioning properly and can be relied on. To do this, it will be necessary to determine if the change management process in an ERP Competence Center is of sufficient quality for the ERP system in general and the decision logic in particular. A particular concern here is that, when analyzing the impact of a change request, sufficient attention is given to the consequences of the change on tax compliance. In this respect, there is nothing new under the sun. This principle has been long known insofar as it applies to BCFs.

C-2011-0-Peters-04

Figure 5: Scope of tax controls

C-2011-0-Peters-t02

Figure 6: Examples of specific SAP VAT risks and application controls ([Zege07])

Useful tips for successful establishment of a TCF

The authors have extensive practical experience in designing, implementing, maintaining and optimizing business control frameworks and tax control frameworks.

For successful implementation of a TCF (or BCF), they would therefore like to offer you the following practical tips:

  • Dynamic: A TCF must be dynamic – not a snapshot but a film! A TCF goes beyond a quick scan of tax risks and internal Controls. The company tax department should know what is happening within the organization and be involved in it. No cabinet full of paper checklists will suffice.
  • Start small: The trick is to set up a workable and manageable TCF. Limits are necessary. It can always be expanded later. Start with 1 tax type, 1 division and a limited amount of risk. Provide support within the organization.
  • Integration: Contrary to popular belief, a TCF is certainly not just used by tax departments, but also by other staff and departments, such as risk managers, controllers, internal audit and IT. It is absolutely necessary to work with these departments in order to achieve a good and workable TCF as a component of the company’s overall risk management.
  • Platform: Provide an integrated platform for tax and other risk management. Our experience indicates that an organization generally develops a great many Controls for business control frameworks that are not thought to belong to a TCF and that are solidified into a number of procedures. An integrated platform makes everything dynamic. It is important to ensure integration with a business control framework.
  • Automated tools: A fully integrated BCF is often a complex whole. An automated tool to monitor Controls may provide a means of handling the complexity.
  • Structure: A structured and codified approach ensures that a TCF focuses on key risks and processes.
  • Communication: Organizations usually have everything under control. What is difficult is to show that this degree of control exists. This requires communication with other departments, internal and external auditors, directors, tax authorities and supervisors. In our view, a clear TCF with structured overviews and reports is essential for this communication.

We would also like to emphasize one final time that, although the attention given TCFs has certainly been strengthened by horizontal monitoring, controlling all of a company’s tax matters is essential for good business. A TCF should not therefore be limited to taxation in the Netherlands. Application to all national and international tax considerations will not only enable an organization to better manage its tax risks but also to gain greater insight into the possibilities of profiting from tax opportunities.

Literatuur

[Bela08] Tax Control Framework; Van risicogericht naar “in control”: het werk verandert, Belastingdienst, March 2008.

[KPMG08] KPMG, Governance, Risk, and Compliance: Driving value through controls monitoring, KPMG Advisory, 2008.

[KPMG09] KPMG, Total TAX Control, Tax Accounting & Control Services, KPMG Meijburg & Co, 2009.

[OECD08] Organization of Economic Cooperation and Development, Study into the Role of Tax Intermediaries, Fourth OECD Forum on Tax Administration, Cape Town, South Africa, January 2008.

[Zege07] A.T.M. Zegers, Omzetbelastingwetgeving en ERP systemen – een overbrugbare kloof?, Master’s Thesis, Eindhoven University of Technology, The Netherlands, 2007.

Effective master data management

The article is intended as a quick overview of what effective master data management means in today’s business context in terms of risks, challenges and opportunities for companies and decision makers. The article is structured in two main areas, which cover in turn the importance of an effective master data management implementation and the methodology to get there. At the end of the article we aim to illustrate the concepts by presenting a real-life case study from one of our clients, as well as some lessons learned throughout our day-to-day projects.

Introduction

How can we implement master data management (MDM) effectively within our ERP system? I use master data (MD) throughout multiple systems, but how can I ensure its consistency? How can proper MDM mitigate risks within our organization? These are only a few of the questions business managers have started to ask within the past years, as more and more companies began to show a growing interest in the topic of MDM and the benefits (both financial and organizational) that effective MDM can bring.

A number of developments have placed MDM back on the agenda, such as a focus on cost savings, investigating centralization options, and minimizing process inefficiencies. Also, market and compliance regulations such as SOx, Basel II, Solvency 2, which all in some way address the topic of having control over data integrity and reliable reporting, can be triggers for MDM initiatives.

This article is intended as an overview of the MDM concept. It includes some of the challenges companies might face due to improper MDM, as well as KPMG’s experience in this field and the approach we propose for successful MDM.

How bad master data management impacts good business

MDM, in a nutshell, refers to the processes, governance structures, systems and content in place to ensure consistent and accurate source data for transaction processes (such as the management of customer master data, vendor master data, materials, products, services, employees and benefits, etc.). It is a term that emerged in recent years as a hot topic on the IT and business integration agenda. Partly because of companies’ wish for improved efficiency and cost savings, some of it due to the numerous issues being encountered during daily activities, compliance issues arose and opportunities were missed due to lack of a good set of data.

Because master data is often used by multiple applications and processes, an error in master data can have a huge effect on the business processes.

Decision making in the context of bad data

A lot of companies have invested in recent years in business intelligence solutions. One goal, among others, is to achieve better insight into such things as process performance, customer and product profitability, market share, etc. These reporting insights are often the basis for key decision making, however, the quality of the reporting is immediately impacted by the quality of the data. Bad data quality leads to misinformed or under-informed decisions (mostly related to setting the wrong priorities). Also, the return on costly investments in business intelligence is partly diminished if the source data is corrupt or if not enough characteristics are recorded in the master data.

Operational impact of bad master data

A major component of any company’s day-to-day business is the data that is used in business operations and is available to the operational staff. If this data is missing, out of date, or incorrect, the business may suffer delays or financial losses. For example, the production process may be halted due to incorrect material or vendor information. Some examples have been known where incorrect product master data was recorded on product labels for consumer products, resulting in the rejection of a whole shipment destined for import into the target market, ultimately resulting in considerable financial and reputational losses.

Every time wrong data is detected in the system, a root-cause analysis and corrective actions must be performed in order to correct and remediate the issues. This, together with the process rework and corrective actions, takes considerable time and organizational resources. Therefore, addressing and integrating MDM at the start should be part of an operational excellence initiative, in order to solve part of the process inefficiencies.

Compliance

The growing number of quality standards and regulations (industry specific or not) has also drawn attention to MDM. In order to comply with these requirements, companies must meet certain criteria which are directly or indirectly impacted by the quality of data in the systems. There are many compliance risks that companies run from having bad MDM:

  • SOx risks occur in maintaining reporting structures and processing critical master data such as vendor bank accounts, fixed-asset data, contracts and contract conditions.
  • Healthcare, pharmaceutical or food & beverage companies that are regulated by federal health and safety standards may have significant exposure to legal risk and could even lose their operating licenses if their master records are incorrect with respect to expiration dates, product composition, storage locations, recording of ingredients, etc.
  • Fiscal liabilities, such as VAT, produce risk. The VAT remittance may be incorrect if the relevant fields in the master data are not appropriately managed, possibly leading to inaccurate VAT percentages on intercompany sales.

Overview of the master data management environment

In the current business environment, companies often don’t have a precise overview of their customers, products, suppliers, inventory or even employees. Whenever companies add new enterprise applications to “manage” data, they unwittingly contribute to the increased complexity of data management. As a result, the concept of MDM – creating a single, unified view of key source data in an organization – is growing in importance.

Definitions

MDM is a complex topic, as it combines both strategic components (organization & governance) and highly detailed activities (rules for master data items on field level, control points to achieve completeness & uniqueness of MD). Below we detail some widely known industry views on MDM:

  • “The discipline in IT that focuses on the management of reference or master data that is shared by several disparate IT systems and groups” – Wikipedia
  • “MDM is much more than a single technology solution; it requires an ecosystem of technologies to allow the creation, management, and distribution of high-quality master data throughout the organization” – Forrester
  • “MDM is a workflow-driven process in which business units and IT collaborate to harmonize, cleanse, publish and protect common information assets that must be shared across the enterprise.” – Gartner

Scope of master data management

There are some very well-understood and easily identified master data items, such as “customer” and “product.” Most people define master data by simply reciting a commonly agreed upon master data object list, such as customer, material, vendor, employee and asset. But how you identify the data objects that should be managed by a MDM system is much more complex, and defies such rudimentary definitions. In fact, there is a lot of confusion around what should be considered master data and how it is qualified, necessitating a more comprehensive treatment.

C-2011-0-Jonker-01

Figure 1: Characteristics of master data

However, there is no easy universal view on what master data is. How master data is perceived differs from organization to organization and from system to system. Let’s take, for example, sales prices. They may be considered by certain organizations to be master data and handled according to the specific master data flows, or they may be considered to be transactional data and handled accordingly. This may be because of the frequency of change, the nature of the product that is being sold, the level of customer interaction, etc. In some businesses, sales prices are configuration data, maintained by a technical department because they are changed once a year. In other businesses, sales prices change frequently and are managed by the business, so they are considered master data.

The KPMG approach to master data management

The benefits and reasons for optimizing MDM have been addressed before. This section will address how to implement effective MDM within an organization. A number of models exist around MDM, such as DataFlux ([Losh08]), which focuses on a single view of data, and Gartner ([Radc09]), which uses building blocks for their MDM model.

The KPMG MDM model is based on KPMG’s in-depth knowledge of MDM and experience gained during the design and implementation of MDM models and processes for complex organizations with integrated IT landscapes in a range of industries. The next section will explain the reasoning behind the KPMG model, how it should be used and where it deviates from existing MDM models.

Master data management touches every aspect of an organization

Different building blocks of master data management

The MDM model is composed of four elements (governance, process, content and systems) within the various levels of an organization (strategic, tactical and operational), which ensures that the model includes every aspect of the organization. These four elements are interconnected and each of them needs to reach a similar level of growth and improvement in order to produce well-balanced MDM within an organization.

C-2011-0-Jonker-02

Figure 2: Different building blocks of master data management

Maturity model for master data management

In order to assess the MDM maturity of organizations and the progress of a MDM quality improvement project, MDM has been envisioned as a model with five maturity levels. This maturity-level model makes it possible to measure the status of MDM within organizations, based on predefined elements. The KPMG model uses governance, process, content and systems as the key elements for this purpose.

The MDM maturity-level model consists of five levels, where at level 1 (the initial level), there is no ability to manage data quality, but there is some degree of recognition that data duplication exists within the organization. On the reactive level (level 2), some attempts to resolve data quality issues and initiate consolidation are performed. At the managed level (level 3), organizations have multiple initiatives to standardize and improve quality and a mature understanding of the implications of master data for business processes. When the organization has a well-managed framework and KPI’s (key performance indicators) to maintain high-quality data, the proactive level (level 4) is reached. An organization is at the strategic performance level (level 5) if all the applications refer to a single comprehensive master data repository, if the quality of master data is a KPI for all process and data owners, and if synchronization, duplication checks and validations are embedded in tools.

At the start of a MDM project, the ambition level should be set indicating what maturity level the organization aims to reach (for example, maturity level 4: pro-active). This gives a target to work towards in MDM implementation. Figure 3 shows the different ambition levels, explaining what reaching level 4 would involve.

C-2011-0-Jonker-03

Figure 3: Maturity levels of MDM

Master data management model implementation approach

Although a MDM implementation is much more than just tooling and configuring system functionality, the phases commonly found in existing system-implementation methodologies can also be used for a MDM implementation. Based on experiences and good practices with MDM implementations, the following phased approach has been developed. In the remainder of this section we describe, for each phase, the steps required when implementing an MDM model within an organization.

Initiation: agree on business need, scope, definitions and approach

In this phase the initial business case for master data management is defined. It is important to address all business areas here, including “IT demand,” “IT supply,” “business” and “finance and reporting.” All these business domains benefit from solid master data management.

In addition to typical project start up activities, in implementing master data management the following should be addressed:

  • What is our system and organizational scope, and which data elements do we consider master data, which will therefore be within the project’s scope.
  • Define common names for the master data objects within the project’s scope, independently of the system in which they occur. This is very important, since similar master data objects can be named differently in different systems as well as throughout the company. For example, is a vendor the same as a supplier, and what do we consider the customer master data? Is it the buyer, or is it also the shipping location?
Assessment: determine the current situation and set the right priorities

The primary deliverable of the assessment phase is a detailed implementation plan indicating all design, implementation and monitoring activities that will be put into place to make the MDM organization work. To be able to draft this plan, a comprehensive review of the current MDM organization is necessary, in relation to the defined maturity level. The implementation plan should contain those steps that need to be taken for each building block, classified per master data object, steps that will close the gap between the current maturity level and the desired maturity level.

The assessment itself consists mainly of conducting interviews and reviewing existing documentation. This will be combined with data analyses to get insight into the current quality of data as a benchmark that can be referred to during the course of (and after) the project, to measure its success.

The goal of the assessment phase is to prioritize the objects that make up master data management. Prioritizing the different master data objects can be done by looking at criteria such as use of master data, distribution over systems, impact on business processes, strategic and operational requirements, current data quality and issues, other projects, complexity and volume.

This assessment phase results in a “heatmap,” where the different master data objects are plotted based on their current MDM maturity level, so they can be compared to the desired maturity level and the applicable decision criteria. The “heatmap” can be used to cluster similar groups of master data objects having similar current data quality and the same level of complexity. The grouping enables a phased prioritization approach, possibly having different implementation waves. This is illustrated in Figure 4.

C-2011-0-Jonker-04

Figure 4: Heatmap example

Design: how to reach the desired master data management maturity level

This phase is focused on agreeing on the design of the planned MDM structure.

A central role in this phase is considering if and what activities will be centrally or de-centrally governed. This does not include deciding where the activities will be performed (in a central department or distributed throughout the organization), but only whether you actually standardize and centrally steer MDM activities or not (i.e. do you leave this up to the business). In other words, what is going to be the scope and reach of your central MDM structure, and where you are going to allow for business interpretation and administration. In making this decision, a number of factors may play a role:

  • What kinds of objects are already centrally managed? If the company is already used to central management for certain data objects, then it is not advisable to change this.
  • What is the frequency of changes and the process criticality? Certain objects are changed frequently and have strong process impact. For example, a master plan or routing in a production environment can determine which production lines are involved and in which order the product is developed. If a production line should fail, the plan should be adjusted on the spot, to re-route the production over alternative lines.
  • What is the impact of the change, and in which environment does the object operate. If a master data object is part of an isolated system, barely influencing other master data, other business units, and reporting, then this could be de-centrally managed.
  • Local laws and regulations. For some master data objects, country-specific laws and regulations may apply. In these cases it may be more efficient to leave the governance over the related data attributes to the national level.
  • How the organization is structured, what countries, business lines, shared services or (outsourced) third parties are there. The complexity of the organization should not be the deciding factor for central or de-central management, however, it is something that could influence the decision.

Based on this outcome, the first design action should be the governance structure and organizational plan.

A second important step, which is related to the design of the planned MDM structure, is the appointment of master data owners, who will be ultimately responsible for their master data objects. The master data owner will, in the course of the MDM project, act as a change agent taking decisions and making sure that, for his or her master data object, roles will be assigned to employees.

A third step is the design of processes and models. These include the standard MDM maintenance processes (to create, change, block, remove, update, etc.), the MDM incident and issues management processes, guidelines for monitoring and compliance, templates around content and quality (e.g. template for data rule books), the MDM governance model and role model, and other common MDM themes like an MDM portal.

Implementation: getting there

As with most implementations, organizational support and sponsorship is an important element to realize a change. This starts with awareness and consequently a change in the mindset of the master data owners. As mentioned before, the master data owners are key in facilitating and realizing the change from the current (as is) to the new (to be) MDM model for their specific master data object. They will not be able to effectively fulfil this role if they do not fully understand the centrally designed and adapted organizational and process model. The implementation phase, therefore, should start with awareness and training workshops for the master data owners and their team members. The objective of these meetings is to change the mindset and get full buy-in for the newly designed concepts.

After that, the master data owners will be in the driver’s seat and will start communicating with other stakeholders. They will be informed and, whenever necessary, trained in the use of object-specific master data processes, rules, templates, etc. Although master data owners usually have the seniority to carry this process, the involvement and support of senior management (C-level) is necessary to underline the importance of effective MDM for the organization.

Implementing MDM includes “soft” implementation activities (such as aligning processes, assigning roles and responsibilities, deciding on quality criteria and service levels), but also technical “hard” implementation activities. These include: implementing (or extending) the use of workflow, aligning system authorizations with the MDM role design, developing reports and data-quality dashboards, implementing technical data validation rules, automating interfaces and migrating data to one source.

Figure 5 gives an overview of the different “hard” and “soft” implementation activities for becoming a level-4 “pro-active” MDM organization.

C-2011-0-Jonker-05

Figure 5: Graphical overview of level 4 MDM maturity

An organization can decide to implement specific MDM systems and tooling. There are a great number of software suppliers offering specific MDM systems that provide the functionalities described above (and many more). Some believe that MDM issues can be solved by selecting and implementing an MDM tool. That, however, is a misconception. Yes, somewhere down the line organizations may need technology for extraction, transformation, load and data monitoring. Effective MDM, however, starts with a clear and concise governance and organizational model. No tool alone is going to solve an enterprise’s data problems. Organizations must understand that improving their data quality – and building the foundation for an effective MDM implementation – requires them to address internal disagreements and broken processes, and that it is not necessarily a technology-focused effort but a strategic, tactical and operational initiative.

Monitoring: ensuring we stay there

Having completed the implementation phase, the next step is implementing the tools and techniques to actively monitor the quality of the data and the quality of the processes. The objective is to sustain and improve MDM processes along the line. Main activities in this phase are monitoring the data quality and the request processes of the master data objects (for example, against KPI’s or service level agreements).

Often considerable time and effort is spent on data cleansing actions, while less attention is paid to maintaining good data quality. In order to continuously improve the master data process and data quality, efficient monitoring processes should be in place, basically covering the four pillars of MDM. Next some examples are given of what can be monitored:

  • Governance performance: review of issues, problem and management processes
  • Process performance: process response times (time to approve, administer, etc.), percentage of approved and rejected changes, number of emergency changes, number of incidents and time of resolution, metrics around meeting agreed service levels
  • Content and quality: data completeness (empty fields, number of pending transactions because of incomplete MD, missing critical data, etc.), data accuracy (data not matching business rules, incorrect hierarchy assignment, incorrect data over multiple systems), data validity (checks on outdated unused records), data accessibility (number of unauthorized changes, role assignment, temporary authorizations, etc.), data redundancy (double records, double recording in multiple systems)
  • Systems and tooling: interface processing (timely/untimely interface processes, number of issues), unauthorized MD object attribute changes (e.g. adding fields).

The initial implementation of a typical MDM project will end here. However, knowing that today’s organizations are dynamic and that they are frequently improving their processes, setting up an effective MDM structure is never a one-time exercise.

Client case: Master data management at an international consumer company

In early 2008, this company started an initiative to improve the MDM structure by moving towards a more pro-active level that would allow MDM to be one of the enabling processes in realizing strategic business goals. For this initiative, a centralized approach was chosen, where a central MDM body would govern the master data processes of all operating companies in the group. At the group level, a new business MDM department was formed.

A clear example of the benefit realized through this project was the standardization of the brand codes used. When all systems were aligned according to the central data standard, a clear and consistent way of reporting and comparing between different countries and operating companies was established.

Master data management in the roll-out of a new central sales system

With the development and roll-out of a new sales system, the MDM approach was completely integrated from the start of the project. This direct approach within the project resulted in a solid embedding of the data standards and MDM processes in the new sales environment.

During the blueprint phase, the MDM custodians were able to define how the master data objects were to be interpreted in accordance with the standards. During the realization phase of the project, the data definitions were aligned with the systems already existing within the company. As part of the data migration of customer, material and vendor master data, specific validations were executed to ensure the data followed the central data standards. The integration of the MDM processes within the project reduced the go-live risks of the system significantly, as the company was comfortable with the quality of the configuration, organizational and migrated master data.

Improvement opportunities for the next roll-out project

During the project, a number of issues came to light when project consultants proposed solutions slightly deviating from the master data standards. The tension between functionality, project timeline and data standards required support from top management to ensure that central standards were met.

As part of the integration of MDM into the implementation project for the new sales system, the MDM support organization after go-live needed to be developed. When the MDM procedures are not clear or easily available, the central standards tend to give way to local interpretations. A central support tool to register, approve and execute master data change requests proved to be critical in this respect. Subsequently the right level of training was provided to the local master data organization, which ensured solid embedding of the data standards.

Tooling to extract, report and monitor data quality was developed during the project and provided insight into the use of the data standards in both the local and centrally maintained master data objects.

Lessons learned

When looking at recent MDM optimization and implementation projects, there are a number of key messages that we would like to share:

  • MDM cannot be effective without proper data governance. If no one is accountable for data quality, then there is no place for escalating issues or setting data standards and monitoring data quality. The difficulty in MDM optimization projects is often finding the right balance between centralized vs. decentralized maintenance and assigning the right responsibilities to the right people. Master data ownership should be taken seriously, and the people who are assigned to this responsibility should be encouraged, or monitored, after taking full responsibility.
  • MDM should not be implemented as an IT project, but rather as a business improvement project. When the focus is too much on IT (e.g. building workflows, building reports) the actual project success factors are overlooked.
  • Although it seems redundant as an activity, it is very important to have a uniform view per master data object of what is actually meant by the object (definitions). For example, when naming a master data object “product” we have seen that this can be interpreted in a number of ways. This results in a range of different issues, which may in fact not relate to the same master data object.
  • Do not approach MDM from a systems angle. Instead place the master data object front and center. System ownership has its place and function within an organization, but can conflict with proper MDM. The goal of MDM is to cross boundaries such as business lines, processes and systems. The master data owner issues the standard which should be adopted, irrespective of the system.
  • MDM is a complex topic, and requires a combination of both strategic components (organization & governance) and highly detailed activities (rules for master data items on field level, control points to achieve completeness & uniqueness of MD). This requires also the right mix in the project team of technical expertise and business-process knowledge.
  • Use a phased approach. In addressing all master data objects in a company when implementing or optimizing MDM, one basically touches almost all business functions. In order to spread the workload internally (in the project team) and also throughout the company it is advisable to implement the new MDM organization through implementation waves.
  • Consider interrelated connections between master data objects. Although a wave approach is advised (see the previous bullet), the master data quality of related objects should be improved in parallel or at least with only small time gaps between waves. For example, it is of little value to improve sales contract administration while your customer master data is still of poor quality.

Through this article, we hope to have clarified that MDM is an important topic in the current business environment. Even though it will take away some precious time from other vital initiatives of the company, the benefits will be substantial throughout the organization in a relatively short time. The best businesses do run best-in-class MDM processes.

Literatuur

[Bigg08] S.R.M. van den Biggelaar, S. Janssen and A.T.M. Zegers, VAT and ERP: What a CIO should know to avoid high fines, Compact 2008/2.

[Butl09] D. Butler and B. Stackowiak, MDM, An Oracle White Paper, June 2009.

[Dubr10] Vitaly Dubravin, 7 Pillars of a Successful MDM Implementation, 11 April 2010.

[Fish07] Tony Fisher, Demystifying MDM, 20 April 2007.

[IBMM07] IBM, IBM MDM: Effective data governance, 11 November 2007.

[Kast10] Vasuki Kasturi, Impact of Bad Data, 27 February 2010.

[Laws10] Loraine Lawson, MDM: Exercise for Your Data, 16 April 2010.

[Losh08] D. Loshin, MDM Components and the Maturity Model, A DataFlux White Paper 8 October 2008.

[Radc09] J. Radcliffe, The Seven Building Blocks of MDM: A Framework for Success, Research 27 May 2009.

[SAPM03] SAP, SAP® MDM, 2003.

[Sunm08] SUN, SUN™ MDM SUITE, White Paper June 2008.

[Wolt06] Roger Wolter and Kirk Haselden, The What, Why, and How of MDM, Microsoft Corporation, November 2006.

http://tdwi.org/

Assurance in the cloud

Cloud computing seems likely to outgrow the hype stage in 2011. There is a growing realization that cloud computing has a far-reaching impact on the degree of assurance provided by financial statements, in particular concerning annual reports and accounts. Cloud computing means external data storage on the cloud provider’s premises, the sharing of IT resources and dependency upon the public internet. Therefore, the steadily progressive shift from locally installed and maintained IT to the cloud makes it necessary for potential customers to be adequately informed about the following key issues: What is cloud computing? How does cloud computing impact the degree of assurance, in particular concerning financial statements? What steps should be taken? This article will provide answers to these questions.

Introduction

Cloud computing is undoubtedly the most significant phenomenon in IT today. The provision of IT services via the internet, what cloud computing is essentially all about, seems likely to outgrow the hype stage in 2011. A recent study by KPMG shows that nearly 60 percent of Dutch companies are already using cloud services for one or more parts of their IT, or intend to switch to cloud solutions within the next 12 months. The same study also indicates that the majority of respondents consider cloud computing to be the future model of IT. However, it should be noted that of the total expenditures on IT at these companies, the share allocated to cloud computing is still marginal (less than 5 percent) ([KPMG10]).

C-2011-0-Chung-01

Figure 1: Statement based on responses of 125 decision-makers ([KPMG10])

While the established pioneers of cloud computing (Salesforce.com, Amazon and Google being the best known) are steadily expanding their service portfolio, almost all major IT providers are investing heavily in cloud services in order to meet the apparently rising demand. Microsoft, IBM and Oracle are all offering cloud services and cloud-enabling technology to facilitate business processes, occasionally in collaboration with other software companies and IT integrators.

Amidst the cloud euphoria fanned by IT providers and “independent” analysts, there is a growing realization that cloud computing has a far-reaching impact on the degree of assurance provided by financial statements, in particular concerning annual reports and accounts. Factors of importance to financial business processes (access control and authorization, change management, backup and recovery) have different risk profiles in the cloud than they have when they are part of traditional, on-premise systems. As a rule, and from the viewpoint of the customer, cloud computing means external data storage on the cloud provider’s premises, the sharing of IT resources and dependency upon the public internet.

Therefore, the steadily progressive shift from locally installed and maintained IT (also known as on-premise IT) to the cloud makes it necessary for potential customers to be adequately informed. For them, information about the following key issues is important:

  • What is cloud computing?
  • How does cloud computing impact the degree of assurance, in particular concerning financial statements?
  • What steps should be taken?

This article will provide answers to these questions.

What is cloud computing?

Definition

A search using Google or Bing delivers a multitude of definitions, descriptions and opinions on cloud computing. Some speak of “applications on the internet” or “computational style in which IT provides scalable and flexible capabilities as services to external customers through the use of internet technology,” while others qualify it with terms such as “old wine in new bottles.” Obviously, there is a lack of consensus and a lot of confusion on what cloud computing actually is.

Simply stated, cloud computing means the provision of IT services from shared resources via the internet. The internet is often metaphorically depicted as a cloud, hence the term cloud computing. Well-known examples of cloud computing are Gmail, Google Apps, Hotmail and Apple’s MobileMe.

The reason why this seemingly simple concept is explained so differently by IT providers, analysts and academics is mainly due to the fact that cloud computing does not only involve technological but also important business elements. From a technological perspective, cloud computing is based upon already existing technologies such as virtualization, web services, shared data caches, and grid computing. Since ASPs (Application Service Providers) have been providing IT applications over the internet for more than a decade, cloud computing can indeed be denoted as “old wine in new bottles.”

However, the commercial provision of IT services over the internet on a large scale from shared pools of IT resources has only become economically viable due to three relatively recent developments. Firstly, the above-mentioned technologies, of which virtualization and web services are the most important, have been refined, standardized and widely applied during the last five years. Secondly, public broadband networks have become abundant and readily available at reasonable cost. Thirdly, some providers have expanded the scale of their IT resources enormously, making them the major players in the cloud computing market of today.

The business principle of cloud computing is based on the fact that possession/ownership of IT resources (i.e. applications, platforms or infrastructure) is independent of use of these resources. In cloud computing, IT resources, whether it is an application or storage, remain the property of the cloud service provider; customers only pay for the use of the IT service without requiring local soft- or hardware installations. In theory, cloud computing does not require upfront investments (capital expenditures) unlike the traditional, on-premise IT. The customer only needs access to the internet.

C-2011-0-Chung-02

Figure 2: On-premise IT versus cloud computing ([KPMG10])

Layers, characteristics, and types

Cloud services can be offered at various layers of IT. At the software layer, such a service is called Software-as-a-Service (SaaS). Platform-as-a-Service (PaaS) provides IT services at the platform level (e.g. operating systems, application frameworks); in this case, additional software must then be developed or installed by customers. Infrastructure-as-a-Service (IaaS) provides technical infrastructure components (e.g. storage, memory, CPU, network). Additional platform elements and software have to be installed by the customer, or specific infrastructure components can be utilized for on-premise processes (see Figure 3). Generally, cloud service providers specialize in one or two layers only.

C-2011-0-Chung-03

Figure 3: Different layers of cloud computing ([KPMG10])

Depending on the layer, cloud computing has the following characteristics:

  • External data storage and processing. Unlike on-premise IT, data is stored and processed outside the customer’s domain at the cloud service provider’s location(s).
  • Multi-tenancy. Contrary to on-premise IT, resources are shared, to a certain degree, by multiple customers.
  • Internet dependency. Although leased lines and proprietary networks can be used for cloud computing, the primary infrastructure of cloud computing is the public internet.
  • Contracted services. Customers pay for a service (pay-as-you-go or subscription) instead of licenses and/or hardware.
  • On-demand services. In contrast to the vast majority of on-premise IT, cloud services can be used almost instantly.
  • Elasticity. Cloud services can be easily upscaled and downsized.

Multi-tenancy may be limited to a select group of customers or even a single customer, although there is always a degree of multi-tenancy (e.g. physical facilities, cooling, supporting staff) with cloud computing. This form of private or dedicated cloud computing represents an alternative to the public cloud, which has a high degree of multi-tenancy. In either form, customer data is stored at the provider’s location(s).

C-2011-0-Chung-04

Figure 4: Different types of cloud computing ([KPMG10])

Some providers offer private cloud computing solutions in which an organization’s internal IT department uses cloud computing technologies to create an “on-premise cloud.” Since this internal form of cloud computing is fully dependent on internal, on-premise IT, it is highly questionable whether this type can truly be called cloud computing. Therefore, any such notion of an internal cloud will not be discussed in this article.

Drivers of cloud computing

More flexibility

The success of cloud computing is partly due to the fact that the traditional, on-premise IT is increasingly being confronted with technical limitations and complexity while the costs of implementing and maintaining IT systems are scarcely kept under control. Outsourcing and offshoring have only partially solved the problems, and the promised cost savings rarely turned out to be achievable. Cloud computing seems to offer the ideal solution in this respect; it enables companies to phase parts of their IT, including hardware, software and IT personnel. Companies can regain authority over their business, required IT services are obtained over the internet, and the costs are transparent and relatively easy to control.

A recent survey by KPMG revealed that nearly 60 percent of cloud computing customers feel flexibility is the most important benefit. Cloud services can be purchased and used quickly since installation has already been done by the provider, including all associated requirements to manage the IT resources, construct physical facilities and provide security. This is in stark contrast to the lengthy and risky deployment projects that are so typical of on-premise IT ([KPMG10]).

Cloud computing also has the advantage of keeping software development and updates largely out of the customer’s sight. Ideally, the customer only defines a set of specifications and requirements, according to which the provider implements the updates and changes on the relevant parts of the IT environment. The customer is only required to conduct functional tests and decide on acceptance. Consequently, annoying updates to IT systems are a thing of the past.

C-2011-0-Chung-05

Figure 5: Benefits of cloud computing based on responses of 125 decision makers ([KPMG10])

Cost-savings

IT operational costs can be reduced significantly by adopting cloud computing, since this model’s initial investments (capital expenditures) are marginal compared to the costs that are involved with large-scale, costly and risky implementations of on-premise IT resources. All installations actually take place on the provider’s servers, and the management costs for making the services continuously available are borne by the provider. Moreover, there are considerable savings in terms of hardware, server rooms, air conditioning and electricity. The costs passed on to customers are relatively low due to the economies of scale of most cloud service providers, efficient use of (shared) resources, and centralization of expertise.

With cloud computing, charges only apply to the use of the IT service, as the IT resource remains in the possession of the provider. Although subscriptions are still the rule, “pay-as-you-go” has come into vogue recently, enabling the customer to pay each time the service is employed. The advantage of pay-as-you-go is that payment is only made for services that are actually used, and unnecessary overhead is avoided.

Still, it should be noted that, although the initial costs of cloud computing are significantly lower than on-premise IT, the costs of cloud computing remain constant throughout the life cycle of the relevant IT resource, supposing that demand remains constant. The costs of local facilities will, however, diminish gradually, due to depreciation. The cost-savings of cloud computing are therefore highly dependent on the duration of the product life cycle. The longer an IT resource is used, the lower the relative advantage of cloud computing in relation to on-premise IT.

Better scalability

Cloud computing also offers the advantage of being able to adjust the use of IT resources either upwards or downwards, thus improving the scalability of IT.

By using various types of virtualization and load-balancing, cloud computing solutions can easily be scaled up and down. Combined with the “pay-as-you-go” or subscription models that are common to cloud computing, customers only pay for what they use and the required IT capacity is always available (in theory). In contrast to on-premise IT, IT capacity is never idle and never scarce.

C-2011-0-Chung-06

Figure 6: Scalability of cloud computing ([KPMG10])

Into perspective

Notwithstanding the valid drivers of cloud computing and the hype, cloud computing should be put into perspective. The share of IT expenditures allocated to cloud computing is still marginal. Depending on the analysis, the share allocated to cloud computing as of 2010 is between 2 and 4 percent, with the US as the leading outlet of cloud services (60 percent); the rest of the world, including Europe, can be considered as peripheral. No matter how popular cloud computing is in our social lives (Facebook and Gmail as typical cloud services), large-scale adoption of cloud computing by the corporate community is yet to come. For the time being, at least until 2015, traditional, on-premise IT will be the dominant factor ([KPMG10], [OECD10]).

Yet, the emergence of cloud computing cannot be ignored: it is growing between 20 and 40 percent per year, despite (or perhaps thanks to) the economic low tide. Moreover, the move towards centralization and consolidation of IT resources and management is a process that has been taking place since the turn of the millennium. From locally installed IT, many companies chose to set up Shared Service Centers (SSH) in order to make more efficient use of their IT. Then came the waves of hosting applications on external platforms and infrastructure, and outsourcing/offshoring. In this respect, cloud computing can be seen as the next phase in this process and part of the paradigm shift in automation from locally installed/managed IT towards centralized delivery and shared use of services ([KPMG10], [OECD10]).

C-2011-0-Chung-07

Figure 7: Paradigm shift ([KPMG10])

The impact of cloud computing on assurance

Relevant factors

The number of cloud services that are mature and proven is rather limited, although CRM, e-mail, “office” software, document sharing and storage as cloud services are gaining a stronghold in the market. Given this impressive pace of development and growth, even financial software services from the cloud will become common in the near future. As a matter of fact, SaaS for accounting purposes, such as Twinfield and NetSuite, have a well-established reputation amongst mid-sized companies. It will take a while before ERP at Fortune 500 companies will move to the cloud, but the rise and expansion of cloud services is imminent, thus increasingly relevant to the issue of assurance provided in financial statements.

When we focus on the specific impact of cloud computing on the degree of assurance, particularly in financial statements, the following factors must be taken into consideration:

  • access control and authorization;
  • change management; and
  • backup and recovery.

Generally, these are the most important IT topics for investigation within the scope of financial audits.

Risk profile

Cloud computing is not devoid of dangers. Although the number of major incidents involving commonly used cloud services was relatively small in 2010 in relation to the number of customers, the foremost providers (Google, Salesforce.com, Amazon and Microsoft) have all had to remedy several critical vulnerabilities in their cloud offerings. Recently, weaknesses in Hotmail were exposed by hackers, who were able to obtain illegal access to thousands of accounts. Amazon’s Elastic Cloud fell prey to Botnets, and leaks in Google’s Web Service enabled unauthorized individuals to gain access to accounts and passwords.

Although these incidents were caused by various technical and process-related weaknesses, customer data stored at the cloud computing provider’s location was, in all cases to a certain degree, compromised. All this emphasized at least one crucial point: the customer is strongly dependent on, if not entirely at the mercy of, the maturity of the cloud service provider.

The risks of cloud computing should be put into perspective. On the one hand, cloud computing is mainly based on existing technologies such as virtualization, data segregation and web services. So existing IT risks apply, albeit the controls and mitigating measures largely belong on the provider’s side, as the provider owns and manages the IT resources in the cloud. On the other hand, cloud computing has characteristics that considerably affect the risk profile compared to the traditional, on-premise IT. These characteristics are:

  • external data storage and processing;
  • sharing of IT resources with other customers (multi-tenancy); and
  • dependency on the public internet.

C-2011-0-Chung-t01

Table 1: Characteristics impacting risk profile

Access control & authorization

Concerning access control and authorization, all three characteristics related to the risk profile of cloud computing apply. The off-premise nature of the cloud means that the customer depends on the provider’s technology, personnel and processes. Multi-tenancy requires an advanced level of authentication, authorization, and separation of data instances. The public internet involves multiple access points from countless locations, which are exceptionally difficult to control.

In practice, customers are confronted by three issues:

  1. divergent degrees and forms of authentication;
  2. complexity of integrating control processes; and
  3. technical complexity of integrating authentication mechanisms.

Almost all cloud services offer their own forms of authentication. They can range from a combination of account and password (2-factor) to stronger forms, such as a combination of account and password in association with a token (3-factor). The strength of authentication is usually fixed, and additional possibilities for authentication (e.g. tokens and/or authentication using biometric factors) are limited, especially for public cloud services. Specific solutions are available (even in the form of cloud services!) that connect the internal authentication mechanism (usually MS Active Directory) to the provider’s own authentication mechanism. This obviously requires additional investment and expenditure on controls. Besides that, authentication services over the internet is a niche market still in development, and its track record is limited.

Different authentication strengths, especially when authentication of the cloud service is weaker than the customer’s requirements, can lead to weaknesses in the IT environment, with the result that the integrity and confidentiality of (financial) data is harmed.

When the required/desired form of authentication (e.g. a user account based on a specified convention, in conjunction with a password) is not applicable to cloud services, there is a high risk of incurring additional costs and management expenses. After all, two or more forms of authentication are being purchased and managed. Users should not be forgotten here. They have to log-on using extra and possibly other means of authentication in order to gain access to IT services. Multiple log-ons with multiple tokens and/or smart cards can be a very annoying experience, not to mention an additional management burden for the organization.

Single-Sign-On technology may in some cases be applied to establish a consistent form and strength of authentication, but it is generally difficult to implement, seldom fully applicable to all IT services, and often easy to circumvent insofar as cloud services are concerned, as many cloud services can be accessed directly from various access points on the internet.

In most large (more than 5,000 computer users) organizations, the processes for user management (creating, changing and disabling/deleting computer accounts) and authorization (who and/or which roles have which permissions for which data) of internal IT resources are complex and open to improvement. Frequently, this process has weaknesses such as obsolete but still active accounts, thus affecting security. Often authorizations for role/function changes within the organization include new permissions while the old permissions have not been removed, resulting in too many permissions and possibly infringing segregation of duties. This complexity is increased by cloud services that use different procedures and/or other technologies to facilitate these processes. Lack of integrated processes can result in further weak points, with negative consequences for the level of assurance.

Cloud services have their own access control and authorization processes that are, in principal, not directly compatible with the customer’s requirements and wishes. Moreover, (open) standards for authorizations on computer systems are still in their development stages, while protocols such as SAML 2.0 provide sufficient latitude for a range of interpretations, thus hindering integration of different solutions.

Authorization mechanisms for more than 90 percent of purchasing organizations are based on the Security Groups and Group Policy Objects in Active Directory, which may or may not be supplemented by an RBAC tool. Both Active Directory and the RBAC tools are designed for an on-premise IT environment. Integration between different IT environments is therefore complex and still undergoing radical development. For example, Microsoft offers Active Directory Federation Services in order to integrate various Active Directories across multiple organizations. But this technology is also relatively new and not widely used on the market.

In practice, cloud-service authorization mechanisms tend to be independent of those of the internal IT environment. This situation therefore increases the risk of additional management costs, inconsistent processes and higher complexity. Integration with existing internal IT services and between different cloud-computing providers may entail significant integration problems and increase complexity.

This complexity also applies to other security mechanisms. Not only are there multiple solutions, the chain of which is only as strong as its weakest link, but the integration of security often results in compatibility issues and unclear responsibilities.

Given the technology currently in development, mitigating the indicated risks will mainly involve the area of process integration. An effort is also being made to harmonize provider and customer processes regarding access control and authorizations. Similar harmonization may also be a solution for private cloud services. In the case of public cloud services, the customer will have to submit to the provider’s processes. In any case, this factor must be included in the business case.

C-2011-0-Chung-t02

Table 2: Cloud computing risks to access control & authorization

It is therefore recommended that the following steps be taken before moving to the cloud:

  • Identify current processes for user management, authentication and authorization.
  • Define clear requirements regarding management processes, especially concerning authorization management.
  • Define clear technical requirements, especially in terms of (open) standards.
  • Define the future integration of technical architecture before making a choice.
  • Perform technical pilot studies prior to selection.
  • Define exit/migration strategy.
Change management

Concerning change management, two characteristics related to the risk profile of cloud computing apply. IT resources on the provider’s premise means, in the first place, that changes on the IT environment with potential impact on the data are no longer controlled by the customer but by the cloud service provider. Unlike on-premise IT, change management in the cloud is primarily not the customer’s responsibility but that of the cloud service provider.

Secondly, this also means that the customer only has limited influence on the changes in the cloud services that it purchases. In principle, the provider supplies all patches, new versions, and keeps the IT environment available. Multi-tenancy implies that each change has impact on multiple customers, thus limiting the degree of customization and desired time frame of changes.

The principle of multi-tenancy has the advantage of outsourcing complex change management to a specialist as well as more efficient way of implementing changes (one change which applies for multiple customers). The disadvantage is that the customer depends entirely on the provider’s willingness and capacity to perform the required/desired changes. Moreover, undesirable changes cannot, in general, be undone for a single customer, especially when the service has a high degree of multi-tenancy. Although this especially applies to public cloud services, most private clouds are also highly standardized compared to on-premise environments.

In practice, it turns out that the limited control over and grip on changes does not impact the degree of assurance as much as the extent to which the provider grants access to its change management processes, that is: offering transparency. Few providers are openly transparent about the ways in which they manage changes on their systems and only provide useful information about future releases on their cloud services. Generally, there is a persistent lack of clarity regarding how and on what grounds changes are initiated, how the impact analysis is conducted, how a change is tested and how it is approved.

Good SAS70 – after mid 2011 SAS70 standard will be replaced by ISAE 3402 standard – reports seem to offer a solution to this issue, but only a minority of providers engage independent parties to regularly perform external audits. Moreover, the selected IT controls are often based on single-tenant structure and not the multi-tenancy characteristic of cloud services. Many of the controls necessary to ensure segregation of the data and resource utilization of various customers are not selected and therefore rarely audited. Furthermore, the auditor is faced with the problem that current frameworks, such as ISO27001/2, are hardly suitable for multi-tenant environments. New frameworks with new IT controls are currently being formulated, but the number of initiatives remains large without any of the frameworks being widely accepted on the market.

A right-to-audit is recommended in these cases, but its exercise is reserved for the most wealthy and/or influential customers. Few requests for audits are honored and many auditors lack the technical knowledge and experience with the architecture to evaluate cloud services on their proper merits.

Insufficient assurance from the provider can therefore constitute a reason to (temporarily) refrain from using cloud services.

C-2011-0-Chung-t03

Table 3: Cloud computing risks to change management

It is therefore recommended that the following steps be taken before deciding to move to the cloud:

  • Identify change management controls with regards to applicable rules and regulations.
  • Define clear requirements regarding the change management process.
  • Demand right-to-audit where possible.
    • Use additional controls which apply for multi-tenant environments.
    • Make sure audits are performed by experienced auditors understanding cloud services.
Backup & recovery

Backup and recovery in the cloud also depend on measures taken by the provider. Apart from – often standardized – reports on backed up data, customers have to trust that the providers actually back up their data and store it in a safe place under proper storage conditions. In addition, customers have to assume that, in case of emergency, the backed up data can be instantly recovered and its availability quickly restored.

Several major incidents have demonstrated that not all data in the cloud is backed up adequately. Thousands of customers lost their data in the cloud due to the infamous “Sidekick Disaster” at Microsoft and T-Mobile in 2009. In violation of agreements, it turned out that Microsoft and T-Mobile did not fully back up the data of their customers. Furthermore, the part that had been secured only became available after several days.

Besides the issue of failing or missing backups, the use of subcontractors has also become a problem plaguing the cloud. Often, a portion of the cloud services is subsequently outsourced by the provider to other cloud computing providers. It is not uncommon for backups and archiving to be performed by other (specialist) providers in different geographical locations with different regulations concerning data storage, data protection and privacy.

For instance, an important part of the data from a US hospital using a cloud service offered by a US provider turned out to be archived in India. This was a violation of US legislation as it is prohibited to store medical records with personal data outside the US. The US provider had in fact outsourced its archiving activities to an Indian company without informing its customer.

The issue becomes critical when the cloud computing provider is no longer able or no longer willing to make the customer’s data available to the customer. Possibilities for escrow exist, but besides the technical implications concerning recovery of data in the proper format and media, the market has yet to elaborate on legal and technical implications. For example, open data formats which can be interchanged (theoretically) between different technical solutions are seldom enforced and as of 2011, many data in the cloud is in proprietary formats of the provider in question.

A right-to-audit with regard to backup and recovery is recommended, but in practice, only a few requests for audits will be honored. Firstly, it is practically impossible for large providers to have their IT environment constantly audited by thousands of different requests. Secondly, auditing a multi-tenant environment requires specific expertise by auditors regarding architecture and technology which is sparsely available. Therefore, it is better to require transparency from the provider prior to making the purchase.

C-2011-0-Chung-t04

Table 4: Cloud computing risks to backup & recovery

The following steps must therefore be taken before deciding to move to the cloud:

  • Require proper agreements and SLAs with clear thresholds such as recovery times.
  • Obtain a full list of all the parties in the ecosystem of the cloud (which parties are involved?).
  • Identify applicable regulations on data, data protection and privacy on all physical locations of your data in the cloud. Take adequate legal measures.
  • Arrange for escrow.
  • Require open data formats and open standards where possible.
  • Demand right-to-audit where possible.
  • Define exit/migration strategy.
  • Make sure that a risk analysis is performed in advance.

Conclusion

The share of IT expenditures allocated to cloud computing – notwithstanding the hype – is still marginal in terms of total spending on automation, and traditional, on-premise IT will be the dominant factor for the time being. Yet the emergence of cloud computing cannot be ignored: its growth is impressive and the model itself can be seen as the next phase in the process of centralization and consolidation of IT that began during the last decade. CRM, e-mail and storage from the cloud are already becoming de facto standards in automation, and more services will follow.

The impact of cloud computing on the degree of financial assurance should be put into perspective. On the one hand, cloud computing is mainly based on technologies that already exist, such as virtualization and web services, so existing IT risks apply. On the other hand, cloud computing has characteristics that considerably affect the risk profile, compared to the traditional, on-premise IT. These characteristics are:

  • external data storage and processing;
  • sharing of IT resources with other customers (multi-tenancy); and
  • dependency on the public internet.

When we look at the main factors related to assurance in financial statements, namely access control and authorization, change management, and backup and recovery, we can determine that cloud computing harbors risks for the customer and challenges for the auditor.

Discrepancies between access control and authorization requirements of the customer and of the cloud computing service provider in technical and process-related fields can strongly influence the degree of assurance. Methods to integrate different directories are in their early stages of development while standards to align multiple cloud solutions are yet to be determined. In terms of process, the same applies to change management, which occurs virtually out of the customer’s sight and control. With regard to backup and recovery, the customer must be aware that data is not necessarily stored just on the premises of the primary provider and that data recovery may be subject to significant technical and legal complications.

Although measures can be taken to mitigate the risks of cloud computing, on occasion it will be exceptionally difficult or even impossible to implement these mitigations, as a right-to-audit is rarely granted by big providers and current audit standards lack specific controls related to cloud services. In any case, the customer must have an exit/migration strategy ready at all times, enabling it to switch to alternatives at any moment. A thorough risk analysis in association with the development of a business case prior to the adoption of cloud computing is a matter of course.

The rise of cloud computing is seemingly unstoppable, even in the domain of financial business processes. As we speak, organizations are already moving their applications from their traditional, on-premise environments to the cloud. Awareness of this paradigm shift followed by adequate risk management will be a critical success factor.

Literatuur

[Chun09] Mike Chung, Cloud computing als panacee, KPMG, 2009.

[Chun10] Mike Chung, Audit in the Cloud, KPMG, 2010.

[Isac09] ISACA, Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives, ISACA Emerging Technology White Paper, 2009.

[KPMG10] KPMG Advisory, From Hype to Future: KPMG’s 2010 Cloud Computing Survey, KPMG, 2010.

[OECD10] OECD Information Technology Outlook 2010, OECD, 2010.

[Schn09] Bruce Schneier, Schneier on Security, 2008.

[Shaz10] Shay Uzery and Joep Ruiter, Privacywetgeving belemmert cloud computing, Automatisering Gids, March 2010.

SAS 70 revised: ISAE 3402 will focus on financial reporting control procedures

Many people now know that the current SAS 70 standard is going to be fundamentally changed. Expectations are that it will become possible to provide third parties with other (and greater) assurance concerning various responsibilities in the areas of internal control. This new standard, the ISAE 3402 “Assurance Reports on Controls at a Service Organization” was accepted by regulators in September 2009, but it remains to be seen if the changes are, in fact, so great. The differences and the impact of this new standard practice will be further discussed in this article.

Introduction

Beginning in mid-2011, service providers currently using SAS 70 reports will change to a new standard for reporting internal controls to third parties. Based on the recently ratified ISAE 3402 standard, this new standard will in practice replace current standard SAS 70 and, as a result, establish an international basis for practice, supported by the IFAC (International Federation of Accountants) and the ASB (US Auditing Standards Board). In the Netherlands, this standard will be included in the COS standards. The US version is not expected to differ much from the IFAC standard. There is also some question about the extent to which this new standard materially differs from the SAS 70 and what this means for service providers. Are adjustments needed, and what are the constraints and challenges of the new standard? What are the alternatives if parts of ISAE 3402 do not meet the needs of users?

Timetable for implementing the new standard

The proposed effective date for the new standard will affect reporting periods ending after mid 2011 (the final date is yet to be decided). Since service auditor reports cover periods of between six and twelve months, service auditors may use the new standard from the second quarter of 2010. The IAASB and the ASB will allow early adoption of the new standard, so that reports under the new standard can be expected in the second half of 2010.

Background of the international standard

Many service providers use an SAS 70 report (Statement on Auditing Standards No. 70) to provide insight into their methods of managing internal control procedures. SAS 70, which has been the standard for reporting on the internal control framework of a service organization, is now being replaced.[SAS 70 has not officially existed for some time now: the really relevant standard (now actually the regulations) is AU 324 (Professional Standards, vol. I, AU SEC 324). Yet no one speaks about AU 324, because the term SAS 70 has been widely established.] Although the new standard is specifically intended for the reporting of the internal control procedures in a service organization insofar as they relate to the annual audit of a user organization, it is being implemented more widely in practice and actually exceeds the possibilities offered by SAS 70.

Due to the lack of a global standard, several countries are already using standard practices that, in effect, underlie the ISAE 3000 standard, in order to develop their own national standards (see Table 1) ([Bell09]).

C-2011-0-Beek2-t01

Table 1: Country-specific and global standards for internal control reports

The International Auditing and Assurance Standards Board (IAASB) has been eager to establish a global standard for the reporting of control procedures related to outsourced processes. They developed the International Standard on Assurance Engagements (ISAE) 3402. Interested parties were able to provide feedback on the first draft of the text until May 2008,[The responses can be found at: http://www.ifac.org/IAASB/ExposureDrafts.php.] and the IAASB subsequently published a second draft in June 2009, with final approval coming in September 2009. According to current expectations, ISAE 3402 will become the standard for reporting on control procedures in cases involving the outsourcing of activities relating to financial statements around mid-2011, but may also be used even before that time (early adoption). Strictly speaking, an international template already exists and may be adopted by national organizations with or without adjustment. The replacement of US standard SAS 70 was implemented in the US early in 2010. In the Netherlands, NIVRA and NOREA have also begun preparations to adopt ISAE 3402. In the case of NIVRA, this involves COS 3402, and for NOREA, it concerns Directive 3402.

ISAE 3402: main changes

After many years of discussion, one international standard has been established as a basis for national practice. Yet this innovation has somewhat disappointed service report users. For instance, ISAE 3402 is reserved for controls relating to (a part of) the user’s financial accounting. For reporting on other processes, reference has to be made to ISAE 3000, since the new standard does not allow the reporting of control procedures for non-financial processes, not even when financial and non-financial processes are combined. The framework and guidance based on the standard can, of course, be useful for reporting on control procedures outside the scope of financial statements, but in using it in this way, the service organization and the auditor must be aware of the possible (significant) differences in applying criteria for materiality concept, use, etc. In effect, the form and content of the report will change little and the scope not at all, despite the likely name change (SAS 70 disappearing and being replaced by the international SAR, the Service Auditor’s Report). We will return later in the article to the applicability of ISAE 3000 to other (non-financial) processes.

The main differences between SAS 70 and the ISAE 3402 standard are:

  • SAS 70 is an auditing standard. The new standard is an “assurance” standard (an “attestation” standard in the United States). The main changes here involve management being required to include a statement on the operation of the control procedures in the report. This underlines management’s responsibility for establishing a system of controls, but it does not mean that, under the new standard, management establishes a separate function to document and evaluate controls. Of course, the service auditor must be able conclude that management has a reasonable basis with which to support its statement. The auditor’s report will be “direct reporting” and not derived from the management statement.

    Furthermore, the audit criteria (suitable criteria) on which management and the auditor assess internal controls have been included in the ISAE 3402 standard, which was not the case for SAS 70. In this context, suitable criteria (fairness of presentation, suitability of design and operating effectiveness) are to be explained in detail. The standard therefore gives a minimum set of criteria, which the control framework of the service organization must meet. The service auditor shall also assess the adequacy of the criteria and measures taken. The effect of this change will show up in practice, as it is to be expected that the criteria shall receive more explicit attention and the degree of freedom in formulating controls shall decline slightly, since the criteria have to be clearly identified in the audit objectives. The authors expect that connections between the controls and criteria shall remain complex and, therefore, a matter of professional judgment.
  • Viewed somewhat superficially, the auditor’s opinion will seemingly change in the manner explained below. In fact, substantive differences between the old and new standards remain small, with two notable exceptions. First, the auditor shall issue one opinion covering three elements in the assessment criteria. Second, a Type II report shall also involve an opinion covering all three elements throughout the entire period. In a SAS 70 Type II, only the performance of the control activities (Chapter III) is reviewed, while the new standard will test all relevant COSO elements such as monitoring, information & communication, etc. (hence current Chapter II as well). In practice, this could mean more work, depending on the relevance of Chapter II in relation to the control procedures under Chapter III.

Suitable criteria

Fairness of presentation. The auditor shall determine if the description is faithful. Does the description clearly and transparently indicate the elements that are within the report’s scope and/or have to be implemented by the user? Does the description contain sufficient detail and accurate information to enable an assessment about the control procedures? Are the control procedures in the description actually implemented?

Suitability of design. The auditor shall verify if a control procedure is appropriately designed so that the control objectives can be achieved with a reasonable degree of certainty. Even if an individual control procedure is insufficient, the objectives may still be achieved with a reasonable degree of certainty due to the effectiveness of other control procedures.

Operating effectiveness. The auditor shall ascertain if the control procedure is effective. Before a control procedure may be re-used, various pieces of evidence must be considered and tested to determine if it functions as described.

Furthermore, there remain two possible types of reports (Type I for design and implementation of control procedures, and Type II for operation). A report must cover at least six months. The testing activities must be described in the report, while indicating the “sample sizes” used, in case of any relevant exceptions. The current SAS 70 standard has limited the distribution circle for the reports. The new standard 3402 requires the auditor’s opinion to explicitly indicate the users and the intended use. The auditor may consider using additional terminology in relation to limiting the distribution circle.

Review of similarities and differences with the current SAS 70 standard

Differences:

  • The new standard is an assurance standard and no longer an audit standard, which means, among other things, that management is made explicitly accountable. The opinion of the service auditor will look slightly different because a single opinion is given about a variety of elements.
  • In Type II, the main changes are that management is required to include a statement on the operation of the control procedures in the report.
  • In a Type II report, all elements in the report are evaluated in terms of all three criteria throughout the entire reporting period, resulting in one opinion.

Similarities:

  • The anticipated control effort required from management and the service auditor is expected to remain materially the same.
  • There are still two types of reports (Type I and II).
  • Type II reports should cover a minimum period of six months.
  • Restrictions in use remain substantially the same.
  • Testing by the service auditor will remain part of the report.
  • Sample sizes are only mentioned when exceptions are identified.

Alternative for non-financial processes: ISAE 3000

A number of practical objections regarding the existing SAS 70 remain valid. For this reason, the ISAE 3402 only applies to processes related to financial statements, therefore matching the scope of SAS 70. However, current practice reveals that service providers would like to have a broader scope. They wish to have independent assurance about the outsourcing of non-financial components, including:

  • Continuity of the service provider
  • Compliance with SLA agreements
  • Accuracy of the information flows between (for example) pension administration and the Board
  • Communications to stakeholders (governance)

In practice, this extension of the SAS-70 scope is usually included in Section IV of the report and is therefore not included in the opinion contained in the service auditor’s report.

ISAE 3402 is not intended to provide such extension, but there is a good alternative: namely ISAE 3000. This standard already exists and is included by NIVRA in COS 3000, while NOREA has NOREA guideline 3000 for it. Unlike ISAE 3402, the standard is more “free form,” only requiring a number of mandatory elements to be covered. These include the definition of the audit object, the control measures implemented at a particular moment or over time, and qualitative factors, such as reliability, continuity and exclusivity. Where appropriate, the auditor will have to assess the applicability of quality criteria in order to prevent – figuratively speaking – an irrational task from being accepted. Assurance reports can be prepared in a manner virtually identical to the SAS 70 reports. It is also possible to opt for a “short” variant just covering the mandatory SAS-70 components, in which audit objectives and control procedures are indicated in an appendix as supplements to the opinion. In this case, the report actually consists of a statement referring to the relevant control objectives and control procedures in the appendix. The procedures are similar to TPAs (Third Party Announcements), which have been used in the past.

Such a “short” variant is also an alternative for those cases where an internal service center provides assurance to the internal users of its services. Such situations are prevalent in cases where an IT service center provides various departments with infrastructural IT services, as illustrated in Figure 1. The auditors of the data center provide an IT audit report (without assurance) to the divisions for the SAS 70 reports that the divisions provide to their customers.

C-2011-0-Beek2-01

Figure 1: Internal assurance: internal and external

Strictly speaking, an SAS 70 is not used internally, nor is an ISAE 3000. An IT audit report is therefore also illustrated in Figure 1.

An SAS 70 is generally larger and can therefore be more expensive than an ISAE 3000 report. In the case of the ISAE 3000 report providing the same assurance, the appendix to the declaration can be limited to the audit objectives and control procedures, and Section II (of the SAS 70) may be omitted, if desired. The testing by the auditor can still be the same, but this need not be indicated in the assurance report. As mentioned, the ISAE 3000 is free form.

Besides the previously mentioned examples of the use of ISAE 3000, consideration can also be given in this structure to new/other areas about which assurance is to be provided, such as statements regarding confidentiality, privacy, governance and soft controls. In practice, there is an increasing need for assurance in these areas.

In fact, the development of the new ISAE 3402 standard again demonstrates the value of ISAE 3000 as an alternative. An acceptable standard is therefore already available for (IT) service organizations desiring more than the current (SAS 70) and new (ISAE 3402) standards allow.

Sensible choices for the service organization

Service organizations may now choose which standard best meets their needs, based on the ways in which ISAE 3402 or 3000 are incorporated in national guidelines. If the report predominantly concerns financial processes relevant to the annual audit, a standard derived from ISAE 3402 will be the most appropriate. In all other cases, the use of the ISAE 3000 standard will be preferred, in which it is still possible to employ the same structure and degree as in the case of ISAE 3402.

If the decision is made to adopt the new standard, the most important activities for the service organization are:

  • Understanding the changes. In particular, this concerns the need for a management statement to be included in the report.
  • Consultation with service auditor. This especially relates to the expected impact on the service auditor’s report, his or her duties and the impact on any sub-service organizations. The new 3402 standard states that an inclusive report not only has to describe and test the controls used by the sub-service organization, but the organization-wide control procedures as well (Chapter II). This eliminates all the advantages of an inclusive report, and it would be more practical if a sub-service organization prepared its own report. For the sake of report users, it would be beneficial to hold timely discussions on the needs and consequences of early adoption.
  • Transition plans. These should include organizing internal training programs, coordination with the legal department (if any), developing a communications plan and reviewing existing reports and processes to determine how the new criteria will be met. In any event, attention should be given to whether there is an adequate basis for the new management to become assertion based. Unlike SOx 404, not all management controls must be first tested by management before being tested by the auditor.

Conclusion

ISAE 3402 is the new standard for reporting on the management of outsourced processes that relate to the financial reporting of the outsourcing party. This new standard will hardly differ from the SAS 70 standard, so it will not require the service organization to implement any material adjustments. If a service organization wishes to provide insight and assurance about non-financial processes, it is better to choose the ISAE 3000 standard. Moreover, this alternative already exists! In the opinion of the authors, this decision represents the main challenge involved in providing service organizations with more options in demonstrating the accountability of their services with the desired degree of assurance.

Literatuur

[Bell09] Sander van Bellen, Marco Francken and Joyce Grotencleas, De pensioenwereld, 2009.

[Hout09] Dennis Houtekamer and Remco de Graaf, ISAE 3402: einde van de SAS 70 in zicht?, January 2009.

[ISEA09] Proposed New International Standard and Amendments on Assurance Engagements ISAE 3402, Assurance Reports on Controls at a Third Party Service Organisation, IAASB, July 2009.

XML Auditfile als start voor de controle van een jaarrekening

Inzicht in de transactiestromen is een vereiste om risico’s te kunnen inschatten die van belang zijn voor een jaarrekeningcontrole. Het gebruik van auditsoftwaretoepassingen kan bijzonder behulpzaam zijn om inzicht te verkrijgen in de transactiestromen binnen de entiteit, zeker als de data die daarvoor benodigd zijn, vrij eenvoudig te downloaden zijn in de vorm van de XML Auditfile. Door gebruik te maken van standaardqueries kun je eenvoudig trends en bijzonderheden ontdekken die een bron vormen voor de implementatie en uitvoering van de controleaanpak.

Inleiding

De accountant dient (NV COS 315.18) inzicht te verwerven in het voor financiële verslaggeving relevante informatiesysteem, met inbegrip van de daarop betrekking hebbende bedrijfsprocessen, met inbegrip van onder meer:

  • die transactiestromen in het kader van de activiteiten van de entiteit die significant zijn voor de financiële overzichten; en
  • de procedures binnen zowel de informatietechnologie als de handmatige systemen, waardoor de transacties tot stand worden gebracht, vastgelegd, verwerkt, voor zover noodzakelijk gecorrigeerd, overgenomen in het grootboek en waarover in de financiële overzichten wordt gerapporteerd.

Voor de risico-inschattingswerkzaamheden kan de accountant verzoeken om inlichtingen, het doen van cijferanalyses en/of het verrichten van observaties en inspecties. Als onderdeel van deze werkzaamheden kun je auditsoftwaretoepassingen gebruiken.

Bijna alle entiteiten maken gebruik van informatietechnologie, namelijk een financiële administratie om hun transacties vast te leggen. Het verkrijgen van financiële data in elektronische vorm en het analyseren hiervan met behulp van auditsoftwaretoepassingen behoort dus tot de mogelijkheden, zeker als die data die daarvoor benodigd zijn vrij eenvoudig zijn te downloaden in de vorm van de XML Auditfile en hierbij gestandaardiseerde analyses beschikbaar zijn.

Dit artikel gaat in op het gebruik van de XML Auditfile als onderdeel van de risico-inschattingswerkzaamheden van de accountant bij een jaarrekeningcontrole.

XML Auditfile

In het bedrijfsleven is een groot scala aan softwarepakketten voor het voeren van de financiële administratie in gebruik. Ieder pakket biedt in meerdere of mindere mate de mogelijkheid om overzichten van journaalboekingen te exporteren. De formaten waarin gegevens geëxporteerd kunnen worden, variëren echter sterk per softwarepakket, waardoor bij de uitwisseling van deze gegevens vaak conversie vereist is.

Om de uitwisseling van veelgebruikte gegevens uit de grootboekadministratie van ondernemers te vergemakkelijken heeft het XML-platform, een samenwerking van de Belastingdienst, de SRA (samenwerkende registeraccountants & accountants-administratieconsulenten) en softwareleveranciers, XML Auditfile ontwikkeld. Dit is een standaard-bestandsformaat waarin gegevens uit de grootboekadministratie kunnen worden opgeslagen. De eerste versie (1999) van deze standaard was de Auditfile Financieel (ADF), een op ASCII, fixed length gebaseerd bestandsformaat. Op basis van deze standaard heeft het XML-platform een vernieuwde standaard ontwikkeld: de XML Auditfile Financieel (XAF), welke sinds 2003 beschikbaar is.

De XML Auditfile Financieel bevat de volgende gegevens:

  • Header: algemene gegevens (bedrijfsnaam, boekjaar, datum, valuta, etc.) en controletotalen;
  • Grootboekrekeningen: overzicht van grootboekrekeningen, eventueel met leadcode;
  • Grootboekmutaties: overzicht van alle grootboektransacties, onderverdeeld naar dagboek;
  • Stamgegevens (optioneel): overzicht van alle debiteuren en crediteuren.

Een belangrijke toepassing van de XML Auditfile is bij de belastingcontrole. De wet verplicht ondernemers om de financiële administratie in digitale vorm te bewaren en aan te leveren, tenzij deze zo beperkt in omvang is dat zij op papier gemakkelijk gecontroleerd kan worden. De XML Auditfile maakt het voor zowel de belastingdienst als ondernemers eenvoudiger om de benodigde gegevens in digitale vorm uit te wisselen.

De XML Auditfile biedt echter ook belangrijke voordelen voor de accountant die inzicht wil krijgen in de grootboekmutaties. Wanneer een onderneming gebruikmaakt van een boekhoudpakket dat de mogelijkheid biedt om een XML Auditfile te exporteren, kan deze gebruikt worden voor het uitvoeren van data-analyse. Specifieke kennis van het door de onderneming gebruikte boekhoudpakket is dan niet meer nodig. De XML Auditfile kan in een, speciaal voor dit doel ontwikkeld, softwareprogramma worden ingelezen en geanalyseerd.

Inmiddels bieden verschillende softwarepakketten de mogelijkheid om een XML Auditfile te exporteren, waaronder:

  • Exact;
  • Microsoft Dynamics (waaronder Navision, Accapta);
  • Unit4;
  • AFAS;
  • AccountView.

(Bron: www.softwarepakket.nl)

Enkele softwarepakketten bieden daarnaast de mogelijkheid om XML Auditfile in te lezen om deze bijvoorbeeld te kunnen analyseren. Wat opvalt is dat enkele grote ERP-systemen zoals SAP, Oracle, Baan en JD Edwards niet in dit rijtje vermeld staan. Een export van transactiegegevens is wel mogelijk, maar zoals vermeld zullen het bestandsformaat en de opmaak hierbij variëren, waardoor bij de uitwisseling van deze gegevens vaak conversie vereist is.

De kwaliteit van de export van de XML Auditfile varieert. Het merendeel van de softwarepakketten genereert goed bruikbare XML Auditfiles, maar bij het inlezen van bestanden hebben we soms geconstateerd dat de geëxporteerde XML Auditfiles significant afwijken van de door de Belastingdienst gepubliceerde standaard. Afwijkingen van de XML-standaard leiden tot het niet kunnen analyseren van de data. Bij een analyse van verschillende XML Auditfiles hebben we afwijkingen aangetroffen die variëren van minimale zaken (veldinhoud te lang, verplicht veld overgeslagen) tot grote afwijkingen (volgorde van de inhoud volledig door elkaar gegooid, niet gegroepeerd per dagboek). Soms is de oorzaak gelegen in het feit dat de entiteit gebruikmaakt van een verouderde versie van het financiële softwarepakket.

Veelal zijn dan diverse en tijdrovende aanpassingen nodig om de data te kunnen inlezen en om de gestandaardiseerde analyses te kunnen uitvoeren.

Beschikbare tools voor inlezen en gebruik XML Auditfile

Op het gebied van data-analyse zijn er diverse tools beschikbaar, zowel generieke data-analysesoftware zoals IDEA of ACL, als financiële software met data-analysemogelijkheden. Zo kent de administratieve software Exact de mogelijkheid om zogenaamde spilanalyses uit te voeren op de gegevens in Exact, maar ook op andere XML Auditfiles vanuit andere systemen. Met een spilanalyse is het mogelijk een interactief overzicht op te stellen waarin de administratieve gegevens van de klant inzichtelijk worden gemaakt. Met behulp van dit overzicht kan de gebruiker gedetailleerde informatie over onder meer saldi en transacties bekijken.

IDEA van CaseWare is een bestandanalysesoftware om data te kunnen inlezen, weergeven, analyseren, manipuleren en selecteren. Een add-in is beschikbaar om eenvoudig de XML Auditfile in te kunnen lezen. Daarnaast biedt SmartAnalyzer diverse gestandaardiseerde analyses van bijvoorbeeld uitzonderlijke boekingen. Een nadeel van het gebruik van IDEA bij het opstellen van diverse analyses met behulp van SmartAnalyzer is dat voor ieder overzicht een nieuw bestand wordt gecreëerd. Dit leidt bij het uitvoeren van meerdere analyses tot een omvangrijke hoeveelheid aan bestanden en data. En hoewel geheugenruimte op je laptop niet zo duur is, is het houden van overzicht, het bepalen van wat je wel en niet wilt bewaren in het controledossier dan een tijdrovende bezigheid.

De Auditfileviewer van de Belastingdienst biedt de gebruiker de mogelijkheid om een XML Auditfile in te lezen en informatie op transactieniveau te bekijken. De mogelijkheden van verdergaande analyses en het creëren van eigen overzichten zijn hierin echter beperkt.

Alhoewel de nodige tools beschikbaar zijn voor data-analysedoeleinden, bestaat er geen standaardoverzicht met gebruikelijke analyses voor de uitvoering van de risico-inschattingswerkzaamheden bij een jaarrekeningcontrole. Doordat de XML Auditfile de financiële data op een gestandaardiseerde wijze beschikbaar stelt, biedt dat een mogelijkheid om te komen tot gestandaardiseerde analyses en rapporten. De tijd die gemoeid is met het verkrijgen en inlezen van data en het creëren en opvolgen van vele uitzonderingsrapportages, vormt vaak een belemmering bij het toepassen van data-analyses. Ondanks dat is de toegevoegde waarde van CAATs in de jaarrekeningcontrole duidelijk, zoals beschreven in een eerder Compact-artikel ([Tole10]).

Bij een efficiënte en effectieve tool zal de accountant met zo weinig mogelijk handelingen zoveel mogelijk informatie uit het bestand moeten kunnen halen welke relevant is voor de planning en uitvoering van de jaarrekeningcontrole. De accountant kan bij een klant een export van het grootboek in het XML Auditfile bestandsformaat opvragen. Door gebruik te maken van gestandaardiseerde rapporten kan de accountant op eenvoudige wijze inzicht krijgen in de transactiestromen van de organisatie. Tevens bestaat de mogelijkheid om de data te exporteren naar bijvoorbeeld Excel voor verdere analyse.

De relatie tussen de analyses en audit evidence is vaak onduidelijk ([Tole10]). Het is daarom van belang dat de standaardrapportages vanuit de XML Auditfile aansluiten op de beweringen in de jaarrekening. Natuurlijk kun je rapportages per grootboekrekening opstellen, maar dit komt het inzicht veelal niet ten goede en is te gedetailleerd als startpunt voor de risico-inschattingswerkzaamheden van de accountant. Een handige groepering van grootboekrekeningposten is de groepering of aggregatie per jaarrekeningpost. Naast de groepering per jaarrekeningpost is ook een vaste indeling van dagboekcodes wenselijk om de veelheid van dwarsdoorsneden als startpunt voor de risico-inschattingswerkzaamheden te beperken. Dus niet zes verschillende dagboekcodes voor memoriaalposten maar een geaggregeerde dagboekcode voor alle memoriaalposten als startpunt. De dagboekcodes vormen een belangrijke bron van inzicht in de transactiestromen, maar in enkele gevallen draagt het aantal gehanteerde dagboekcodes door een entiteit niet bij aan een eenvoudig totaaloverzicht of helikopterview van de uitgevoerde transacties.

De aggregatie van data is één van de belangrijkste uitdagingen bij data-analyses voor de risico-inschattingswerkzaamheden. Enerzijds zijn deze werkzaamheden op een hoger detailniveau en is aggregatie gepast. Anderzijds wil je door de aggregatie niet bijzonderheden verliezen die aanwijzingen geven tot bepaalde risico’s. Bij alle standaardrapportages is het wenselijk om in te kunnen zoomen op de onderliggende details.

Doelstelling bij het opstellen van analyses, met behulp van zelfontwikkelde tools, is niet zozeer het genereren van zoveel mogelijk verschillende analyses, maar juist te bepalen welke overzichten bijdragen aan het inzicht van de accountant in de transactiestromen in het kader van de activiteiten van de entiteit die significant zijn voor de financiële overzichten. En hoe dit inzicht vervolgens bijdraagt aan de opzet en implementatie van de controleaanpak. In de volgende paragraaf zal hier verder op worden ingegaan.

Analyses ten behoeve van de opzet en implementatie van de controleaanpak

Hierna wordt voor enkele van deze analyses beschreven hoe zij bijdragen aan het verbeterde inzicht in de bedrijfsprocessen en transactiestromen en het efficiënt en effectief inrichten van de controle. De volgende overzichten of draaitabellen komen aan de orde:

  • totaaloverzicht transacties per dagboek per jaarrekeningpost;
  • overzicht transacties van een jaarrekeningpost per tegenjaarrekeningpost;
  • overzicht transacties van een jaarrekeningpost per periode;
  • overzicht stratificatie van de transacties van een jaarrekeningpost.

Totaaloverzicht transacties per dagboek per jaarrekeningpost

Een overzicht waarbij per jaarrekeningpost het totaal van de transacties vanuit de diverse dagboeken op de betreffende jaarrekeningpost is geboekt, biedt inzicht in de soorten transacties en boekingsgangen die de entiteit hanteert. Op basis daarvan kunnen de routinematige en niet-routinematige transacties worden onderscheiden en bijzondere transactiestromen en boekingsgangen worden geïdentificeerd.

Ook kunnen logische verbanden in de transacties en geld- en goederenbeweging worden gesignaleerd. Op basis van deze analyse kan de accountant bepalen welke jaarrekeningpost de nadere focus verdient en waar een systeem- of gegevensgerichte aanpak mogelijk is. Waar bijvoorbeeld logische verbanden in de transacties en geld- en goederenbeweging blijken, zou de accountant weinig gegevensgerichte werkzaamheden hoeven te verrichten en worden routinematige transacties normaal systeemgericht gecontroleerd. In figuur 1 is een voorbeeld van een totaaloverzicht transacties per dagboek per jaarrekeningpost opgenomen.

C-2010-3-Langen-01

Figuur 1. Voorbeeld totaaloverzicht transacties per dagboek per jaarrekeningpost.

Uit figuur 1 blijkt onder andere het logische verband tussen debiteuren (714.000), omzet (600.000) en de te betalen 19% btw (114.000) bij de omzetboeking. Een vergelijkbaar verband blijkt uit de inkopen van de voorraden. Duidelijk is het geld- en goederenverband dat uit de transacties van de dagboeken en begin- en eindbalans blijkt. Op basis van vorengenoemde verbanden kan de accountant voor de controle op juistheid, volledigheid en bestaan van debiteuren, omzet en kostprijs omzet steunen op de effectieve werking van de interne beheersing rondom deze transactiestroom. De profesioneel-kritische accountant zal bij zo’n duidelijk verband in de geldbeweging, op basis van zijn professionele oordeelsvorming, nagaan welke risico’s nog aanwezig zijn en welke aanvullende controle-informatie hierbij nodig is.

Bij een verdere splitsing van de vorenvermelde totaalbedragen per dagboek in debet- en creditbedragen (niet in figuur 1 opgenomen) ontstaat inzicht in bijvoorbeeld de omvang van de retouren (debet voorraden/omzet en credit debiteuren/kostprijs omzet) die plaatsvinden. Verder geven de transacties via het memoriaal inzicht in de omvang van handmatige posten. De verwerking van retouren en handmatige posten zal waarschijnlijk geschieden via een ander proces waarvoor andere risico’s en interne beheersingsmaatregelen van toepassing zijn en waarvoor een andere controleaanpak wenselijk is.

Overzicht transacties van een jaarrekeningpost per tegenjaarrekeningpost

Met data-analyse kun je transacties van een specifieke jaarrekeningpost sorteren naar de tegenrekening (op jaarrekeningpostniveau). Zo’n overzicht laat op het niveau jaarrekeningpost (of grootboekrekening) zien waar het andere deel van de boeking is geboekt en biedt daarmee inzicht in de gehanteerde boekingsgangen. Tevens kunnen ongebruikelijke transacties, waaraan extra aandacht dient te worden besteed, worden geïdentificeerd.

Indien bij bankmutaties als tegenrekening kostenposten blijken, dan zijn deze transacties geboekt buiten het reguliere inkoopproces (niet via inkoopboek en crediteuren). Een nadere analyse zal dan inzicht kunnen geven in de aard van deze posten, zoals periodieke machtiging voor bepaalde kostensoorten als energiekosten, spoedbetalingen of anderszins. In figuur 2 is een voorbeeld van een overzicht transacties van de jaarrekeningpost bank per tegenjaarrekeningpost opgenomen.

C-2010-3-Langen-02

Figuur 2. Voorbeeld overzicht transacties van de post bank per tegenjaarrekeningpost.

Overzicht transacties van een jaarrekeningpost per periode

Een overzicht van transacties per periode geeft weer in welke periode van het jaar (bijvoorbeeld maand) de transacties van een bepaalde jaarrekeningpost zijn verantwoord. Op basis van dit overzicht kan de accountant analyseren of het verloop van de transacties over het jaar heen gebruikelijk is en bij de aard van de activiteiten van de entiteit past (seizoenspatronen). Dezelfde analyse op het niveau van een grootboekrekening kan nuttig zijn. In figuur 3 is een voorbeeld van een overzicht van de transacties van de post debiteuren per maand gegeven.

C-2010-3-Langen-03

Figuur 3. Voorbeeld overzicht transacties van de post bank per maand.

Uit figuur 3 blijkt dat het bedrag aan debet en credit debiteurentransacties relatief hoger is aan het begin van het jaar. Omdat in dit voorbeeld de betreffende entiteit ruimten voor een periode van één jaar ter beschikking stelt en deze aan het begin van het jaar factureert, past dit verloop bij de aard van de activiteiten van de entiteit.

Overzicht stratificatie van de transacties van een jaarrekeningpost

Een ander overzicht dat snel inzicht biedt in de aard en omvang van transacties is een stratificatie van de transactiestromen. In deze analyse worden de transacties van een jaarrekeningpost ingedeeld naar enkele lagen die gerelateerd zijn aan de omvang per transactie. De accountant kan deze omvangslagen bepalen op basis van zijn uitvoeringsmaterialiteit. Bijvoorbeeld (i) transacties > 75% van de materialiteit, (ii) transacties tussen 75% en 5% van de materialiteit en (iii) transacties < 5% van de materialiteit. Deze analyse geeft de accountant inzicht in de samenstelling van de transacties op een jaarrekeningpost. Het inzoomen naar transacties op grootboekniveau is ook mogelijk. Indien bijvoorbeeld de betreffende jaarrekeningpost uit veel transacties bestaat maar waarvan 80% wordt gevormd door enkele transacties groter dan 75% van de tolerantie, kan de accountant bepalen dat een gegevensgerichte controleaanpak op deze post efficiënter en effectiever is.

Resultaten van de data-analyse en gebruik hiervan als controle-informatie

In een eerder Compact-artikel ‘AudIT Innovation’ ([Veld10]) is benoemd dat door gebruik te maken van centraal beschikbare data en (financiële) processen, routinematige transactionele processen efficiënter kunnen worden gecontroleerd. In dat artikel ligt de focus op centralisatie van ERP-systemen. Maar voor kleinere entiteiten zonder (gecentraliseerde) ERP-systemen kan het gebruik van de XML Auditfile een hulpmiddel zijn voor het bepalen van de controleaanpak.

De diverse analyses die mogelijk zijn geven snel inzicht in de aard en omvang van transactiestromen van een entiteit. Bij een entiteit bleek een opvallend seizoenspatroon voor facturering en debiteurenontvangsten. Bij een andere entiteit bleek door de implementatie van een nieuw financieel systeem de boekingsgang significant gewijzigd te zijn met diverse nieuwe tussenrekeningen waarvan de impact nog niet volledig was onderkend. Vervolgens is gebleken dat dit soort overzichten bijzonder behulpzaam is voor nieuwe teamleden. Bij teamleden met enige ervaring met de entiteit leverden bovenstaande overzichten vaak een bevestiging op van het beeld van de entiteit dat zij al hadden, maar leidden zij veelal niet tot nieuwe of andere inzichten. De overzichten zijn in zo’n situatie wel behulpzaam om de huidige kennis en risico’s te bevestigen en te documenteren.

De beschikbare overzichten geven ook snel inzicht in de kwaliteit van de financiële administratie. Bij diverse entiteiten constateerden we een veelvuldig gebruik van handmatige boekingen (memoriaalposten) al dan niet in combinatie met verzamelboekingen aan het einde van de maand, waarbij verschillende memoriaalposten als een journaalpost waren verwerkt. Hierdoor waren overzichten als boeking per tegenrekening soms onbruikbaar omdat niet één of enkele tegenrekeningen bij een boeking waren gebruikt. Een overzicht naar tegenrekening, waarbij je het journaalpostnummer als identificatie gebruikt, levert dan al gauw een lang overzicht op met een flinke hoeveelheid aan grootboekrekeningen. Een belangrijke conclusie die je dan kunt trekken is dat een controle van de handmatige journaalposten meer tijd vergt om de diverse regels van zo’n journaalboeking op aanvaardbaarheid te toetsen. De overzichten gaven in dat geval onvoldoende inzicht in de transactiestromen. Bij de uitvoer van (verplichte) werkzaamheden ten aanzien van journaalposten zou dit ook naar voren zijn gekomen.

Bij enkele entiteiten waren de bankboekingen niet eenvoudig als volledige journaalposten te onderkennen. De mutaties hadden in dat geval elk een aparte transactie-identificatie meegekregen, wat in eerste instantie dan leidt tot enkelvoudige journaalposten. Met data-analysesoftware kun je hierbij wel een work around creëren (transactieID aanpassen voor bankmutaties), maar dit kost extra tijd en niet iedere eindgebruiker kan dat op eenvoudige wijze zelfstandig.

In deze auditstandaarden zoals die gelden voor perioden eindigend op of na 15 december 2010 zijn auditsoftwaretoepassingen (Computer Assisted Audit Techniques, CAATs) gedefinieerd als geautomatiseerde controlewerkzaamheden waarbij gebruik wordt gemaakt van de computer. In deze standaarden wordt in enkele paragrafen specifiek ingegaan op het gebruik van auditsoftwaretoepassingen. Tabel 1 geeft een overzicht.

C-2010-3-Langen-t01

Tabel 1. Passages die specifiek ingaan op het gebruik van auditsoftwaretoepassingen. [Klik hier voor grotere afbeelding]

Een belangrijke vraag was in hoeverre de overzichten bijdragen aan een efficiënte uitvoering van de risico-inschattingswerkzaamheden van de accountant. De auditstandaarden onderkennen de toepassing van auditsoftware als een mogelijkheid voor het verkrijgen van informatie, doorzoeken van informatie, vaststellen van afwijkingen, toetsen van transacties en verkrijgen van controle-informatie over de werking van interne beheersingsmaatregelen.

De standaarden geven niet aan hoe je dit het meest efficiënt kunt doen. Data-analyse kan bijzonder tijdrovend zijn indien data niet zijn gestandaardiseerd en/of indien het einddoel onduidelijk is. Met data uit de XML Auditfile is het inlezen van data eenvoudig. De standaardoverzichten zijn ook eenvoudig te vervaardigen. De interpretatie hiervan en bepaling van de impact op de opzet en implementatie van de controleaanpak blijft in belangrijke mate steunen op de professionele oordeelsvorming van de professioneel-kritische accountant. Hoe meer gestandaardiseerd het transactieverwerkingsproces verloopt bij een entiteit, hoe makkelijker het is om harde verbanden te onderkennen en die te gebruiken als maatstaf voor de selectie van transacties met een verhoogd risico.

Het gebruik van tooling om de XML Auditfile in te lezen en standaardrapportages te genereren zal de controleaanpak niet wezenlijk veranderen. Wel geven de standaardrapportages inzicht hoe transactiestromen worden verwerkt, en inzicht in de kwaliteit van de administratie, en daarmee zijn zij een bijzonder handig hulpmiddel bij de uitvoering van de risico-inschattingswerkzaamheden.

Samenvatting

Auditstandaarden geven de mogelijkheid om auditsoftwaretoepassingen in te zetten gedurende de diverse fasen in de audit. Bij de invoering van de nieuwe standaarden is de wijze waarop auditsoftwaretoepassingen kunnen worden ingezet, niet gewijzigd. Door gebruik te maken van beschikbare data kunnen routinematige transactionele processen efficiënter worden gecontroleerd.

De XML Auditfile is met name bij kleinere entiteiten zonder (centrale) ERP-systemen een belangrijke bron van input die kan worden gebruikt. Dit overzicht bevat alle financiële transacties van een entiteit. Om de aansluiting met de jaarrekeningcontrole te maken en om de hoeveelheid aan overzichten te beperken (voor een helikopterview) is hierbij een nadere groepering naar jaarrekeningpost gewenst.

Door gebruik te maken van standaardoverzichten kan efficiënt inzicht worden verkregen in de aard en omvang van de transactiestromen. Dit inzicht is bijzonder handig voor nieuwe teamleden en veelal een bevestiging van het inzicht bij bestaande teamleden.

De interpretatie van de overzichten en de bepaling van de impact op de opzet en implementatie van de controleaanpak blijven in belangrijke mate steunen op de professionele oordeelsvorming van de professioneel-kritische accountant. Hoe meer gestandaardiseerd het transactieverwerkingsproces verloopt bij een entiteit, hoe makkelijker het is om harde verbanden te onderkennen en die te gebruiken als maatstaf voor de selectie van transacties met een verhoogd risico. De uitdaging hierbij is om de tooling zodanig te standaardiseren dat deze grootschalig en efficiënt kan worden ingezet, waarbij de focus niet moet liggen op de tooling maar op de toegevoegde waarde voor de controle en de entiteit.

Literatuur

[NIVR10] Koninklijk Nederlands Instituut van Registeraccountants (NIVRA), Amsterdam en de Nederlandse Orde van Accountants-Administratieconsulenten (NOvAA), Den Haag, Handleiding Regelgeving Accountancy Deel 1a, mei 2010.

[Tole10] Drs. Peter van Toledo RE RA, drs. Gideon Lamberiks RE en Quintra Rijnders MSc RA, Facts to Value – Data omzetten in toegevoegde waarde, Compact 2010/1.

[Veld10] Drs. Maurice op het Veld RE, drs. ing. Stephen van den Biggelaar RE en drs. Eric Daanen RE, AudIT Innovation, Compact 2010/1.

Facts to Value, beyond application security

Datamining, data-analyse, Facts to Value en ‘fact based audits’ zijn veelgehoorde kreten in deze tijd. De ontwikkelingen in IT maken een andere wijze van IT-audit in het kader van de jaarrekeningcontrole mogelijk. In dit artikel wordt stilgestaan bij het beoordelen van de IT-beheersing in de gehele keten, naast applicaties ook de technische infrastructuur. Met behulp van moderne tooling en verfijnde auditingtechnieken kan de daadwerkelijke inrichting van autorisaties en security settings efficiënter en effectiever worden beoordeeld. De auteurs stellen hierbij een integrale aanpak en visie voor.

Inleiding

In de praktijk zien we dat de IT-audits verschillende accenten hebben over de jaren heen. Na de invoering van SOx zagen we een verhoogde aandacht voor IT in het kader van de jaarrekeningcontrole, waarbij het accent in eerste instantie lag op de IT general controls (hierna: ITGC). Na een sterkere focus op de application controls zien we nu een sterke nadruk op de zogenaamde Facts to Value-aanpak (Tole10). In deze aanpak wordt datamining onder andere toegepast om de goede werking van de application controls aan te tonen en gegevensgericht te controleren. De auteurs onderschrijven het belang van de focus op de primaire bedrijfsprocessen en willen in dit artikel stilstaan bij het belang om de IT-security in de gehele keten te blijven beoordelen en hierbij eveneens de efficiency en effectiviteit te verbeteren door het gebruik van datamining.

In de eerste paragraaf zal kort worden ingegaan op het belang van de IT-controls in het kader van de jaarrekeningcontrole, waarbij de keten kort wordt toegelicht. Vervolgens wordt verder ingegaan op de samenhang tussen de Facts to Value-aanpak en Access Governance en Automated Security Review. Het artikel wordt afgesloten met een conclusie.

Application en IT general controls

In het kader van de jaarrekeningcontrole staat de beheersing van de bedrijfsprocessen ten behoeve van de financiële verantwoording centraal. Hierbij is betrouwbaarheid een belangrijk aspect, maar ook continuïteit (BW9) en Fraude (ISA-240). De IT ondersteunt de betreffende processen en zal daarmee ook voldoende moeten worden beheerst in het licht van deze drie aspecten. In de huidige aanpak wordt een onderscheid gemaakt tussen:

  1. de application controls (input – output controls, validation rules, toleranties, autorisaties, interfacecontrols, IT dependent controls…), en
  2. de IT general controls (Change Management, Security Management, …).

Deze twee soorten controls hebben een (in)directe relatie met de bedrijfsprocessen en worden vanuit de geïdentificeerde risico’s in de processen geselecteerd. Hierbij worden de application controls direct in de processen geïdentificeerd en zijn de ITGC gericht op de IT-componenten die de werking van deze application controls waarborgen. Deze relaties zijn in figuur 1 weergegeven.

C-2010-3-Francken-01

Figuur 1. Application controls en IT general controls en hun relatie met de bedrijfsprocessen.

De ITGC in scope hebben betrekking op de betreffende applicaties en de onderliggende IT-infrastructuur, zoals de database, het operatingsysteem en het netwerk. Deze IT-componenten ondersteunen de goede werking van de applicatiecontroles, die vanuit de bedrijfsprocessen zijn geselecteerd. Voor een goede beoordeling van de betrouwbaarheid van de applicaties en beveiliging van gegevens, is het van belang om de gehele keten en alle IT-componenten te overzien. Concreet voorbeeld: Binnen een ERP-applicatie kan de functiescheiding voldoende geborgd zijn. Indien de toegangsbeveiliging van de onderliggende database, bijvoorbeeld Oracle, niet op databaseniveau voldoende is geregeld maar men vertrouwt op de application controls, dan is het mogelijk dat gebruikers door middel van generieke applicaties zoals Microsoft Access of Excel toegang krijgen tot de database en deze zelfs kunnen muteren zonder de beperkingen van de ERP-applicatie.

Deze aanpak is niet nieuw, maar de samenhang tussen de componenten zou ons inziens meer integraal moeten worden opgepakt. Dit geldt ook indien er niet (of gedeeltelijk) wordt gesteund op de aanwezige controls en er meer gegevensgericht wordt gecontroleerd. Indien gebruik wordt gemaakt van datamining voor het beoordelen van verbanden in de bedrijfsprocessen, is het van groot belang dat deze analyses worden uitgevoerd op alle data (volledigheid) en dat deze data integer zijn. Dit betekent dat de toegangsbeveiliging op de diverse IT-componenten adequaat moet zijn, zodat data leakage en datamanipulatie kunnen worden beperkt. In het kader van de jaarrekeningcontrole is het daarnaast van belang dat voldoende aandacht wordt gegeven aan continuïteit, waar wij nu niet verder op in zullen gaan.

Access Governance

Zoals aangegeven dienen data-analyses te worden uitgevoerd op alle data en dienen deze data integer te zijn. Hierbij ligt de nadruk op een goede toegangsbeveiliging op de diverse IT-componenten. Dit kan worden vastgesteld door alle relevante beheersingsmaatregelen te beoordelen, zoals de application controls en de ITGC, maar dit kan ook door een meer geautomatiseerde aanpak. Hierbij maken wij onderscheid tussen Access Governance en Automated Security Review.

Wij definiëren Access Governance als een proces waarbij met behulp van analytische tooling toegang tot applicaties en IT-platformen periodiek wordt beoordeeld. Enkele kenmerken van Access Governance zijn:

  • correlatie en analyse van toegangsrechten op zowel netwerk-, database- als applicatielaag, alsmede tussen de verschillende lagen;
  • toegangsrechten kunnen worden verrijkt met HR en/of organisatiedata;
  • analyse op basis van voorgedefinieerde bedrijfsregels:
    • generieke bedrijfsregels: regels van toepassing op toegangsrechten van alle componenten die onderzocht worden,
    • applicatiespecifieke regels: regels van toepassing op toegangsrechten binnen de applicatie (vaak de vertaling van functiescheidingsregels);
  • off-lineanalyse, geen geautomatiseerde koppeling met de infrastructuur.

C-2010-3-Francken-02

Figuur 2. Het proces van Access Governance.

Deze aanpak (zie figuur 2) start met een voorbereidingsfase, waarin onder andere de relevante HR-data worden opgevraagd, alsmede de bedrijfsregels op het gebied van taken en verantwoordelijkheden. Op basis hiervan wordt inzicht verkregen wie wat zou mogen in de systemen. Vervolgens vindt er een validatie plaats van de ingerichte autorisaties op basis van specifieke verificatiesoftware, waarbij tevens wordt gekeken naar de mogelijkheden van de zogenaamde superusers. Ten slotte wordt hierover gerapporteerd aan het management.

Deze aanpak is in opzet niet anders dan voorheen, maar met behulp van de meest recente verificatiesoftware kan de daadwerkelijk ingerichte toegangsbeveiliging sneller en efficiënter worden verkregen, zonder de, normaal gesproken, handmatige verificatieslagen. Daarnaast helpt deze aanpak bij het verkrijgen van een volledig inzicht in alle ingerichte autorisaties over alle systemen, dus niet uitsluitend in één applicatie. Deze aanpak is dus op feiten gebaseerd (fact based) en heeft voor de auditor als voordeel dat:

  • er een beter overzicht aanwezig is van de daadwerkelijk ingerichte autorisaties, over alle systemen heen;
  • de belangrijkste functiescheiding sneller kan worden getest;
  • het uiteindelijke audit risk wordt gemitigeerd;
  • de rapportage concreter is dan voorheen, gebaseerd op feiten;
  • eventuele afwijkingen, ontstaan buiten de applicaties, eerder gesignaleerd kunnen worden.

De organisatie heeft er ook voordeel bij:

  • Ze krijgt gedetailleerd inzicht in de inrichting en werking van haar functiescheiding in de systemen.
  • Deze rapportages helpen om de interne beheersing verder te versterken en het bedrijfsrisico te verlagen.
  • De rapportage is specifiek en toegesneden.

De aanpak en planning ziet er op hoofdlijnen uit als weergegeven in figuur 3.

C-2010-3-Francken-03

Figuur 3. Access Governance: aanpak en planning. [Klik hier voor grotere afbeelding]

Access Governance is volgens ons noodzakelijk als randvoorwaarde om vervolgens met behulp van datamining verbanden te leggen en de bedrijfsprocessen te beoordelen. Met behulp van de huidige verificatiesoftware, zoals Aveksa, Bhold, Oracle en Sailpoint, kan dit efficiënter dan voorheen.

Enkele voorbeelden van concrete Access Governance reviews

Het eerste voorbeeld (zie figuur 4) betreft het analyseren van alle accounts van een applicatie met als doel te verifiëren of alleen personen die werkzaam zijn binnen de organisatie toegang hebben tot de applicatie.

C-2010-3-Francken-04

Figuur 4. Voorbeeld 1: het analyseren van alle accounts van een applicatie.

Deze review wordt uitgevoerd door het importeren van de accountdata van de applicatie alsook de HR-data met daarin alle medewerkers werkzaam voor deze organisatie. De verificatiesoftware zal op basis van de matching van de accountdata met de HR-data bepalen welke accounts niets voldoen aan dit policy-statement (bedrijfsregel). De accounts die niet voldoen aan deze regel zijn enerzijds ‘orphaned accounts’ (accounts van personen die niet meer werkzaam zijn) of anderzijds system accounts (niet-persoonlijke accounts).

Het tweede voorbeeld (zie figuur 5) betreft het analyseren van de fijnmazige toegangsrechten (authorisation data) van een bepaalde applicatie op basis van vooraf gedefinieerde bedrijfsregels, zoals die zijn vastgesteld in een autorisatiematrix. Op basis van de analyse zal een rapportage worden gegenereerd van alle personen (die gematcht worden op basis van accounts), waarvan de toegangsrechten niet in overeenstemming zijn met de gewenste rechten (‘Soll-Ist’ vergelijking).

C-2010-3-Francken-05

Figuur 5. Voorbeeld 2: het analyseren van fijnmazige toegangsrechten van een applicatie.

Het toepassen van Access Governance betekent ons inziens dat de ITGC, dat wil zeggen de procedures zoals wijzigingsprocedures en het toekennen van rechten in de systemen, niet langer afzonderlijk hoeven te worden beoordeeld door uitsluitend de beheersingsmaatregelen in de processen te beoordelen. Volgens ons kan de integriteit worden aangetoond door tevens datamining toe te passen op de ingerichte autorisatie op de diverse systemen en IT-platformen. Aangevuld met het geautomatiseerd beoordelen van de security baselines, kan zo voldoende audit evidence worden verkregen. Kortom, een efficiënte beoordeling door een mix van preventieve beheersingsmaatregelen en (detectieve) datamining.

Automated Security Review

Naast het beoordelen van de ingerichte toegangsbeveiliging over de applicaties heen, zal moeten worden vastgesteld dat de onderliggende IT-componenten, zoals de netwerk- en databasecomponenten, geen grote gaten bevatten. Indien er mogelijkheden zijn dat ongeautoriseerde personen van (buiten) de organisatie zelf toegang verkrijgen en/of gevoelige data kunnen zien/muteren, dan loopt de organisatie een risico op data leakage, fraude, privacyovertredingen, etc.

In navolging van het toepassen van dataminingtechnieken bij het beoordelen van de toegangsbeveiliging (Access Governance) zien we een dergelijke aanpak ook bij het beoordelen van de belangrijkste IT-beveiligingsrisico’s binnen de technische infrastructuur. Op basis van de relevante bedrijfsapplicaties en data in scope, wordt vastgesteld welke IT-componenten in scope zijn waar specifiek wordt gekeken naar configuratie-instellingen, zoals password settings, patch management, en monitoringparameters. Dit gebeurt door middel van audit scripts, fact based, waarbij de uitkomsten worden vergeleken met de geldende policies, waardoor een indruk wordt verkregen van de feitelijk geïmplementeerde ITGC. Door middel van ‘automated security testing’ wordt vastgesteld dat de gehele securityarchitectuur voldoende is, over de diverse IT-infrastructuurlagen heen, zoals de applicatie, database, netwerk, storage en middleware. Zeker in de huidige wereld met SOA-achtige oplossingen, virtualisatie, off site storage en bussen, is het van groot belang dat het gehele IT-landschap wordt beoordeeld. Alleen kijken naar de bedrijfsprocessen en -stromen, op basis van datamining, is ons inziens te beperkt. De risico’s daarbuiten zullen ook onderdeel van de totale scope moeten zijn van de auditor. Dit betekent niet dat alle IT-componenten dezelfde aandacht moeten krijgen, ook hier is een risicoaanpak van belang. Het gebruik van datamining om de daadwerkelijke inrichting van autorisaties, over de applicaties heen, en de beveiligingsinstellingen te beoordelen, maakt het mogelijk op een efficiënte wijze toch de vereiste zekerheid en toegevoegde waarde te realiseren.

Samenvattend zien we hier een duidelijke afhankelijkheid om naast de data-analyse op de processen, eveneens vast te stellen wat men binnen de gehele (relevante) IT-infrastructuur kan en heeft gedaan, op het gebied van toegangsbeveiliging. De samenhang tussen de processen (Facts to Value) en de beveiliging van de relevante infrastructuur (Access Governance en Automated Security Review) zal ons inziens moeten worden beoordeeld, waarbij zowel ‘did do’ (wat heeft men daadwerkelijk gedaan in de systemen, data-analyse) en ‘can do’ (wat kan men, instellingen) relevant zijn.

C-2010-3-Francken-06

Figuur 6. Het proces in samenhang weergegeven.

Conclusie

In de huidige aanpak van de jaarrekeningcontrole kan men niet om de IT-systemen heen, dat is inmiddels wel duidelijk. Dat de aanpak efficiënter en effectiever kan, is ook duidelijk. Zo zien we een tendens richting ‘fact finding’-achtige oplossingen met behulp van diverse tooling. Deze aanpak lijkt zich voornamelijk te richten op het aantonen van verbanden in de bedrijfsprocessen en onderliggende datastromen en minder op de risico’s in het gehele IT-landschap en onderliggende IT-platformen. Dat is ons inziens niet terecht. De integriteit van de data is een belangrijke randvoorwaarde, voordat überhaupt een conclusie kan worden getrokken over deze data. Met behulp van dataminingtechnieken kan de daadwerkelijke inrichting van de toegangsbeveiliging worden beoordeeld over de diverse applicaties en IT-platformen heen (Access Governance) en kan worden aangetoond dat de onderliggende IT-infrastructuur geen relevante zwakheden kent waardoor derden alsnog ongeautoriseerd data kunnen zien en/of wijzigen. Naast Facts to Value is er ook een duidelijke behoefte en noodzaak om de geïmplementeerde toegangsbeveiliging en security settings te beoordelen. Alleen zo kan daadwerkelijk worden aangetoond wie welke transactie heeft uitgevoerd in de betreffende geautomatiseerde bedrijfsprocessen.

Literatuur

[Tole10] Drs. Peter van Toledo RE RA, drs. Gideon Lamberiks RE en Quintra Rijnders MSc RA, Facts to Value, data omzetten in toegevoegde waarde, Compact 2010/1.