Inleiding

Dit artikel bestaat grofweg uit drie onderdelen. In de eerste plaats wordt stilgestaan bij de SOX-ervaringen en -ontwikkelingen op het gebied van IT vanuit de wet- en regelgeving en gezaghebbende instanties. Hierbij wordt aangegeven welke IT in dit verband relevant is en hoe met specifieke vraagstukken moest worden omgegaan. Vervolgens worden de ontwikkelingen vanuit de praktijk, met name gericht op de kosten van compliance, besproken. Ook komen hierbij aan de orde de mogelijkheden om beter inzicht te krijgen in de kosten en het integreren van frameworks. In de derde plaats wordt richting de toekomst stilgestaan bij recente ontwikkelingen, zoals de impact van de recente voorstellen van de PCAOB en de SEC, gericht op de IT-aspecten. De indeling is als volgt:

• Ervaringen IT en SOX vanuit wet- en regelgeving
  • Applicatie- en IT general controls
  • Guidance vanuit Cobit (2004-2006)
  • Evaluatie van tekortkomingen (framework 2004)
  • PCAOB 16 mei 2005 guidance.
• Ervaringen vanuit de organisaties
  • Centrale versus decentrale benadering
  • Compliancekosten en control transformation
  • Framework integration
  • Ondersteunende SOX-tools.
• Toekomstige ontwikkelingen
  • Recente guidance PCAOB en SEC.

Ervaringen IT en SOX vanuit de wet- en regelgeving

Applicatie- en IT general controls

Bij een terugblik op de SOX-ontwikkelingen is het van belang om de relevante IT hierbinnen vast te stellen. Binnen SOX staat de beheersing van de bedrijfsprocessen ten behoeve van de financiële verantwoording centraal. De IT ondersteunt deze processen en zal daarmee ook voldoende moeten worden beheerst. Voor de gehele beheersing van een organisatie wordt meestal het COSO-model[Dit model zal in dit artikel niet verder worden uitgewerkt, maar wordt als bekend verondersteld.] als beheersingsraamwerk gehanteerd; zie daarvoor ook gerelateerde artikelen in eerdere Compacts. Binnen IT zijn de relevante IT controls in een organisatie in drie categorieën te onderscheiden:

1. organisatiebrede controls (COSO-component Control Environment);
2. applicatiecontrols (input-outputcontrols, validation rules, toleranties, autorisaties, interfacecontrols, IT dependent controls …);
3. algemene IT controls (Change Management, Security Management, …).

De laatste 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 applicatiecontrols direct in de processen geïdentificeerd en zijn de algemene IT controls gericht op de IT-componenten (zoals databases, operating systems, netwerk, …) die de werking van deze applicatiecontrols waarborgen.

Applicatiecontrols (hierna AC) zijn op diverse plaatsen in en rondom de applicaties aanwezig, soms geheel geautomatiseerd en soms gedeeltelijk. Dit maakt het identificeren van de AC niet altijd eenvoudig. Binnen de SOX-wetgeving zijn niet alle AC relevant. Om te komen tot een juiste set van AC dienen vanuit de beweringen in de financiële verantwoording, de bedrijfsprocessen te worden geïdentificeerd die een belangrijke (significante) bijdrage leveren aan de standen en stromen in deze verantwoording. Vervolgens zal het management de risicopunten in de bedrijfsprocessen bepalen, gebaseerd op mogelijke significante onjuistheden in de verantwoording. Deze risicopunten worden beheerst door middel van zogenaamde key controls, dit kunnen AC zijn. De goede werking van de AC moet door het management worden aangetoond. Indien een AC niet goed werkt, is het risicopunt niet voldoende beheerst en volgt een proces van het identificeren/testen van compenserende controls of het herstellen van controls en/of het bepalen van de mogelijke fout in de financiële verantwoording.

Figuur 1. Scoping van kritieke financiële rapportageapplicaties.

