SOX EN HET BELANG VAN DE IT-CONTROLS

&

FINANCE

CONTROL

Informatiemanagement

SOX EN HET BELANG VAN DE IT-CONTROLS Binnen de SOX-verslaggeving is de verantwoordelijkheid voor de IT-controls lang niet altijd even duidelijk. In de term ‘IT controls’ lijkt een organisatorische tegenstrijdigheid verscholen. Een afdeling Operational Risk Management is genegen te kijken naar het eerste deel, namelijk ‘IT’ en trekt de conclusie ‘het hoort thuis bij ICT’. De ICT-afdeling is echter genegen te kijken naar het tweede deel ‘controls’ en trekt de conclusie ‘nee hoor, het hoort thuis bij de afdeling Operational Risk Management’. Zo is er nog niet zoveel gebeurd.

D O O R CO R RO O D H O R ST

P

er 2006 staat SOX op de agenda als externe verslaggevingsplicht voor alle Amerikaanse beursgenoteerde ondernemingen. Met het bepalen van de ‘significant accounts’, de proceshiërarchie, de risico’s en de risicobeheersingsmaatregelen wordt inhoud gegeven aan de SOXverslaggevingsplicht. IT-controls vormen een essentieel onderdeel van het dossier, aangezien vrijwel alle cijfers vandaag de dag vanuit softwaresystemen worden aangeleverd. De IT-controls worden vaak niet als het meest eenvoudige onderdeel ervaren binnen de SOX-verslaggeving. In dit artikel wordt uitgelegd waarom dit zo is. Vervolgens wordt een richting aangeboden hoe dit onderdeel in te richten. Eerst volgt een korte toelichting op het belang van de IT-controls in het SOX-dossier. IT en de betrouwbaarheid van de cijfers In de gedachte van SOX staat het presenteren van betrouwbare cijfers centraal. De vanuit de ‘significant accounts’ benoemde administratieve processen dienen gevrijwaard te zijn van risico’s. Er dienen tenminste risicobeheersingsmaatregelen gedefinieerd te zijn waarmee die risico’s beperkt worden om zo betrouwbare informatie te leveren. De IT-component kan niet uitgesloten worden, aangezien vrijwel alle cijfers gegene-

reerd worden door softwaresystemen. Indien deze applicatiecontroles niet bestaan of de automatische verwerking niet of onvoldoende plaatsvindt, kan per definitie getwijfeld worden aan de betrouwbaarheid van de cijfers ondanks uitstekend georganiseerde (financieel) administratieve processen. Onvoldoende beveiliging van de data en onvoldoende inzicht in de controls van de geautomatiseerde gegevensverwerking binnen een systeem maken de IT-control tot een blinde vlek in het SOX-dossier. Wat maakt IT-controls een moeilijk onderdeel? De IT-controls bestaan in de SOX-verslaglegging uit twee delen en voor beide delen geldt dat ze minder makkelijk te koppelen zijn aan de administratieve processen. Te beginnen met de general IT-controls waar de beveiliging van de gegevens centraal staat. In dit geval is de relatie tussen processen en de controls vaak niet meer direct te leggen. De algemene toegangsbeveiliging van een systeem is bijvoorbeeld niet aan één proces te koppelen. Het tweede onderdeel betreft de application controls. In dit geval zijn de relaties beter te leggen omdat de processen centraal staan, maar ook dan nog is niet altijd even duidelijk wat er achter de schermen van de eindgebruikers gebeurt.

FEBRUARI 2006

|

35

W W W. K L U W E R F I N A N C I E E L M A N A G E M E N T. N L

&

FINANCE

Systemen worden immers vaak gezien als ‘black boxes’ waardoor de afbakening van het gebied ‘waar begint een risico en waar houdt het op’ niet eenvoudig is. De vraag zal ontstaan wie binnen de organisatie dit moet weten. In feite begint hier het organisatorische vraagstuk van de IT-controls. Wie is verantwoordelijk voor dit onderdeel in de organisatie? Is dat een afdeling Operational Risk Management (ORM) of is dat een afdeling ICT? Nog moeilijker wordt het wanneer het gaat om oudere systemen waarvan niemand in de organisatie echt kan garanderen hoe het daadwerkelijk zit. Deze situatie gaat nogal eens vergezeld met niet aanwezige of gedateerde beheersdocumentatie. Bij oudere systemen is vaak de documentatiediscipline verzwakt of zonder samenhang gefragmenteerd over de organisatie. Bovendien is de documentatie nogal eens moeilijk toegankelijk voor andere expertisen dan ICT, hetgeen het voor een afdeling Operational Risk Management weer moeilijk te begrijpen maakt hoe een systeem op hoofdlijnen werkt. Dat vergroot het probleem van de communicatie tussen ICT en Operational Risk Management aanzienlijk. De afdelingen

