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
Logische toegangsbeveiliging
Logische toegangsbeveiliging
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
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
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
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