Het is in dit verband van belang dat de diverse onderdelen in de organisatie (business-IT-kant) nauw samenwerken. Dit geldt uiteraard ook voor de samenwerking tussen de IT-auditor en de financial auditor. Indien de samenwerking ontbreekt, is er een risico dat er te weinig relevante AC worden geïdentificeerd, maar het omgekeerde is ook mogelijk. Indien systemen geïsoleerd worden beschouwd, kan het goed zijn dat er daadwerkelijk, op het eerste gezicht belangrijke, AC aanwezig zijn in de betreffende systemen. Maar op andere plekken en in andere systemen kunnen vergelijkbare beheersingsmaatregelen aanwezig zijn, waardoor de gevonden AC niet getest hoeven te worden. Zo kan de feitelijke voorraad in depotsysteem A worden geregistreerd in hoeveelheden en wordt de financiële waarde in ERP-systeem B vastgelegd. Periodiek vindt er een inventarisatie van het depot plaats en wordt de waarde in B vastgelegd en via dit systeem verwerkt in de depotsystemen A. Met behulp van de inventarisatie en de registratie in systeem B zijn er mogelijk geen relevante AC in A. Dit systeem zit dan niet in de SOX-scope. Hetzelfde geldt voor systemen die weliswaar financiële data registreren, maar geen materieel financieel effect kunnen hebben op de financiële verantwoording.

Vervolgens zijn de aanwezige risicoanalyse en de applicatiecontrols het startpunt voor het bepalen van de IT general controls (hierna ITGC). Deze relatie is figuur 2 weergegeven.

Figuur 2. Scoping van kritieke applicatiecontrols en IT general controls.

De ITGC in scope hebben betrekking op de betreffende applicaties en de onderliggende IT-infrastructuur, zoals de betreffende database, het operatingsysteem en het netwerk. Het is in dit verband goed te beseffen dat niet de IT-processen, veelal op ITIL gebaseerd, het vertrekpunt zijn voor de SOX-scope, maar de IT-componenten binnen de genoemde IT-infrastructuur. Deze IT-componenten ondersteunen de goede werking van de AC, die vanuit de bedrijfsprocessen zijn geselecteerd. In de praktijk zien we vaak dat organisaties starten met de implementatie van alle ITIL-processen, voor zover nog niet aanwezig, om aan SOX te kunnen voldoen. Deze aanpak heeft tot gevolg dat relatief veel procedures en standaarden worden opgesteld. Hierbij bestaat het risico dat deze onvoldoende zijn uitgewerkt in ITGC, gericht op de betreffende IT-componenten. De geïmplementeerde set van procedures is weliswaar een belangrijke randvoorwaarde voor goede beheersing, maar de procedures zijn niet of moeilijk testbaar voor het management / de auditors indien de directe relatie met de IT-componenten ontbreekt ([Korn05]).

Guidance vanuit Cobit (2004-2006)

In de praktijk is er veel discussie geweest met betrekking tot de ITGC die in scope zouden moeten zijn voor SOX. De PCAOB heeft de IT-gebieden aangegeven en vanuit de AC kunnen de IT-componenten binnen de IT-infrastructuur worden onderscheiden, zoals databases, etc., maar welke ITGC zijn hierbinnen relevant? Zijn dit alle domeinen binnen Cobit of de meest gangbare ITIL-processen? Het IT Governance Institute (ITGI) heeft hier ondersteuning aan gegeven door vanuit Cobit de specifieke controledoelstellingen voor de ITGC te identificeren ([ITGI04] en [ITGI06]), zie figuur 3.

Figuur 3. Identificeren van controledoelstellingen en IT general controls.

Vanuit de IT-infrastructuur in scope worden de relevante ITGC geïdentificeerd binnen de relevante IT-beheerprocessen, mogelijk gebaseerd op ITIL, vanuit de twaalf aangegeven controledoelstellingen binnen de vier IT-gebieden van de PCAOB. Afhankelijk van de feitelijke omstandigheden zullen deze ITGC verschillen per organisatie. Binnen de ICOFR wordt de nadruk gelegd op de aanwezige ITGC en niet zozeer op de aanwezige IT-beheerprocessen, hoewel deze wel een randvoorwaarde kunnen zijn om de ITGC in te kunnen richten. Zonder duidelijke IT-beheerprocessen zullen de ITGC vaak niet effectief zijn. Het ‘brede’ IT-beheer kan in dit verband ook worden gezien als een onderdeel van de ‘entity level controls’. Indien IT-beheerprocessen onduidelijk zijn, is er een organisatiebrede tekortkoming.