CONTROL

spreken elkaars taal niet en de samenwerking wordt daardoor bemoeilijkt. Een bron van wederzijds onbegrip ontstaat. Voorwaarden inrichten IT-controls SOX Voor de ontwikkeling van de IT-controls moet aan ten minste een drietal noodzakelijke voorwaarden worden voldaan. De eerste voorwaarde betreft de officiële toewijzing van de gezamenlijk taakopdracht voor dit onderdeel. Het meest logische is de combinatie van een afdeling Operational Risk Management (ORM) en een ICT-afdeling. Maar net zo belangrijk is de samenwerking met een groep geselecteerde kundige eindgebruikers. De twee expertisen vullen elkaar aan en de gebruikers kennen de systemen vanuit hun processen. De afdeling ORM kan in samenwerking met de afdeling ICT de betrokkenheid van de systemen in de processen bepalen, waarna gebruikers de risico’s kunnen benoemen in samenwerking met de afdeling ORM. Het is noodzakelijk dat de samenwerking bekrachtigd wordt vanuit het MT. Een vrijwillige samenwerking zal al snel door herprioritering van de dagelijkse werk-

Figuur 1 Relatie tussen systeem en omgeving Logische toegangsbeveiliging

1

2 Door het systeem gegenereerde controlelijsten, gedefinieerde systeemcontroles

Satellietsystemen

