Inleiding

Een belangrijke bevinding uit een onderzoek van KPMG LLP naar de ontwikkelingen in ‘SOx-compliancy’ in 2007 ([KPMG07]) was dat het integreren van ‘enterprise risk management’ met de risicoassessmentactiviteiten voor SOx als één van de top vijf strategische issues wordt aangemerkt. Een integratie van SOx met het ORM-framework zou hieraan kunnen bijdragen. Zowel de SOx-regelgeving als het Basel II-Akkoord bevat eisen voor risicomanagement van banken. De scope van zowel ORM (als onderdeel van Basel II) als SOx betreft in principe een gehele bank en bovendien zijn de activiteiten van beide gericht op procesbeheersing.

In de praktijk zien wij dat er bij de implementatie van ORM beperkt gekeken wordt naar de mate waarin Basel II-initiatieven kunnen aansluiten bij de reeds geïmplementeerde SOx-elementen.

Dit artikel geeft een overzicht van de mate waarin SOx en ORM elkaar overlappen. Hiertoe is gekeken naar business planning en scoping, governance, het controlsraamwerk en de mogelijke (ondersteunende) IT-tooling. Het doel van het artikel is aan te geven waar efficiencyvoordelen kunnen worden behaald door inspanningen voor beide regelgevingen te combineren.

ORM-kader

Operationeel risico is één van de risicocategorieën die in het Basel II-Akkoord ([BIS06]) van de Bank for International Settlements (BIS) wordt onderkend. In Nederland is het Basel II-Akkoord van kracht sinds januari 2007 en is dit verankerd in de Wft (Wet financieel toezicht). Afhankelijk van de aanpak wat betreft operationeel risicomanagement geeft het Basel II-Akkoord meer of minder stringente kwalitatieve en kwantitatieve eisen en richtlijnen voor ORM. De voornaamste kwalitatieve eisen zijn beschreven in de ‘Sound practices for operational risk management’ ([BIS03]). Een raamwerk dat aan deze ‘sound practices’ en de overige Basel II-eisen invulling geeft, is weergegeven in figuur 1.

Figuur 1. ORM-raamwerk.

De driehoek in het ORM-raamwerk geeft aan welke bouwstenen aanwezig moeten zijn om ORM in een organisatie in te bedden:

• risicostrategie: de strategie die de basis is voor alle andere componenten en dient aan te geven wat wel en niet als risico wordt geaccepteerd;
• organisatiestructuur: de rollen en verantwoordelijkheden;
• rapportage: de gewenste managementinformatie en benodigde externe rapportage;
• definities en structuren: de taxonomie en structuur voor de elementen van ORM;
• loss data: (het proces voor het verzamelen en analyseren van) data van operationele verliezen;
• risicoanalyse: een kwalitatieve analyse van de bestaande risico’s binnen de organisatie (met behulp van zogenoemde risico (en control) selfassessments);
• key risk indicators: ‘early warning’-signalen die een verhoogde kans op het optreden van een verlies signaleren;
• mitigeren: maatregelen om bestaande, ongewenste risico’s te mitigeren;
• kapitaalberekening: berekening van het benodigde kapitaal om operationele risico’s te kunnen opvangen;
• informatietechnologie: IT-systemen die ORM-activiteiten ondersteunen.

De cyclus rond deze elementen geeft aan dat ORM geen statisch, maar een continu proces is. Het inbedden van deze cyclus in de bedrijfsprocessen is een belangrijke maatstaf voor het slagen van ORM in een organisatie.

SOx-kader

De Sarbanes Oxley Act (SOx) is in 2004 in werking getreden en is van toepassing op alle aan de New York Stock Exchange genoteerde bedrijven. Sinds 2006 dienen ook niet-US-bedrijven aan de vereisten voortkomende uit deze Act te voldoen ([SOx07]).

SOx heeft een groot aantal consequenties voor bedrijven, waarvan de belangrijkste zijn vastgelegd in secties 302 en 404. Sectie 302 schrijft voor dat management verantwoordelijk is voor het vaststellen en onderhouden van ‘internal control’. Het ontwerp van een dergelijk ‘internal control framework’ dient een redelijke mate van zekerheid te verschaffen omtrent de betrouwbaarheid van de externe financiële verslaggeving.