Evaluatie van tekortkomingen (framework 2004)

Nadat de totale IT-scope langzaam helder werd vanuit de PCAOB- en Cobit-richtlijnen, kwam het vraagstuk inzake het evalueren van tekortkomingen naar voren. Hoe belangrijk is een IT-deficiency? Als specifieke ITGC niet werken, is het lastig om de impact hiervan te bepalen, indien er geen duidelijke relatie is gelegd met de businessprocessen en de daarin opgenomen AC. In overleg met de SEC hebben de grotere accountantskantoren een raamwerk opgesteld om onder andere tekortkomingen in de IT controls te kunnen evalueren ([Fram04]). De applicatiecontrols worden gelijk als de andere ‘process level controls’ beoordeeld, voor de ITGC is een specifiek model ontwikkeld. Samengevat komt dit erop neer dat indien een AC wordt aangemerkt als een ‘significant deficiency’, dit nooit kan leiden tot een ‘material weakness’ in de (algemene) IT control en daarmee tot een afkeurende ‘SOX-verklaring’. Dit onderstreept het belang van het identificeren van de relatie tussen de IT controls ten opzichte van de AC, aan de hand van de IT-componenten. Zoals eerder aangegeven zijn deze IT-componenten onderdelen uit database, netwerk en operatingsysteem die de goede werking van de AC ondersteunen. Binnen de aanwezige IT-infrastructuur zullen de relaties tussen deze IT-componenten moeten worden uitgewerkt, zodat hierop specifiek kan worden getest en tekortkomingen via bovenstaand model kunnen worden geëvalueerd. Met name in grotere IT-omgevingen zal dit een nadere inventarisatie van servers, tabellen, interfaces, etc. tot gevolg hebben. Door deze relaties vooraf gedetailleerd in kaart te brengen kan de totale SOX (en test)-scope aanzienlijk worden beperkt. Daarnaast kan weloverwogen worden besloten enkele ineffectieve IT controls niet op te lossen, bijvoorbeeld indien de betreffende applicatiecontrols wel effectief zijn of slechts een ‘deficiency’.

Bovenstaande betekent niet dat IT controls die geen directe invloed hebben op de goede werking van de applicatiecontrols, niet relevant zouden zijn, omdat zij niet direct kunnen leiden tot een ‘material weakness’. Een veelheid van eventueel kleine tekortkomingen (deficiencies) op één of meer ITGC-gebieden (bijvoorbeeld Access to Programs and Data of Program Changes) duidt op een minder goed beheerste control environment, wat op zich een ‘significant deficiency’ of ‘material weakness’ kan zijn. Deze aggregatie-evaluatie dient ook te worden meegenomen in de totale ‘deficiency evaluation’.

PCAOB 16 mei 2005 guidance

Naar aanleiding van de ervaringen bij de SOX-plichtige ondernemingen in de Verenigde Staten hebben de SEC en de PCAOB additionele richtlijnen uitgevaardigd in ‘Frequently Asked Questions’ en ‘Staff-Policy Statements’, waarvan met name die van 16 mei 2005 een relatief grote impact hadden. In het algemeen was men niet tevreden over de wijze en diepgang hoe de ondernemingen met SOX (en IT) zijn omgegaan. Dit kwam onder meer naar voren in de volgende opmerkingen ([PCAO05]):

• ‘… for purposes of the Section 404 assessment, the staff would not expect testing of general IT controls that do not pertain to financial reporting …’
• ‘… in establishing the scope of its IT assessment, management should apply reasonable judgment and consider how the IT systems impact internal control over financial reporting …’

In dit verband heeft de SEC specifiek aangegeven dat een top-down risicobenadering gevolgd dient te worden, waarbij uitsluitend applicaties relevant zijn waarin significante applicatiecontroles zijn opgenomen in relatie tot de financiële verantwoording.