3 Operation Controls (voorbeelden: afgedwongen fiattering, afgedwongen volledige invoer afgedwongen controles

Systeemdocumentatie

Logische toegangsbeveiliging

36

|

FEBRUARI 2006

Change Management System maintenance



Verbandscontroles tussen systeemmodules en controlelijsten

&

FINANCE

zaamheden uitmonden in een teruglopend contact. Overigens gaat het hier om de aanpak van de IT-controls en dus niet om de toewijzing van de proceseigenaren. Een tweede voorwaarde betreft de ontwikkeling van één taal tussen de twee hierboven genoemde afdelingen (ORM en ICT) en de eindgebruikers. Concrete voorbeelden die hier genoemd worden zijn (sub-)systeemcodelijsten, jobcodelijsten, batchcodelijsten, foutverslagenlijsten, mutatiecodes, schermcodes, boekingscodes maar ook functieprofielen vertaald in bevoegdheden binnen het systeem. Op deze lijsten dient per code een korte omschrijving opgenomen te zijn. De risicobeheersingsmaatregelen en tests kunnen aanzienlijk concreter gedefinieerd worden indien met deze codes gewerkt wordt. Gebruikers van de systemen maken namelijk vaak gebruik van dit soort codes. Het gebruik van deze codes zal daarom de tests sneller herkenbaar doen zijn. Een derde voorwaarde betreft een gemeenschappelijke transparante dossierstructuur die voorziet in de koppeling tussen de afdelingen ORM en ICT, maar die ook makkelijk begrepen kan worden door de organisatie. In die structuur dienen de operationele, tactische en strategische managementniveaus herkenbaar te zijn om zo de processen en de samenhang ertussen in kaart te brengen. Met de rangschikking van de processen wordt het interne controle framework (ICFR) opgesteld, dat een logische opbouw kent van gegevensverwerking naar de consolidatie ervan. Daarmee ontstaat inzicht in de relatie tussen de invoer en verwerking van data en de rapportage. Zowel de key controls als de tests zijn aan de structuur op te hangen en zijn makkelijker uit te leggen aan de eindgebruikers, maar ook aan auditors en de accountants. Een ander voordeel betreft de inperking van het aantal controls. Binnen een dergelijke structuur is het beter mogelijk de samenhang met het grootboek (de significant accounts) en de relevantie van de SOX-processen te bepalen. Structuur van de SOX IT-controls Met figuur 1 als leidraad wordt een zevenstappenplan aangeboden voor het opzetten van de application controls. Daaraan vooraf zal allereerst de opzet van de door figuur 1 vertegenwoordigde structuur uitgelegd worden. Van belang daarbij is het onderscheid tussen het systeem en de omgeving ervan. Het systeem wordt weergegeven door de informatiepiramide (zie kader 1). De betrouwbaarheid van de door het systeem geleverde (financiële) informatie is ook afhankelijk van de omgevingsfactoren van het systeem. Hier gaat het in feite om elementen die onder de general IT-controls vallen. Hoewel dit aspect hier summier besproken wordt en dus verder niet behandeld wordt, dient toch gerealiseerd te worden dat de application controls op dit punt afhankelijk blijven van de effectiviteit van de risicobeheersingsmaatregelen op dit

CONTROL

1 De omgeving van het systeem Logische toegangsbeveiliging. De buitenste cirkel van figuur 1 betreft de toegangsbeveiliging. Het gaat hier bijvoorbeeld om het voorkomen van ongeautoriseerde toegang tot de ruimten en de systemen. Het voorkomen ervan is een minimaal noodzakelijk in te vullen randvoorwaarde voor de betrouwbaarheid van de informatie. Satellietsystemen. Naast het primaire systeem wordt nogal eens gebruik gemaakt van hulpapplicaties die bijvoorbeeld met het downloaden van gegevens een rekenfunctionaliteit kennen die niet in het primaire systeem zijn opgenomen. Hoewel de functionaliteit van de hulpapplicaties dan buiten het primaire systeem valt, houdt dit nog niet in dat deze buiten de scope van de SOX-verslaggeving valt. Dit is zeker het geval wanneer het satellietsysteem de data na de download bewerkt en vervolgens weer als upload aanbiedt aan het primaire systeem. Changemanagement/system maintenance. Veranderingen in het systeem dienen altijd geborgd te zijn door een goed ingerichte testorganisatie. Een onafhankelijke representatieve testomgeving, een risicoanalyse en testplannen zijn de minimaal in te vullen voorwaarden. Systeemdocumentatie. Een niet onbelangrijk aspect van het systeem is de systeemdocumentatie. Indien wijzigingen optreden is het van belang deze in de daarvoor bestemde beheersdocumentatie vast te leggen. Vaak is er veel aanwezig maar nooit of onvoldoende onderhouden.

vlak. Factoren als de logische toegangsbeveiliging, changemanagement en systeemdocumentatie en satellietsystemen kunnen zich voor alle drie de managementniveaus van het systeem voordoen. Daarom is dit in figuur 1 als een ronddraaiend geheel opgenomen. Om een voorbeeld te noemen: of systeemveranderingen nu plaatsvinden in een systeemmodule voor de operationele gegevensverwerking (informatieniveau 3) of dat dit gebeurt in een module op het niveau van de gegevensconsolidatie (informatieniveau 1) maakt voor de betrouwbaarheid van de financiële informatie op zich evenveel uit. Systeemwijzigingen dienen altijd plaats te vinden in een goed georganiseerd changemanagementproces. Hetzelfde geldt dus ook voor zaken als satellietsystemen en de systeemdocumentatie. Terug naar het systeem zelf. Voor het systeem zelf wordt uitgegaan van de informatiepiramide met de drie regelkringniveaus en de daarbij behorende managementinformatieniveaus (zie kader 2) Voor de beschrijving van de structuur wordt hier gekozen voor een bottum-upbenadering dus vanaf mutatieniveau naar consolidatieniveau. De logica hierachter is dat een betrouwbare informatievoorziening begint bij de zuiverheid van de brondata. Er wordt in dit geval van uitgegaan dat er één systeem gebruikt wordt dat bestaat uit diverse modules. Het systeem

FEBRUARI 2006

|

37


&

FINANCE

2 Het systeem 1 Operaties. Elke module is een geautomatiseerde ondersteuning

CONTROL

wordt er ook hier vanuit gegaan dat gewerkt wordt met één systeem, bestaande uit diverse modules.

van diverse administratieve processen door de invoer van gegevens, de geautomatiseerde verwerking ervan en de beschikbaarstelling van informatie. Dit niveau is dus vooral het gegevensmutatieniveau. De application controles op dit niveau zijn dus mutatiegerelateerd. Het kan gaan om systeemafgedwongen fiattering, controle op volledigheid invoer, systeemafgedwongen invoercontrole door een tweede medewerker, maar bijvoorbeeld ook het afgedwongen gebruik van geprogrammeerde boekingssoorten. Een ander voorbeeld hiervan is een overboekinglimiet op een rekening-

1 Inventariseer de relevante SOX-processen. In feite is deze stap binnen het SOX-traject een van de eerste uit te voeren stappen nadat de significant accounts bepaald zijn. Het betreft de account/proces mapping waarmee een koppeling gelegd wordt tussen materiële onderdelen van de financiële verslaggeving en de processen die daar een significante invloed op hebben. Vooraf dienen vanzelfsprekend de materialiteitscriteria gesteld te zijn.

courant. Met dit soort controles op operationeel niveau begint de betrouwbaarheid van de verslaggeving. 2 Controlelijsten. Door iedere module wordt doorgaans een hoeveelheid controlelijsten gegenereerd die óf direct gebruikt worden tijdens de operationele processen (mutatielijsten), óf na indikking van de gegevens gebruikt worden voor een tactische sturing in de organisatie. Een voorbeeld hiervan betreft de debiteurenadministratie. Deze lijsten zullen op mutatieniveau inzicht bieden in de ouderdom per vordering maar op niveau 2 is dat bijvoorbeeld een ouderdomsanalyselijst. De inventarisatie van dergelijke lijsten biedt al een eerste inzicht of daadwerkelijk alle informatie over het pakket

2 Deel de processen in naar de informatieniveaus. Nadat de relevante SOX-processen geïdentificeerd zijn, dienen deze ingedeeld te worden naar de informatieniveaus. Er zal moeten blijken welke processen direct verbonden zijn met de consolidatie van informatie en welke processen direct te relateren zijn aan de operationele processen. Een juiste toekenning aan de informatieniveaus is van belang, omdat daarmee ook het gewicht van de key controls bepaald kan gaan worden, in verhouding tot de financiële jaarverslaggeving en het gewicht van een eventuele imperfectie.

bekend is. Voorbeelden van deze lijsten zijn tussenrekening, grootboek en werkvoorraden. 3 Verbandscontroles. Tussen de lijsten zijn verbandscontroles te leggen, niet alleen binnen modules maar ook tussen de modules. Op dit niveau moet gedacht worden aan consolidatie van de financiele informatie die op niveau 1 ingevoerd is. Verbandscontroles kunnen bestaan tussen lijsten maar ook tussen standen en controletotalen.

wordt dus vertegenwoordigd door de informatiepiramide in de structuur. Een module wordt gezien als een logische set van geautomatiseerde operaties (gegevens mutaties). De module levert na de invoer van de gegevens al dan niet als zelfstandige module stuurinformatie op die bestemd is voor de twee regelkringniveaus. Dit wordt bezien vanuit de betrouwbaarheid van informatie, vertegenwoordigd door regelkringniveau 2 en 3. Met de beschrijvingen van de niveaus is het duidelijk dat het gebruik van een zelfde taal aan te bevelen is. Elke module zal zijn eigen batchcodes, uitvallijsten en foutcodes kennen. Een overzicht van codes en omschrijvingen is voor de definitie van risico's een uitkomst en communiceert makkelijker. Daarbij zij opgemerkt dat eindgebruikers van een systeem ook vaak werken met lijstcodes. Application controls in zeven stappen Met een op hoofdlijnen uitgewerkt 7-stappenplan wordt de hiervoor beschreven structuur uiteengezet. Zoals gezegd zullen de omgevingsfactoren niet beschreven worden. Wederom

38

|

3 Verricht een module/systeeminventarisatie. Om een juiste koppeling tussen de processen en de ingeschakelde modules in kaart te brengen, dient allereerst het gehele systeemlandschap bekend te zijn. Daarbij dient ook de samenhang van de datastromen binnen en tussen de modules zichtbaar gemaakt te worden. Tijdens deze fase is het van belang inzicht te krijgen in de systeemcodes, modulecodes en andere applicatiegerelateerde codes. Dit is eigenlijk het invullen van de hiervoor genoemde voorwaarde 1 en 2. Het definiëren van controls en tests gaat met die kennis een stuk sneller door gerichtere en meer concrete vragen te kunnen stellen tijdens de risicoanalysefase (stap 5). Voor dit onderdeel zal een afdeling ICT een bijdrage moeten leveren waarna ORM dit verder uitschrijft. 4 Proces/modulematrix. Na het in kaart brengen van het systeemlandschap kunnen de onder stap 1 gedefinieerde processen gekoppeld worden aan de modules. Aangezien de processen reeds in stap 2 gekoppeld zijn aan de informatieniveaus, is daarmee ook inzichtelijk gemaakt hoe de modules met de informatieniveaus gerelateerd zijn. Daarmee is ook een eerste stap gezet naar het belang van het benoemen van de application key controls. 5 Analyse automatisering SOX-processen. Tijdens deze fase is het van belang vast te stellen op welke wijze binnen de vastgestelde SOX-processen de automatisering wordt toegepast. Ook hier is systeemdocumentatie een

FEBRUARI 2006

&

FINANCE

onmiskenbare steun. Tijdens de procesanalyse dient dus bepaald te worden welke informatie ingevoerd, verwerkt, opgehaald en vergeleken wordt. Wat daarbij in het voordeel gaat werken, is het gebruik van de hiervoor genoemde gemeenschappelijke codelijsten. Samenwerking met de gebruikers van het systeem is hier noodzakelijk. Er zal tijdens deze stap ook bepaald moeten worden welke onderdelen van het verslaggevingsproces op elkaar moeten aansluiten en hoe dit door de automatisering ondersteund wordt. Onvoldoende gedefinieerde verbandscontroles zijn vaak op zich al een indicatie van onvoldoende control. 6 Risicoanalyse. Met een beeld van de processen kunnen vervolgens de risico's bepaald worden. Hier gaat het erom dat de informatie tijdig, volledig, juist en met voldoende functiescheiding in de processen gegarandeerd is. Hoe hoger de automatiseringsgraad, hoe meer IT-controls er doorgaans gedefinieerd worden. De afdeling ORM zal tijdens deze analysefase een onafhankelijke positie moeten innemen en voor een gedegen risicoanalyse de advocaat van de duivel moeten spelen. Van vanzelfsprekendheden kan dus niet uitgegaan worden. Tijdens deze fase spelen ook de interfaces tussen modules een belangrijke rol. Het voert te ver om hier een uitputtende lijst met mogelijke algemene risico's op te sommen. Desondanks noemen we hier een aantal voorbeelden. ~ niet aansluiten van standen tussen modules (bijvoorbeeld tussenrekeningcontroles); ~ niet afgedwongen fiattering mutatieniveau; ~ onbeschermde velden bij bepaalde mutaties, waardoor ongeautoriseerde mutaties kunnen optreden; ~ systeemlijsten die niet op elkaar aansluiten; De risicoanalyse zal dus vanuit een contingentiebenadering toegepast worden, waarbij de aard van het bedrijf en het proces belangrijke factoren zijn.

7 Benoem de key risks/key controls top-down. Nadat de risicoanalyse heeft plaatsgevonden en de daarbij behorende risicobeheersingsmaatregelen bekend zijn, kan een selectie gemaakt worden van de key controls. De start van het benoemen van de key controls zal in samenhang gebracht moeten worden met de materialiteitscriteria. Het aantal key controles kan voor de overzichtelijkheid en beheersbaarheid van de SOX-werkzaamheden beter beperkt blijven. Op niveau 1 zal de aandacht daarom eerst uit kunnen gaan naar verbandscontroles (van niveau 3 naar niveau 1). In dat verband wordt opgemerkt dat juist de definitie ervan tijdens stap 5 belangrijk is. De top-downbenoeming van deze key controls zal verder in samenhang gebracht moeten worden met de impact van het risico van de betrouwbaarheid van de jaarverslaggeving.

CONTROL

Dit houdt niet in dat op operationeel niveau er geen key controls zouden kunnen bestaan. Juist wanneer er processen bestaan waar gebruikers de bevoegdheid hebben mutaties te fiatteren met grote financiële consequenties, is de benoeming van een key control vrijwel onvermijdelijk. Met het vaststellen is de basis gelegd voor de testwerkzaamheden en de verslaggeving over de imperfecties.

Een gezamenlijke taakopdracht, één taal, en een eenduidige structuur, zijn basisvoorwaarden voor een goed ontwikkeld SOX IT-dossier

Conclusie In dit artikel is de aandacht primair uitgegaan naar het opzetten van de application controls. Daarbij zijn drie in te vullen voorwaarden en een zevenstappenplan aangeboden, gebaseerd op een informatiestructuur. Het volgen van een eenduidige ontwikkellijn rondom een door de organisatie te begrijpen structuur maakt dat de application controles makkelijker en sneller in kaart gebracht kunnen worden. Gebleken is dat het daarbij in kaart brengen van het systeemlandschap van belang is. Met het in kaart brengen van het systeem en de onderliggende modules is het ook van belang reeds kennis te nemen van de processen. Processen kunnen uiteraard ook verbonden zijn met meerdere modules. Een gezamenlijk begrepen en herkenbare structuur maakt dat partijen gemakkelijker zullen samenwerken. Bovendien is ook de impact van eventuele systeemwijzigingen die zich (gaan) voordoen, gemakkelijker te plaatsen in dat perspectief. Tenslotte: het SOX-dossier is nooit af. Elke wijziging die plaatsvindt in de organisatie, procedureel maar ook systeemtechnisch, heeft doorgaans consequenties voor de IT-controls. Gerealiseerd dient te worden dat bij iedere release-update er een kans bestaat dat de operationele controles zijn gewijzigd. De stappen 4, 5 en 6 zullen daarom ook regelmatig verricht dienen te worden. Drs. C. Roodhorst MC ([email protected]) heeft dit artikel op persoonlijke titel geschreven.

FEBRUARI 2006

|

39


SOX EN HET BELANG VAN DE IT-CONTROLS

Recommend Documents