In sectie 404 is vastgelegd dat de CEO en CFO een verklaring dienen af te geven waarin het topmanagement verklaart verantwoordelijk te zijn voor het creëren en vaststellen van een adequaat framework van internal controls. In deze verklaring dient tevens een beschrijving van dit framework te zijn opgenomen. Indien één of meer ‘material weaknesses’ in dit raamwerk zijn gedetecteerd, dan mag het topmanagement niet verklaren dat de internal controls effectief zijn.

Tevens dient een verklaring van de externe accountant te worden opgenomen in het jaarverslag omtrent de effectiviteit van het internal control framework.

Business planning en scope

Operationeel risicomanagement is erop gericht het risico op operationele verliezen als gevolg van inadequaat of foutief menselijk handelen, van tekortkomingen in interne processen of systemen of van externe gebeurtenissen te verkleinen tot het niveau dat de bank (en de toezichthouder) als acceptabel beschouwt. Verliezen worden gegenereerd door incidenten. Deze incidenten zijn door de BIS en DNB in zeven categorieën ingedeeld (zie tabel 1).

Tabel 1. Categorieën incidenten. [Klik hier voor grotere afbeelding]

Incidenten die leiden tot deze operationele verliezen zijn onder andere interne en externe fraude. SOx is primair gericht op het voorkomen van deze fraude en ‘safeguarding of assets’. Door het implementeren van sterke internal controls dient fraude te worden gedetecteerd en voorkomen, om zo materiële ‘misstatements’ in de financiële verslaggeving te voorkomen. Standard No. 5 ([PCAO07]), die de voormalige Auditing Standard No. 2 sinds mei 2007 vervangt, legt bovendien extra nadruk op frauderisico en ‘anti-fraud controls’. De overige incidentencategorieën zijn niet van specifiek belang vanuit SOx-oogpunt, mits deze verliezen correct financieel worden verantwoord. SOx beperkt zich immers tot de beheersing van processen, vanuit het oogpunt van correcte financiële verslaggeving. Dit betekent dat de processen, risico’s en controls die betrekking hebben op de juistheid, tijdigheid en volledigheid van de financiële rapportage, binnen de SOx-scope vallen. Om de precieze scope te bepalen wordt gebruikgemaakt van het materialiteitsprincipe. Alleen de processen van die organisatieonderdelen die een materiële bijdrage leveren aan de geconsolideerde cijfers van de bank, vallen hierbinnen. Het zijn immers ook deze processen die bij falende internal control kunnen leiden tot een ‘material misstatement’. Omdat het niet voldoen aan SOx kan leiden tot additionele kosten (verliezen) en reputatieschade (een ‘niet financieel (ORM) verlies’), vallen SOx en de hiermee samenhangende controls binnen de scope van ORM.

Ook ORM heeft betrekking op alle processen en onderdelen van een organisatie. In elk proces kunnen immers als gevolg van fouten in systemen, processen, menselijk handelen of als gevolg van externe omstandigheden, verliezen optreden.[Vanuit Basel II vindt er ook scoping plaats. Hierdoor kunnen processen van organisatieonderdelen die niet binnen de scope van Basel II vallen, ook buiten de scope van ORM vallen. De toezichthouder kan om argumenten vragen waarmee wordt aangetoond dat het ‘outscopen’ van deze activiteiten geen onjuiste weergave van het risicoprofiel van de organisatie tot gevolg heeft.] De focus van ORM wordt in eerste instantie bepaald door de risicostrategie van het management. In tegenstelling tot SOx, waarin wordt voorgeschreven dat geen material misstatements mogen voorkomen, mag er vanuit Basel II een bepaalde mate van operational risk (OR) bestaan. Een organisatie hoeft en kan niet honderd procent in control zijn zolang het (operationele) risicoprofiel in overeenstemming is met de ‘risk appetite’ en ambitie van de bank en er voldoende kapitaal wordt aangehouden om de verwachte en onverwachte operationele verliezen op te kunnen vangen. Deze link tussen operationeel risico en kapitaal is een significant verschil tussen de SOx- en Basel II-vereisten; ORM, als één van de risicogebieden binnen het Basel II-Akkoord, bepaalt mede de hoogte van het kapitaalsbeslag vanuit solvabiliteitsoogpunt. Naast kwalitatieve eisen die vergeleken kunnen worden met de SOx-vereisten, worden er daarom ook kwantitatieve eisen aan ORM gesteld. In de meest geavanceerde benadering voor ORM bestaat er een directe link tussen het (operationele) risicoprofiel van een bank en de hoogte van het aan te houden kapitaal voor ORM. Deze link tussen risicoprofiel en kapitaal is een ‘incentive’ voor het management om een optimale balans te vinden tussen ‘risk’ en ‘reward’ en zo ‘return on capital’ te maximaliseren. In de praktijk vindt hiertoe allocatie van OR-kapitaal plaats naar organisatieonderdelen. Voor SOx wordt alleen de impact van niet-werkende controls gekwantificeerd om zo te kunnen bepalen in hoeverre er sprake is van een material misstatement. In tabel 2 wordt een overzicht van de scope en doelstellingen van ORM en SOx gegeven.