Daarnaast heeft de PCAOB het concept van ‘Baselining – Benchmarking’ van AC verder uitgewerkt. Indien een AC eenmaal is getest op werking en de ITGC zijn solide, zoals change management en system access, dan behoeft de AC niet ieder jaar te worden getest. De PCAOB geeft in dit verband aan: ‘Entirely automated application controls, therefore, are generally not subject to breakdowns due to human failure and this feature allows the auditor to ‘benchmark,’ or ‘baseline’, these controls.’ Dit houdt in dat ‘… the auditor may conclude that the automated application control continues to be effective without repeating the prior year’s specific tests of the operation of the automated application control …’. Het moge duidelijk zijn dat er op voorhand efficiencyvoordelen zijn te behalen indien dergelijke AC niet jaarlijks behoeven te worden getest. De PCAOB heeft hierbij wel een aantal randvoorwaarden gesteld. Afhankelijk van de feitelijke omstandigheden zal de betreffende benchmark periodiek kunnen worden uitgevoerd.

Ervaringen vanuit de organisaties

Centrale versus decentrale benadering in de praktijk

Afgezien van het feit dat in de PCAOB-publicatie van mei 2005 specifiek de nadruk is gelegd op een risk based top-down benadering, is de praktische uitvoering van SOX in het eerste jaar toch vaak decentraal geweest. Een belangrijke oorzaak hiervan is het niet specifiek inzichtelijk hebben van de lokale IT-omgeving op centraal niveau. Dit kwam bij een belangrijk proces voor SOX, het scopen van de IT-applicaties en -infrastructuren, vaak al tot uitdrukking. Dit proces is door veel organisaties en externe auditfirma’s in het eerste SOX-jaar onderschat en onvoldoende concreet gedefinieerd. Niet alleen de onduidelijkheid van de SOX-regelgeving met betrekking tot IT, zoals genoemd in de vorige paragraaf, is hier debet aan, maar ook de onbekendheid met het IT-landschap in het algemeen en al helemaal die delen daarvan die impact kunnen hebben op de financiële rapportageprocessen.

Concreet zijn er twee manieren om het IT-landschap te definiëren voor SOX, namelijk de top-down en bottom-up benadering. Bij de top-down benadering is er inzicht in de key IT-applicaties en -infrastructuren en wordt de IT-scoping gecentraliseerd uitgevoerd. Aangezien op centraal niveau niet altijd bekend is hoe het exacte decentrale IT-landschap eruitziet, hebben veel organisaties het scopen van de IT overgelaten aan de lokale units. Door deze veelal decentrale benadering zijn in eerste instantie ook veel applicaties geïdentificeerd waarbij geen of slechts weinig applicatiecontrols zijn geïdentificeerd of die financieel gezien niet materieel zijn; in beide gevallen zijn deze applicaties dus niet significant. Gedurende het jaar hebben dan vaak ook herscopingen plaatsgevonden om het hoge aantal niet-significante applicaties te beperken binnen de SOX-scope. Hierbij is een aantal (compenserende) manuele controles geïdentificeerd om deze applicaties buiten de SOX-scope te houden. Deze reparatieactie neemt naast de nodige tijd ook de focus op de daadwerkelijk significante IT-applicaties en -infrastructuren weg.

Deze decentrale benadering is ook veelal tot uitdrukking gekomen in de identificatie van de applicatiecontrols. Onbekendheid met verschillende applicaties en het ontbreken van gestandaardiseerde proces-, risico- en controletemplates inclusief duidelijke IT application controls heeft ertoe geleid dat er veel verschillende AC of juist geen AC zijn geïdentificeerd binnen de bedrijfsprocessen. Hierdoor was het op het eerste gezicht ook lastiger om een geheel efficiënte en gecentraliseerde testaanpak te hanteren voor de AC. Ondanks dat de decentraal geïdentificeerde AC verschillend werden beschreven, konden ze vaak herleid worden naar een aantal key application controls per bedrijfsproces. De aanpak voor 2007 zal daardoor ook vanuit deze key application controls per bedrijfsproces ingestoken gaan worden. Niet alleen kan hierdoor meer duidelijkheid worden verschaft over wat de AC nu exact inhouden, maar ook kan een efficiëntere centrale testaanpak worden gedefinieerd en gehanteerd.

Nu na het eerste jaar het IT-landschap, de AC en de testaanpak daadwerkelijk inzichtelijk zijn gemaakt, zullen in 2007 veel organisaties in het kader van SOX een meer gecentraliseerde en top-down benadering implementeren en zo nodig intern en bij hun externe accountants afdwingen.

Compliancekosten verlagen

De meeste organisaties hebben het eerste SOX-jaar een hoge prijs moeten betalen om ‘compliant te geraken. Naast het feit dat de auditfees gestegen zijn en vaak ook een externe adviseur is gevraagd te ondersteunen, hebben de organisaties ook veel interne kosten gemaakt. Het tweede jaar staat bij de meeste organisaties dan ook in het teken om deze total cost of compliance te verlagen door zaken te optimaliseren en te verbeteren. Het probleem is echter, dat de total cost of compliance vaak niet bekend is bij organisaties, doordat het merendeel van de kosten (de interne kosten) niet wordt bijgehouden. In figuur 4 is een illustratie gegeven van de kostenstructuur van een dagelijkse controle. Naast de test- en auditkosten brengt een dergelijke control ook de kosten van de dagelijkse uitvoering met zich mee.

Figuur 4. Overzicht total costs of compliance van een handmatige control.

De meeste organisaties hebben vaak het eerste jaar initieel de toevlucht gezocht tot manuele controls, waardoor de kosten van SOX onacceptabel hoog kunnen oplopen. Zoals al aangegeven in het artikel ‘Tool-based monitoring en auditing van ERP-systemen’ ([Brou06]) zullen organisaties de komende jaren manuele detective controls vervangen door preventieve controls (applicatiecontrols). Deze preventieve controls hoeven namelijk slechts eenmaal op het bestaan te worden getoetst. Daarnaast behoeft een preventieve controle geen correctieve acties die bij detective controls vaak wel aan de orde kunnen zijn. Verder heeft een AC een belangrijk voordeel: vele daarvan kunnen automatisch worden getest. Wijzigingen aanbrengen in de controls portfolio wordt ook wel ‘control transformation’ genoemd en zal de komende jaren bij veel SOX-organisaties in het teken van optimalisatie staan.

Figuur 5. De trend: control transformation.

Voor het aanbrengen van wijzigingen in de controlportfolio is behalve overleg tussen het SOX-projectteam, de control owner en de IT-afdeling ook een duidelijke business case nodig. Een dergelijke business case wordt samengesteld op basis van een zogeheten controlportfolio-analyse. De uiteindelijke processen die in aanmerking komen om als eerste aangepakt te worden hebben naast een hoge bijdrage tot kostenreductie ook duidelijke procesoptimalisatiemogelijkheden.

Voordelen controlportfolio-analyse:

• standaardiseert de classificering van controls;
• standaardiseert de gekwantificeerde cost of compliance-analyse;
• ondersteunt het identificeren en prioritiseren van opportunities voor procesoptimalisatie en kostenreductie.

In de markt zijn er nog niet veel generieke tools aanwezig om een dergelijke controlportfolio-analyse uit te voeren. Daarom grijpen veel organisaties naar Excel-georiënteerde tools. De ondersteunende tools die op de markt beschikbaar zijn, onderscheiden vaak een kwantitatieve scan (bottom-up) om de cost of compliance te berekenen op basis van de geïmplementeerde control frameworks in de organisatie en een kwalitatieve scan (top-down) op basis van enquêtes en interviews om de mogelijke procesoptimalisaties te bepalen. De beide aanpakken vormen de basis voor het identificeren van de mogelijke opportunities. In figuur 6 is een voorbeeld van een projectaanpak toegelicht.

Figuur 6. Voorbeeld aanpak analyse van de controlportfolio. [Klik hier voor grotere afbeelding]

Het uiteindelijke resultaat: de controlportfolio, een onderbouwd impactanalyserapport en de implementatieroadmap.

Framework integration