Tabel 2. Scope en doelstellingen ORM en SOx. [Klik hier voor grotere afbeelding]

Governance

SOx stelt het bestuur van een bedrijf (CEO en CFO) hoofdelijk aansprakelijk voor het inrichten van een internal control framework en het afleggen van een verklaring omtrent de werking van dit framework. Indien deze verklaring onjuist blijkt te zijn en er materiële misstatements in de jaarrekening voorkomen, dan zijn geldelijke boetes en een maximale gevangenisstraf van twintig jaar de consequentie.

In de ‘sound practices’ voor ORM ([BIS03]) wordt ook het bestuur van een bank verantwoordelijk gesteld voor de implementatie van een ORM-raamwerk. Er is geen sprake van een hoofdelijke aansprakelijkheid, noch dient dit vastgelegd te worden in een verklaring. Net zoals bij SOx is de lijnorganisatie verantwoordelijk voor een juiste implementatie van ORM. Lijnmanagement is verantwoordelijk voor de identificatie van operationele risico’s en de implementatie van adequate maatregelen om deze te mitigeren in lijn met de ‘risk appetite’ van de bank. Daarnaast wordt in de ‘sound practices’ voorgeschreven dat ‘Internal Audit’ een rol dient te spelen in de inhoudelijke toetsing van het ORM-raamwerk. Een verdeling van verantwoordelijkheden zoals die in de praktijk wordt toegepast, is belichaamd in het zogenaamde ‘three lines of defence’-model, zoals weergegeven in figuur 2.

Figuur 2. Three lines of defence.

Voor ORM en SOx dienen taken en verantwoordelijkheden te worden belegd op het niveau waar de risico’s bestaan en de ‘controls’ worden uitgevoerd.

In de praktijk wordt het management in zijn activiteiten ondersteund door afdelingen die gespecialiseerd zijn in ORM of SOx. Operational risk managers ondersteunen het management in de identificatie, monitoring en evaluatie van operationele risico’s. Daarnaast zien wij dat Internal Audit het management vaak ondersteunt bij de test- en documentatieactiviteiten voor SOx. Bij verschillende banken is dit echter ook bij de ORM-functie belegd.

Toezicht

Het toezicht op SOx-compliancy wordt uitgevoerd door de externe auditor. Deze diende onder PCAOB Auditing Standard No. 2 twee SOx-verklaringen af te geven; één betreffende management assessment en een verklaring gebaseerd op eigen testwerk. Met de introductie van Auditing Standard No. 5 in mei 2007 is de eerste vereiste verdwenen; de auditor dient alleen een eigen verklaring af te geven. De PCAOB voert toezicht uit op de wijze waarop de externe accountant de testwerkzaamheden verricht en tot een oordeel is gekomen.

De externe auditor zal bij ORM focussen op de juistheid van de kapitaalberekeningen en hiertoe de eventueel gebruikte modellen valideren. In hoeverre er voldoende adequate maatregelen getroffen zijn om de operationele risico’s te mitigeren, is voor de externe auditor niet van belang, zolang de geleden operationele verliezen juist tot uitdrukking komen in de jaarrekening. De input hiervoor komt voort uit het geïmplementeerde ORM-raamwerk, maar dit raamwerk zelf is in principe geen onderdeel van de externe audit. Het toezicht op de implementatie van een ORM-raamwerk wordt in Nederland gevoerd door DNB. In tabel 3 worden de verschillende verantwoordelijkheden binnen ORM en SOx samengevat weergegeven.

Tabel 3. Verantwoordelijkheden ORM en SOx. [Klik hier voor grotere afbeelding]

Controlsraamwerk