Bij de organisaties die op een adequate wijze het ICOFR-raamwerk hebben ingericht, zien we dat zij duidelijke stappen zetten richting een transformatie naar een Business Control-raamwerk. Hierdoor kunnen zij de beheersing van de bedrijfsprocessen verbeteren en daarmee daadwerkelijk de vruchten plukken van hun inspanningen. Dit begint bij het uitvoeren van een analyse naar bedrijfsrisico’s, zowel op strategisch als op procesniveau. Centraal daarbij staan alle ‘businessrisico’s’ (van strategische tot operationele risico’s), aangezien de financiële risico’s al in kaart zijn gebracht. Op basis van deze risico’s worden vervolgens Business Controls geïdentificeerd en gedocumenteerd, die daarna kunnen worden ingebed en geoptimaliseerd. Het is raadzaam om na de implementatie van het ICOFR-raamwerk direct door te pakken door niet alleen de financiële beheersingsmaatregelen, maar ook de Business Controls gestructureerd in te richten. SOX heeft immers binnen de organisatie een schat aan kennis, ervaring, tools en draagvlak opgeleverd. Het zou zonde zijn om dat momentum verloren te laten gaan. Deze fase noemen we ook wel Framework integration, waarbij de verschillende control frameworks, gebaseerd op verschillende wet- en regelgeving, worden geïntegreerd en gezocht wordt naar controledoelstellingen en beheersingsmaatregelen die meerdere frameworks afdekken.

Figuur 7. Control framework integration.

De volgende overwegingen kunnen hierbij een rol spelen:

• hergebruik van al het verzameld controlebewijs, efficiënter testen van controls;
• verlaging van de kosten van separate audits;
• geïntegreerd overzicht van controls en analyse, en efficiëntere monitoring;
• onderhoudbare (sustainable) compliance.

Ondersteunende SOX-tools

Het eerste SOX-jaar hebben veel organisaties en auditfirma’s nog hun toevlucht genomen tot de ‘flexibele’ wereld van Excel voor de ondersteuning van de SOX-opdracht. Indien echter de organisatie een omvang heeft van meerdere landen en organisatieonderdelen voldoet Excel niet meer. Beperkingen zoals het slechts ten dele kunnen afdwingen van versiebeheer, het werken in een template, het niet met één druk op de knop kunnen monitoren van de voortgang, etc. hebben geleid tot nadenken over ondersteunende SOX-tooling. Maar wat houdt ondersteunende SOX-tooling nu precies in?

Bij de term ondersteunende SOX-tools wordt in eerste instantie gedacht aan de ondersteuning bij de SOX-opdrachtmanaging zelf, namelijk ondersteuning bij SOX-scoping; vastlegging van de procesbeschrijvingen, risico’s en key controls; vastlegging en monitoren van de voortgang van het testwerk; en vastlegging en evaluatie van de deficiencies.

Er zijn echter meerdere typen tooling op verschillende niveaus mogelijk die de organisatie kunnen ondersteunen ([Brou06]). Voor SOX hebben de Operational Risk Management Tools de meeste directe toegevoegde waarde. Binnen dit niveau worden twee typen tools onderscheiden. Op de eerste plaats het monitoren van de key controls (al dan niet IT controls) door de ‘control executors’ binnen de lokale organisaties in een centrale database. Hierdoor is in één oogopslag duidelijk welke controls in scope zijn, welke getest zijn en wat de resultaten hiervan zijn vanuit alle mogelijke invalshoeken. Het tweede type tool faciliteert het automatisch verkrijgen van fact-findings van de werking van applicatie-, autorisatie- en reporting controls uit de systemen. Dit laatste type tools zal mede door de control transformation (de transitie van manuele controls naar applicatiecontrols) en framework integration de komende jaren een grote vlucht gaan nemen. Vooral het op elk moment efficiënt en automatisch met behulp van deze tools kunnen monitoren van de bedrijfsprocessen en hierover kunnen rapporteren zal veel organisaties aanspreken. Indien deze fact-finding tool is dan wel wordt geïntegreerd met de hiervoor genoemde tool ten behoeve van de monitoring van key controls, ontstaat een krachtig en effectief instrument voor de organisatie om enerzijds de financiële reportingprocessen maar anderzijds ook de bedrijfsprocessen te beheersen.

Toekomstige ontwikkelingen

Recente guidance PCAOB en SEC