De verklaring die het management aflegt voor SOx dient ondersteund te worden door de resultaten van testwerk, waarmee is aangetoond dat de benodigde controls effectief zijn. Dit testwerk plus de daarbij behorende documentatie van de resultaten is niet expliciet voorgeschreven voor ORM; door gebruik te maken van risk (and control) selfassessments, het gebruik van key risk indicators en een loss database verkrijgt het management inzicht in het bestaande risicoprofiel en kan zo identificeren of actie is gewenst.

Documentatie van deze activiteiten is gewenst om interne en externe belanghebbenden op de hoogte te kunnen stellen van de kwaliteit van ORM, maar er bestaat een grote mate van subjectiviteit, die bij SOx niet bestaat.

SOx beveelt het COSO-framework (opgesteld door het Committee of Sponsoring Organisations of the Treadway Commission) aan als geschikt internal control framework. Controls kunnen worden ingedeeld conform de vijf onderdelen van dit raamwerk: monitoring, information & communication, risk assessment, control activities en control environment. Het COSO-raamwerk heeft weinig verankering in de ORM-wereld. Operationele risico’s en controls worden in het algemeen niet conform COSO geclassificeerd. De ORM-controls worden ingedeeld op basis van de oorzaak (processen, mensen, systemen of externe omstandigheden) van het onderliggende risico en de gebeurtenis (zie tabel 1) die zij (proberen te) mitigeren (in figuur 3 zijn de componenten van een operationeel risico weergegeven).

Figuur 3. De definitie van operationele risico’s.

In 2005 is een nieuwe versie van het COSO-raamwerk uitgegeven, het ‘Enterprise Risk Management Framework’ (zie figuur 4) ([COSO05]). Dit raamwerk heeft meerdere lagen, waarbij meer aandacht wordt besteed aan risk assessment en de afstemming tussen de doelen van een organisatie en het daarbij behorende risicoprofiel. Deze aanpak en de aandacht voor de effectiviteit en efficiency van de bedrijfsvoering sluiten goed aan bij de opzet en doelstellingen van ORM. Het raamwerk koppelt de (risk management) strategie van een organisatie met de bestaande risico’s en controls van de bank en neemt tevens externe factoren (events) mee in de bepaling van deze risico’s.

Figuur 4. Enterprise Risk Management Framework.

Het Basel II-Akkoord stelt geen eisen aan de wijze waarop risico’s en controls dienen te worden gedocumenteerd. Indien er gebruik wordt gemaakt van een loss database, wordt er wel per operationeel verlies een classificatie naar ‘business line’ en ‘event category’ (zie tabel 1) verwacht.

Ook vanuit SOx is het van belang om op een adequate wijze te documenteren. Denk hierbij aan het documenteren van de processen/procedures en daarbinnen de ‘key controls’ en risico’s, de vastlegging van het uitgevoerde testwerk, het vastleggen van informatie over de wijze waarop transacties worden geïnitieerd, goedgekeurd, vastgelegd, verwerkt en gerapporteerd, etc. Om hieraan te voldoen is het aan te bevelen controls volgens een vaste indeling te documenteren. Deze indeling zou ook binnen ORM kunnen worden toegepast als richtlijn voor de ‘controls-documentatie’ (zie tabel 4) om zo de kwaliteit van de risicodocumentatie te verbeteren.

Tabel 4. Indeling controlsdocumentatie.

Uit de documentatie moet zowel de opzet en het bestaan (Test Of Design) blijken, als de effectieve werking van een control (Test of Operating Effectiveness). Binnen Basel II wordt dit onderscheid niet gemaakt. Aangezien van het management verwacht wordt dat het de bestaande risico’s mitigeert, zal de focus liggen op het bestaan en de werking van controls.

IT-controls

Veel banken hanteren naast het eerdergenoemde COSO-raamwerk het Cobit-framework (Control Objectives for IT) om specifieke invulling te geven aan de IT-controls binnen de organisatie ([ITGI06]). Dit raamwerk geeft zowel invulling aan de SOx-vereisten als aan de ORM-wensen. ORM-vereisten kunnen rechtstreeks uit SLA’s worden afgeleid. De SLA zou immers het resultaat moeten zijn van een kosten-batenanalyse waarbij de kosten van additionele zekerheid zijn afgewogen tegen de (directe of indirecte) opbrengsten van hogere service levels.

SOx hecht groot belang aan de IT general controls. In een geautomatiseerde omgeving kan immers niet automatisch op application controls worden gesteund, wanneer de IT general controls niet effectief zijn. Deze specifieke aandacht voor IT general controls bestaat niet binnen ORM. Dit betekent echter niet dat er niet eenzelfde afhankelijkheid bestaat van IT general controls en er daarom ook binnen ORM voldoende aandacht aan moet worden besteed.

Een verschil tussen ORM en SOx is dat de beschikbaarheid van systemen bij ORM meer aandacht krijgt dan onder SOx. Vanuit het oogpunt van de juistheid van de financiële verslaglegging is het key dat de gegevens juist, tijdig en volledig worden aangeleverd, maar ten aanzien van de manier waarop – handmatig of geautomatiseerd –, is er geen directe eis. Vanuit efficiency- en effectiviteitsoogpunt zal ORM veel belang hechten aan de beschikbaarheid van systemen.

Voor wat betreft application controls geldt dat hier in beide gevallen aandacht aan wordt besteed, vanwege de mogelijkheid van fouten in deze controls. SOx zal zich hierbij focussen op de application controls die de financiële verslaggeving beïnvloeden en ORM op de controls die de prestaties van de bank mede bepalen. De controls vanuit SOx-oogpunt zullen ook binnen ORM belangrijk worden geacht, aangezien het voorkomen van sancties van de toezichthouder ook onder de ORM-doelstellingen valt.

Tabel 5. Raamwerk controls. [Klik hier voor grotere afbeelding]

IT-tooling

Het gebruik van bedrijfsbrede informatiesystemen ten behoeve van de (eenmalige) vastlegging van risico’s en ‘controls’ op verschillende niveaus binnen een bank, ondersteunt in het (zichtbaar) voldoen aan ORM- en SOx-vereisten.

Vanwege de documentatievereiste voor SOx, is het verstandig een zo efficiënt mogelijke wijze van vastlegging te hanteren, waarmee niet alleen de ‘controls’ worden vastgelegd, maar waarmee tevens evaluatie en rapportage van de effectiviteit van de ‘controls’ wordt ondersteund ([Brou03]). Veel organisaties gebruiken een specifieke applicatie voor het vastleggen van hun internecontroleraamwerk, hun testactiviteiten, en de uitkomsten daarvan. Voorbeelden hiervan zijn BWise, Risk Navigator en SAP MIC. Tegelijkertijd zien we dat bedrijven Excel gebruiken voor hun rapportages en de ondersteunende ‘evidence’ hardcopy opslaan. Ditzelfde geldt voor ORM.

Ondanks dat er systemen in de markt bestaan voor de ondersteuning van zowel SOx- als ORM-activiteiten, zijn in de praktijk meestal twee aparte applicaties (en werkwijzen) geïmplementeerd. Tabel 6 geeft weer welke activiteiten door een applicatie kunnen worden ondersteund en in hoeverre de functionaliteit van toepassing is op SOx- of ORM-activiteiten of op beide.

Tabel 6. Overlap functionaliteiten. [Klik hier voor grotere afbeelding]

Hoe de overlap te benutten?

Uit het voorgaande blijkt dat, ondanks het feit dat de ‘incentives’ voor SOx en ORM compleet verschillend zijn, de ORM- en SOx-activiteiten en -verantwoordelijkheden voldoende gelijkenis vertonen om te kunnen profiteren van de overlap. Vanwege de beperktere scope van SOx, ten opzichte van ORM, heeft het onze voorkeur om de SOx-activiteiten zo veel mogelijk binnen de ORM-activiteiten te verankeren. Het bepalen, documenteren en testen van SOx-controls kan een plaats krijgen binnen de activiteiten die ORM uitvoert om operationele risico’s te identificeren, analyseren, monitoren en mitigeren. Hierbij dient gegarandeerd te worden dat er geen concessies worden gedaan aan de SOx-vereisten ten aanzien van documentatie en testwerk en dient een ‘risk appetite’ van (nagenoeg) nul te worden gehanteerd voor de SOx-gerelateerde risico’s en controls. Door duidelijk aan te geven welke risico’s en controls voor SOx van belang zijn, hoeven deze niet nogmaals vanuit ORM-oogpunt onder de loep te worden genomen en wordt voorkomen dat de stringente(re) SOx-vereisten op ORM-risico’s en controls worden toegepast. Een IT-tool kan ondersteuning bieden bij het integreren van de activiteiten door eenmalige vastlegging en het duidelijk vastleggen van de doelstelling van gedocumenteerde risico’s en controls (SOx en/of ORM).