Op 19 december 2006 heeft de PCAOB een voorstel gepubliceerd om de huidige auditstandaard (AS2) te vervangen ([PCAO06]). De SEC heeft een dag later een ‘guidance paper’ voor het management voorgesteld ([SEC06]). De belangrijkste wijzigingen die van invloed kunnen zijn op de aard en omvang van de IT controls en de hoeveelheid testwerk zijn[Het voorstel van de PCAOB en het guidance paper van de SEC zijn nog in concept en zijn aan review en eventuele aanpassingen onderhevig. De in dit artikel beschreven interpretaties van deze conceptvoorstellen zijn een mening van de schrijvers op persoonlijke titel.]:

• Er zal een duidelijke focus moeten worden aangebracht op een risico- en top-down gerichte aanpak:
  • Focus op materiële risico’s en het testwerk hierop afstemmen. De audit moet niet gericht zijn op het identificeren van mogelijke ‘significant deficiencies’, maar op de mogelijke ‘material weaknesses’.
  • In dit verband is het begrip susceptibiliteit geïntroduceerd. Er zal meer focus moeten zijn op de relatief zwakke plekken van jaarrekeningposten, transacties en onderbouwingen. Deze plekken kennen een grotere subjectiviteit, complexiteit en fraudegevoeligheid.
• De auditor hoeft geen verklaring meer te geven bij het ‘management process’. Veelal ontbrak het bij de organisatie aan IT-technische deskundigen om alle IT controls goed te kunnen beoordelen. Hierover hoeft de auditor niet te rapporteren, indien de IT controls effectief zijn.
• Er kan meer worden gesteund op verricht werk en ervaringen uit het verleden, waardoor het testwerk kan worden verminderd. Maar het roteren van tests, met andere woorden het spreiden van de testwerkzaamheden over meerdere jaren (bijvoorbeeld elk jaar eenderde van de totale hoeveelheid), blijft niet toegestaan (met uitzondering van benchmarking van entire automated controls). Ieder jaar moet nog steeds op zichzelf worden beoordeeld. Afhankelijk van de risico-inschatting kan wel minder worden getest.
• Er kan meer gebruik worden gemaakt van het testwerk van ‘anderen’ (bijvoorbeeld een IAD), mits zij competent en objectief zijn. In dit verband kan worden samengewerkt bij het uitvoeren van walkthroughs. Daarnaast behoeft de auditor geen ‘principal evidence’ meer te verzamelen, maar ‘sufficient competent evidence’. Dit is vager, maar maakt een duidelijke inschatting van de verrichte werkzaamheden door die ‘anderen’ noodzakelijk.
• Significant deficiencies, die voor IT veelvuldig voorkwamen, kunnen blijven bestaan. Zij hoeven niet binnen een redelijke termijn te zijn opgelost, mits er een goede onderbouwing en afweging van risico’s aanwezig is. Deze afweging is dan een onderdeel van de control environment.

Verder zijn de belangrijkste uitgangspunten van de ’16 mei guidance’ duidelijk herhaald.

Daarnaast geeft de PCAOB voor kleinere en minder complexe omgevingen aan dat ‘… in the areas in which off-the-shelf software is used, the auditor’s testing of information technology controls should focus on the application controls built into the pre-packaged software that management relies on to achieve its control objectives and the IT general controls that are important to the effective operation of those application controls …’.

Conclusie

Het moge duidelijk zijn dat er de afgelopen jaren veel is gebeurd op het gebied van de SOX-regelgeving in relatie tot de scoping en testing van de IT controls binnen de grote US-beursgenoteerde ondernemingen. Dit heeft geleid tot aanzienlijke inefficiënties waar ondernemingen op hebben gereageerd met slimmere scoping, combineren en vereenvoudigen van beheersingsmaatregelen, betere ondersteuning door tools en het integreren van controleraamwerken. Vervolgens zien we dat zij, in hun efficiencypogingen, worden gesteund door de voorgestelde aanpassingen in de auditingstandaard: meer gebaseerd op risico’s, geen afzonderlijke beoordeling van management assessment, meer gebruikmaken van IAD’s, etc. Hopelijk zijn er nu voldoende bouwstenen aanwezig voor een ‘sustainable and efficient compliance’ in de toekomst en kan er worden gedacht aan ‘return on compliance’, ofwel de toegevoegde waarde van een beter beheersbare omgeving.