Many organizations today are coming to terms with the fact that the huge growth in information has created risk exposure in terms of the accessibility and integrity of data. That exposure is increasingly realized through litigation where data records are considered “discoverable” by courts. This article sets out some of the risks and challenges facing organizations today in the realm of Records Management.

Introduction

As the nature of business information becomes more complex and compliance issues multiply, every organization, large or small, regardless of its line of business, must analyze how it controls information within the enterprise, across the globe, and between product/service offerings. Sometimes corporate compliance departments and legal departments find themselves in contention with their IT departments as the former demand processes that can deliver the right information at the right time to the right person. When that repeatedly fails to happen, organizations begin re-assessing their records management programs.

Most organizations today have, in practice, a records management program based upon physical paper. They may also have an archiving strategy for electronic information. Frequently, the first is performed by a Records Management or Legal Compliance Department; the second is managed by an IT Department. The Records Management/Compliance Department concentrates on producing documents for regulatory, tax, and litigation reasons; the IT Department wants to save costs on storage and improve network performance. Getting these two groups to align their strategies is the first step toward a comprehensive global records management program that ensures safe harbor from risk and provides verifiable, defensible practices.

The development of a Global Records Management program and policy is an opportunity to set out the vision and role of enterprise-wide Records Management within an organization, as well as to create a framework for the ancillary policies. Ancillary policies need to be established to treat specific types of data content, but they must still adhere to the guiding principles of the overall policy. Ancillary policies create requirements that meet the different needs of physical records, inactive records, vital records, e-mail, records shared across multiple regions, and electronic records for long-term archival storage. The result is an organization that mitigates risk, meets compliance demands, and realizes tangible business benefits.

Records Management Risks

Records are information created, received or used as part of a firm’s transactions, processes or business activities and legal obligations (ISO15489). Records contain information created, received, and maintained as evidence by an organization or person, in pursuance of legal obligations or in the transaction of business. They include documentation pertaining to a transaction or business event that may have legal ramifications or historical value. Guided by regulations, each organization must determine the definition of what a record is and, often more importantly, what it is not.

Good records management can:

Aid more effective disclosure and help laywers make faster decisions as to the extent of a reasonable search for documents in accordance with disclosure rules. Being able to identify relevant or privileged material quickly will also save significant costs in the event of litigation.
Provide evidence of compliance in keeping with legal requirements as regulators pay more attention to data retention.
Reduce time and expense incurred through document production activities associated with litigation, and increase speed and efficiency in meeting regulatory requests for documentation.

The complexity of records management has increased exponentially in recent years. Massive information production along with the complexity of processing this amount of data frequently has every level of management perplexed when the full gambit of risks are considered. For instance, a subset of this massive information contains personal information about individuals, and therefore requires increased control and recognition of how the use of data protection rights such as Subject Access Requests, interact with non-privacy related litigation, such as discrimination.cases.

Organizations are capturing information using an increasing variety of methods, including scanners, notebooks, printers, removable devices and storage area networks. The records containing this information are subject to multiple regulatory requirements, including for instance MiFID, national implementations of Directives 95/46/EC & 02/58/EC, provincial and national employment law, Federal Rules of Civil Procedure (FRCP), American Bar Association (ABA) Civil Discovery Standards, Gramm-Leach-Bliley, Health Insurance Portability and Accountability Act (HIPPA), Securities and Exchange Commission (SEC) Rule 17a-4 and National Association of Securities Dealers (NASD) Rule 3010. Failure to produce records and information to meet these regulations can be costly and damaging to an organization’s reputation.

More recently, improvement programs for records management have been driven by Litigation Readiness concerns over e-discovery costs. Those costs have steadily risen as businesses deal with numerous and constant disclosure requests. The task of sifting through vast archives of e-mail and electronic data has become increasingly complex and taxing. Litigation Readiness programs hold the promise of reducing these costs. Their aim is to give companies the knowledge of precisely where and how their records are stored and over what period of time, plus the comfort of knowing they are stored in accordance with the discovery obligations of each jurisdiction in which they operate.

Figure 1. The Bounded Control of Key Business Functions.

Nothing is growing as fast as the production of information. Much of this information is linked to individuals, and some of this personal data is sensitive. At the same time, the complexity associated with processing data is also growing. These three factors are the primary constituents of privacy risk (shown here), and hence the privacy risk function is exponential. Because records management encapsulates and extends beyond personal data, a similar escalation in risk applies to records management. No single business function is equipped to manage this risk in its entirety. There can be little doubt that severe exposure is likely for those with the greatest value at stake. This is certainly the case where the legal aspects of regulation are dealt with in isolation, without also ensuring alignment with IT, assurance through audit and full integration with prevailing operational risk frameworks.

To help organizations realize potential benefits that could be gained from proactive programs, KPMG has designed a process called Transformational Records Management (TRM), a process that aligns records management practices with legal and business objectives. TRM can deal with widely deployed responsibilities and help gain acceptance across multiple functional lines. TRM moves processes towards broadly stated business and regulatory objectives. Technology is leveraged to address both the past (where the vast majority of exposure resides) and the future, to support long-term value preservation.

TRM aims to help organizations realize the benefits of good records management by adopting strategies across the following areas:

Reputational risk management arising from inefficient records management processes.
Litigation and regulatory readiness.
Compliance transparency.
Effective data retention.
Controled storage costs.

Through the orchestration of these five elements TRM provides organizations with the ability to achieve business benefit from the effective and efficient management of records.

Improved management of reputational risk

Losing face can trigger a crisis of confidence in shareholders, customers, business partners and regulators, constraining a company’s ability to do business. Many adverse court decisions have been publicized where findings were made against companies unable to produce admissible records. But the issue is broader. Poor records management is the cause of many failures to deal effectively with customer queries and complaints. It is directly correlated to falling customer retention rates and affects customer acquisition.

Fragmented approaches tend to fail. Success depends on establishing a consistent view of information lifecycles across the organization focusing on retention, disposition and discovery. Consistency can be achieved by adopting a model centered on business activities, with similar rules applied to the records for each activity. Taking an integrated view of the approaches across several business functions can help to ensure that a consistent approach is taken to defining the categorization scheme for retention and disposition. Business users will have made decisions in the past around retention, as part of business continuity planning, and these can serve as precedents for the design and implementation of functional taxonomies that will enable category and custodial identification standards to be applied.

Litigation and Regulatory Readiness

It is a growing and significant challenge for institutions to manage the growth of data held within their systems in order to identify, preserve and manage information effectively for future use. Corporate and public bodies are increasingly subject to information requests by regulators, government institutions and the general public, whilst there is a continuing obligation to disclose electronically stored information (ESI) in legal proceedings. Having simple and immediate access to relevant information in advance of competition enquiries, regulatory investigations, Freedom-of-Information requests or litigation can save organizations time, money and inconvenience should such scenarios materialize.

Poor records management can lead to poor preparedness for the challenges of e-discovery in the US and e-disclosure in the UK. There have been various examples of records management failures that have led to heavy fines as part of legal proceedings. These include Nationwide being fined £980k by Financial Services Authority for information breaches (information security lapses), the SEC fining 5 broker-dealers $8.25M for violation of record-keeping requirements regarding e-mail and Morgan Stanley being ordered to pay $1.45 billion in a civil lawsuit, due in large part to failure to properly produce electronic documents.

The courts in the UK have started to take a greater interest in e-disclosure: for example, in the recent case of Digicel the defendants were found not to have properly searched back-up tapes. As such it is clear that proper records management can aid more effective e-disclosure and help lawyers make faster decisions on the extent of a reasonable search for documents in accordance with disclosure rules. Being able to identify relevant or privileged material quickly will also save significant costs in the event of litigation.

Some questions to consider:

Are you ready to handle an information request, enquiry or raid?
Do you have a comprehensive and consistently applied information retention strategy?
Do you know where your business critical information is stored?
Can you access and extract it quickly?
Are your information systems effectively organized to ensure disclosure?
Can you measure the cost of collecting, processing and producing ESI?
Do you have a documented, defined, defendable and repeatable process for processing litigation and regulatory requests?

In litigation, internal counsel needs to understand precisely which records opposing counsel will receive in response to a discovery request. Predictability in these cases directly affects litigation success. For records to be admissible and defendable in court there must be evidence of their authenticity and chains of custody. Legal certainty here is entirely dependent upon the ability of the IT organization to align its records control framework to a prescribed set of legal and regulatory requirements. Legal certainty represents significant value at risk for many corporations that absorb sizeable litigation exposure each year.

The alignment of IT and legal functions needs to be conceptualized, planned, executed, measured, monitored and assured. Aligning them is not a simple task and can require significant rethinking, but it is vital that both parties understand the rationale for the linkage between them and the roles they play. For example, the Legal Department’s understanding of the types of data, subject to legal holds and destruction must be connected with IT’s understanding of the affected underlying data. Legal will determine the records stored and deleted, but IT will need to provide evidence that retention rules have been implemented. Such evidence creates legal certainty. Legal needs to be aware of current data organization, location and accessibility, and IT should be capable of establishing a chain of custody with provable authenticity. Allegations of delinquent response can be avoided by establishing, and consistently executing, precise communication protocols between Legal and IT.

Getting this alignment right requires methodology and process. Methodology is often overlooked, but is necessary in precisely translating legal requirements into traceable operational requirements, which can be broad and deep. Process can be substantiated through a formalized Responsible, Accountable, Consulted and Informed (RACI) framework, which articulates actions and allocates roles. As an example, policy approval is a role connecting Legal and IT, with Legal formally endorsing regulatory taxonomies. This provides legal certainty and assurance for the IT function so that retention and disposition rules can be applied to all storage devices.

Compliance transparency

In general, it is becoming more important for an organization to be able to quickly provide evidence of their compliance with regulations. Expectations are rising and there is a cultural shift in many organizations away from control frameworks dedicated to how a company dealt with exposure, toward more organic frameworks which seek to measure how risk events are controlled and how problems can be averted before exposure is realized.

The vast majority of records exposure a company faces resides in the past. The first step towards achieving compliance transparency is to make a conceptual split between the past and the future.

A technology roadmap is a logical starting point for considering past exposure. Roadmaps serve to baseline existing records technology capabilities against prevailing regulatory, business and technical requirements. Roadmaps include governance, alternative solution architectures (such as a records shared-service paradigm), implementation strategies and appropriate standards to reduce the cost and complexity of the current environment. All roadmap requirements should be derived from expected benefits, such as improved discoverability. In the case of regulatory requirements, effort is well spent in establishing traceability from legal rules to functional requirements that will withstand the scrutiny of substantive audit testing as a proxy for court scrutiny.

Selecting a robust records management application (RMA) is critical. RMA’s should be capable of locating data outside the network topological map, as are SharePoint servers and online collaboration tools such as Google Docs. They should be able to sift through unstructured content with text analysis and apply ontological classification enabling the information to be coherently indexed and classified. RMA’s should be capable of categorization. This enables retention and disposition rules to be applied and enforced. It also supports legal holds by searching for relevant data then moving that data to a “legal hold categorized” repository.

In terms of the future, the vehicle of IT Governance is of particular use. Control Objectives for IT (COBIT) processes related to system development, technical change management and the service level management are worthy of focus as recipients of records management requirements. Development and implementation of records risk controls in these three areas invariably creates leading indicators of control, rather than traditional lagging indicators of exposure event trends. This directly supports the realization of compliance transparency.

Data retention

Data retention is becoming a real focus for Privacy Commissioners in Europe. This is due to rapid technological development in the areas of data mining supported by personal data fueled business models, and an increasing awareness of the impact this has on privacy rights. What many organizations are also beginning to realize is that data retention can have a substantial impact on the level of trust that exists between businesses and their customers.

One systematic weakness in information lifecycle management, impacting upon data retention, is that in many cases the “time factor” of user access is still not given sufficient attention by organizations. The “time factor” means that there are different people with varying business needs who access information throughout the information lifecycle.

Increasing volumes of new and unique information are being generated by organizations every year. This data, in all its media forms, held within corporate groups and their business partners, needs to be retained for a finite period of time. Not surprisingly, this is presenting organizations with both practical and legal challenges.

There are two main reasons for retaining the data. Firstly, it can serve useful purposes in addition to the reason for which it was originally collected, typically including customer profiling and meeting new legislative requirements. Secondly, storing the data is often a more pragmatic solution than destroying it.

What we know from our member firms’ work in this area is that search tools have improved (in particular, search technologies for unstructured text/data – a high-growth area in the Business Intelligence market), making it far easier to efficiently access large amounts of data. Furthermore, systems rarely enable the user to delete selected fields; it is often all or nothing. This results in whole data sets being retained when only subsets can be stored compliantly.

In managing the information lifecycle, many organizations still repeatedly fail to pay sufficient attention to user access, which has an impact on retention. KPMG firms often see inadequate processes, and the time factor is typically not considered when determining levels of access. However, time is an important consideration, as many users do not need access throughout the entire information lifecycle. Many staff do not need to access stored data at all in order to fulfill their business roles. For example, front-end customer support staff can comply with applicable bookkeeping regulations without the need to call up stored data. Similarly, account staff do not have a business need to access information about customers stored in CRM systems.

Insufficient access controls and deletion routines frequently lead to fundamental privacy principles being contravened, as large volumes of personal information become accessible to people with little or no business need to use the information. In the days of paper storage, this was not a problem. Records were physically moved into archives. But with data stored electronically, inappropriate access to information is now a major concern.

Figure 2. Data Retention Staircase

The Data Retention Staircase is neither a solution nor a methodology, but illustrates the challenge of access controls and data retention., assisting an organization in mitigating the risks of potentially illegal storage.

The vertical axis of the Data Retention Staircase in Figure 2 depicts the volume of personal data. The horizontal axis depicts time. The employees in dark blue are those with an actual need to access the data. The employees in grey have access, but no business need. Importantly, this model illustrates that legitimate access to data is required by fewer people over time, so that in planning storage and access, regular re-assessments of both employee needs and storage requirements should be made.

Data retention can be managed effectively, without the need for systems overhaul, by following a six-step process:

Create an overview of the personal information being processed in the company. In some cases, Operational Risk process definitions are well suited to establish information lifecycles.
Map all relevant legal requirements (including business needs, if they contribute to the rationale) relating to data storage and any additional purposes identified in Step 1.
Assess current retention levels and policies against requirements throughout the information lifecycle.
Identify the staff with access to information and map them against the purpose for processing the data.
Provide a view of all gaps:
1. Information kept without a defined purpose
2. Individuals with access but no established need.
Close gaps:
1. Delete excess information
2. Embed and enforce appropriate access controls.

Controlling storage costs

Nothing is growing as fast as the production of information to the extent that associated storage costs have outstripped falling per-gigabyte storage costs, improvements to drive capacity and disk performance. The “save everything” approach does not make economic sense (and neither is it a recommended litigation management strategy), while storage reduction solutions such as de-publication can create problems with legal admissibility of records. A typical organization holds between 10 and 30 copies of each document. Many of these are no longer needed; some are misplaced or even unknown. Storage optimization and process efficiency have become important business objectives.

Process improvements and a well thought-out infrastructure strategy are key factors in controlling storage growth. Records requirement, in many cases, needs to be incorporated into business processes through automatic content analysis, identification and classification.

Infrastructure strategy encompasses many elements. Duplicate management, e-mail filtering and archiving, backup, data center approach, tape restoration and data classification all play a part. But infrastructure strategy also considers the presentation layer. Records functionality will need to become abstracted into common user interfaces, particularly e-mail, providing users with support for identification and categorization. Consequently, employees will become increasingly responsible for identifying and classifying records.

In computing, virtualization is a broad term that refers to the abstraction of computer resources typically at the platform, storage, resource or network layer. In virtualization, users do not necessarily know what resources they are using. In enterprise environments those resources usually are controlled by the company, but the resources can also be external, which means that it is difficult to know where that data will be stored, processed and transferred.

Virtualization of storage helps achieve location independence by abstracting the physical location of the data. The virtualization system presents the user with a logical space for data storage and handles the process of mapping data to its actual physical location. This means that the data can reside at several locations and in locations unknown to the user. In virtual storage the host only deals with the logical space. Any changes to the meta-data mapping are transparent to the host, meaning the data can be moved or replicated to another physical location without affecting the operation of any client.

In storage virtualization the physical storage resources are aggregated into storage pools, which can be added as and when needed, with the virtual storage space scaling up by the same amount. Many data retention policies state that data must not be stored beyond the end of its lifecycle. When the data is scattered in different physical disks in the storage pool, it is difficult to physically destroy the disk containing the record. Therefore these records need to be erased from the virtual storage using other means, such as specific software that is designed to reliably erase data from disks. On the more positive side, since multiple independent storage devices appear to be a single monolithic storage device they can be managed centrally, which can help in data lifecycle management. Although a virtual storage infrastructure benefits from a single point of logical disk and replication service management, the physical storage must still be managed. For example, faulty disks need to be identified, properly destroyed and replaced.

Meta-data is a key component in virtualization, since once the data has been virtualized, the meta-data is the only thing making it possible to access the information. If the meta-data is lost, so is all the actual data, since it is virtually impossible to reconstruct the logical drives without the mapping information. Hence it is important to be able to reconstruct the meta-data in the event of a failure. Meta data has also been admissible in US court proceedings.

Conclusion

As structured and unstructured records grow in both the volume and the risk they represent, it becomes more important for organizations to re-think the processes by which they manage records. Are they adequate today and will they suffice for tomorrow are questions well worth asking.

Case studies

Case Study 1 – Global Financial Services Company

For a global financial services company, KPMG created an inventory of all electronic record types, defined a compliance framework in accordance with the company policy and standard operating procedures, established the internal controls for record repositories and processes, and conducted risk and gap analysis by determining nonconformity with the company’s e-compliance framework. KPMG worked closely with senior management to develop a remediation strategy and a plan to correct the gaps.

Case Study 2 – Retail Correspondent Clearing Firm

KPMG performed a records retention process improvement program specifically for account records for a large retail and correspondent clearing firm. Current state policies, processes, and documentation were identified and desired state polices and processes developed with operations and technology management. The team prepared process-improvement observations with recommendations for change, and provided a roadmap for addressing open issues.

Case Study 3 – Manufacturing Company

KPMG managed the development of the regulatory and legal requirements for a corporate retention schedule for a manufacturing company. KPMG led a risk appetite workshop with key stakeholders to understand the organization’s “risk appetite” and designed a corporate-wide program to meet regulatory compliance demands.

Case Study 4 – Insurance Company

As part of an overall legal and compliance process review, KPMG assessed an insurance company’s policies, processes, and procedures for creating, maintaining, accessing, and destroying pertinent company records. Of particular concern were records relating to policy forms and producer licensing information, thus a comprehensive program was developed.

Case Study 5 – Utilities Company

For a large southeastern U.S. utilities client, KPMG was tasked with

developing an enterprise information security program,
developing a dynamic and sustainable compliance program,
developing performance metrics to be utilized in assessing operational and business performance, and
designing, implementing, and managing an enterprise information management and protection program.

Ervaringen met geïntegreerde IT-controleraamwerken

Ondernemingen ervaren een aanzienlijk grotere regeldruk dan vijf à tien jaar geleden, zo ook op het vlak van de beheersing van informatietechnologie. Door wet- en regelgeving en interne richtlijnen op het gebied van bijvoorbeeld informatiebeveiliging, IT compliance, IT General Controls, en operational risk management kost het organisaties veel (dubbel) werk om interne en externe partijen te voorzien van de nodige verantwoordingsinformatie. In de praktijk bestaat een grote overlap tussen de controledoelstellingen of controlemaatregelen waaraan voldaan moet worden. Daarom wordt naarstig gezocht naar één integraal kader voor de beheersing van de IT-omgeving (IT-controleraamwerk) waar CFO’s en controllers, CIO’s, security managers, risk managers, compliance officers, interne auditors en accountants op kunnen steunen. Dit komt neer op een eenduidig stelsel aan controlemaatregelen waaraan de organisatie moet voldoen en waar zij op haar beurt ook andere partijen aan moet houden. De uitkomsten van twee workshops op het KPMG IT Najaarsevent vormen de basis voor dit artikel over de stand van zaken van en ervaringen met geïntegreerde IT-controleraamwerken.

Inleiding

Regeldruk

De laatste jaren staan ondernemingen onder een toenemende regeldruk. Nationale en internationale wetgeving verplicht ondernemingen inzicht te geven in de kwaliteit van de financiële verantwoording. Voorbeelden zijn de gevolgen van de Sarbanes Oxley[Sarbanes-Oxley Act of 2002 – 23 januari 2002.] (SOx)-wetgeving voor aan Amerikaanse beurzen genoteerde ondernemingen en voor de Nederlandse corporate governance code van de commissie-Tabaksblat[De Nederlandse corporate governance code – Beginselen van deugdelijk ondernemingsbestuur en best practice bepalingen – 9 december 2003.]. Voor het bank- en verzekeringswezen geldt aanvullende wetgeving zoals de Wet op het financieel toezicht (Wft)[Wet houdende regels met betrekking tot de financiële markten en het toezicht daarop – 28 september 2006.] en Basel II[Basel Committee on Banking Supervision, Principle 1 – Framework for Internal Control Systems in Banking Organisations – september 1998 en Basel Committee on Banking Supervision, International Convergence of Capital Measurement and Capital Standards – juni 2006.]. Maar ook de overheid staat onder grotere druk om de privacy van burgers te waarborgen (Wbp)[Wet houdende regels inzake de bescherming van persoonsgegevens – 6 juli 2000.] en om vertrouwelijke en staatsgeheime informatie te classificeren en naar rato te beschermen (VIR-BI)[Voorschrift informatiebeveiliging rijksdienst – bijzondere informatie – 1 maart 2004.].

C-2009-0-Wolters-f1

Deze trend vertaalt zich ook door naar het IT-werkveld. Security managers, compliance officers, risk managers en internal auditors ervaren een wirwar aan overlappende IT-kaders waarover de onderneming dient te rapporteren. Zo rapporteert de CFO over SOx-artikel 404 en functiescheiding, de security manager over ISO 27002[BS ISO/IEC 27002:2005.], de CIO over onder meer IT-dienstverleningsniveaus en de kwaliteit van ITIL-processen, alsook de interne auditor en huisaccountant over General IT Controls en IT-governanceraamwerken zoals COSO[Enterprise Risk Management – Integrated Framework – september 2004.] en Cobit[Cobit 4.1 – 2007.]. De meeste organisaties hanteren hierbij intern ontwikkelde policies, richtlijnen en baselines voor IT-beheer en -beveiliging.

Het gevolg hiervan is dat veel dubbel werk plaatsvindt. Vanwege de diverse, onafhankelijke rapportageverplichtingen worden veel IT controls meervoudig gecontroleerd en gerapporteerd. Het is dan ook niet vreemd dat vrijwel alle grote en middelgrote ondernemingen op zoek zijn naar een efficiëntere manier om verantwoordingsinformatie te verzamelen over het ‘in control’ zijn van de IT-functie. Niet alleen om dubbel werk te voorkomen, de IT-organisatie te ontlasten en eventueel kosten te besparen, maar ook om tijdiger te kunnen rapporteren. Veel organisaties worstelen namelijk met de periodiciteit en tijdigheid van verantwoordingsrapportages en komen hierdoor in de problemen met hun toezichthouders. Tevens kan door een organisatie op deze manier een gemeenschappelijk kader voor beheersing van de IT-omgeving worden gecreëerd, wat het spreken van gedeelde taal van alle relevante partijen ten aanzien van beheersing en controle van de IT-omgeving doet bevorderen.

De controleomgeving

De controleomgeving van middelgrote en grote ondernemingen bestaat uit een groot aantal in- en externe wet- en regelgevers en andere stakeholders zoals klanten en leveranciers. Deze stakeholders willen via wetten, richtlijnen en contracten invloed uitoefenen op de mate van beheersing van informatietechnologie, temeer als de organisatie sterk afhankelijk is van haar IT voor de betrouwbaarheid en continuïteit van de bedrijfsvoering. Als antwoord op de eisen van de stakeholders dient de IT-organisatie verantwoordingsinformatie te overleggen over de mate waarin is voldaan aan deze eisen. Bij voorkeur wordt deze verantwoordingsinformatie getoetst door een onafhankelijke partij, waardoor meer zekerheid of ‘assurance’ afgegeven kan worden dat daadwerkelijk aan de eisen is voldaan.

In figuur 1 is een schema opgenomen waarin deze controleomgeving is gevisualiseerd.

C-2009-0-Wolters-01

Figuur 1. De controleomgeving van een willekeurige IT-organisatie.

Outsourcing als drijfveer tot rationalisatie

Deze behoefte tot rationalisatie van kaders voor de beheersing van IT wordt nog eens versterkt door de trend om de IT te outsourcen. Veel ondernemingen zetten hun IT-beheer- en -ontwikkelingsactiviteiten buiten de deur. IT-dienstverleners streven naar verregaande standaardisatie van hun IT-dienstverlening en hebben hun werkprocessen doorgaans ingericht volgens open standaarden of ‘good practice guidelines’. Daarnaast leidt het uitbesteden van IT volgens de richtlijnen en baselines van de opdrachtgever tot maatwerk voor de IT-dienstverlener en daarmee tot hogere kosten. Ook dit is voor ondernemingen een extra drijfveer om zowel intern als richting IT-dienstverleners met één IT-controleraamwerk op basis van open standaarden te werken.

Wanneer bijvoorbeeld het beheer van (delen van) een IT-omgeving is uitbesteed, is het gebruikelijk dat over deze dienstverlening een assuranceverklaring (SAS 70, TPM of anderzijds) wordt verkregen van een externe auditor. Deze auditor wordt meestal aangewezen door de leverancier. In het geval van financiële dienstverleners of banken is dit zelfs door toepasselijke wet- en regelgeving noodzakelijk.

Ook in dergelijke gevallen kan een IT-controleraamwerk dienst doen als referentiekader voor de eisen die de organisatie stelt aan de beheersing van haar IT-omgeving. Het IT-controleraamwerk moet dan wel zijn opgenomen als onderdeel van het contract tussen de uitbestedende organisatie en haar leverancier. De externe auditor die een assuranceverklaring afgeeft, zal in de praktijk in overleg met zijn opdrachtgever een selectie maken van de controls in het IT-controleraamwerk die als relevant worden beschouwd voor de uitbestede IT-diensten.

Basisprincipes geïntegreerde IT-controleraamwerken

Structuur

Een geïntegreerd IT-controleraamwerk is een kader waarin alle relevante IT-richtlijnen zijn gekoppeld aan universele controledoelstellingen. Tevens kunnen deze controledoelstellingen gekoppeld zijn aan of verder uitgewerkt zijn in controlemaatregelen of controls. Het merendeel van de organisaties die bezig zijn met een integraal framework, hanteert Cobit 4.x als ‘kapstok’ en zoekt naar manieren om vanuit de controledoelstellingen die in Cobit[Cobit bestaat uit een deming cycle van Plan and Organise, Acquire and Implement, Deliver and Support, en Monitor and Control. Deze hoofdonderdelen vallen uiteen in diverse high level control objectives (zoals bijvoorbeeld Manage Changes of Ensure System Security). Deze high level control objectives zijn op hun beurt weer onderverdeeld in detailed control objectives.] zijn opgenomen relaties te leggen met de diverse interne en externe regelgeving.

C-2009-0-Wolters-02

Figuur 2. Structuur integraal IT-controleraamwerk.

In figuur 2 is de structuur van een geïntegreerd IT-controleraamwerk schematisch weergegeven. Vanuit de diverse interne en externe wetten, regelgeving en richtlijnen wordt een koppeling of ‘mapping’ gemaakt naar relevante gedetailleerde controledoelstellingen uit Cobit. Op dat moment zijn de diverse eisen uit de wet- en regelgeving dus verzameld in één eenduidige set van controledoelstellingen.

Volledig en herbruikbaar

Onze ervaring leert dat veel organisaties steunen op een selectie van Cobit controls die door de organisatie van belang wordt geacht. Zelden wordt een integraal control framework opgebouwd aan de basis: de verschillende wet- en regelgeving waar de noodzaak van het framework mee begon. Indien organisaties daadwerkelijk inzichtelijk willen krijgen welke beheersingsdoelstellingen gehaald dienen te worden vanuit specifieke wet- en regelgeving, zal een mapping gemaakt moeten worden van deze wet- en regelgeving naar (bijvoorbeeld) de Cobit-controledoelstellingen (control objectives).

De koppelingen van relevante wet- en regelgeving voor een specifieke branche naar controledoelstellingen kunnen voor alle organisaties in die branche worden gebruikt. Daarnaast wordt met het gebruik van Cobit als model voor de controledoelstellingen een algemene standaard geïntroduceerd die breed is geaccepteerd. Hoewel herbruikbaar dient het raamwerk te allen tijde afgestemd te worden met en goedgekeurd te worden door de betrokken functionarissen binnen en buiten de organisatie, zoals de externe accountant.

De kracht zit ‘m niet in de details

Aangezien een aantal wet- en regelgevers zeer gedetailleerde eisen stelt aan de IT-organisatie is het soms noodzakelijk om deze controledoelstellingen nog nader uit te werken. Daarvoor worden algemeen geaccepteerde specifieke maatregelensets (zoals ISO-normen en andere standaarden) gebruikt. Ook dan vindt een koppeling plaats van de gedetailleerde controledoelstellingen van Cobit naar deze specifieke maatregelen of controls. Zie ook de onderzijde van figuur 2.

De kracht van een geïntegreerd IT-controleraamwerk wordt vooral bereikt wanneer deze op het niveau van gedetailleerde controledoelstellingen van Cobit is uitgewerkt en de diverse betrokken partijen, zoals IT-dienstverleners, de vrijheid behouden om zelf een keuze te maken voor de invulling van specifieke maatregelen, mits de controledoelstellingen maar worden gehaald.

Uitkomsten workshop: waar staan organisaties nu?

Workshops

Tijdens het KPMG IT Najaarsevent hebben de auteurs een tweetal workshops gehouden met in totaal circa veertig deelnemers. De deelnemers waren afkomstig uit een diversiteit aan organisaties (banken, verzekeringsmaatschappijen, industriële ondernemingen, overheidsinstanties, IT-serviceproviders) en hadden zeer verschillende functies (CIO, CFO, hoofden risk management, hoofden internal audit). In deze workshops is de deelnemers met behulp van een interactief stemsysteem een aantal vragen gesteld over drijfveren, de stand van zaken en verwachte merites van geïntegreerde IT-controleraamwerken.

Hieronder volgt een samenvatting van de belangrijkste resultaten van de workshops:

Meer dan driekwart van de deelnemers ziet voordelen bij de implementatie van een geïntegreerd IT-controleraamwerk (figuur 3).

C-2009-0-Wolters-03

Figuur 3. Zien de deelnemers voordelen bij de implementatie van een integraal IT-controleraamwerk?

Uit de workshops bleek dat zestig procent van de deelnemende organisaties nog geen geïntegreerd IT-controleraamwerk heeft of bezig is om dit te ontwikkelen. De overige veertig procent gaf aan al te beschikken over een dergelijk raamwerk (figuur 4).

C-2009-0-Wolters-04

Figuur 4. Hebben de organisaties van de deelnemers reeds een geïntegreerd IT-controleraamwerk?

Driekwart van de deelnemers gaf aan te moeten voldoen aan meer dan vier verschillende typen wet- en regelgeving op het vlak van IT-beheersing. Een kwart gaf zelfs aan te maken te hebben met meer dan zeven verschillende typen wet- en regelgeving op dit vlak (figuur 5).

C-2009-0-Wolters-05

Figuur 5. Aan hoeveel verschillende typen wet- en regelgeving moeten de organisaties van de deelnemers naar schatting voldoen?

Hetzelfde bleek het geval te zijn voor het aantal externe en interne partijen waaraan de IT-organisaties van de aanwezigen verantwoording dienen af te leggen. Driekwart legt aan meer dan vier verschillende partijen verantwoording af over de beheersing van IT.
Tweederde van de deelnemers geeft aan te steunen op meer dan drie IT-dienstverleners voor beheer, onderhoud en/of ontwikkeling van IT. De helft daarvan heeft zelfs meer dan zeven IT-dienstverleners (figuur 6).

C-2009-0-Wolters-06

Figuur 6. Op hoeveel IT-dienstverleners steunt de organisatie voor beheer, ontwikkeling en onderhoud van IT?

Tweederde van de deelnemers geeft aan de assurance-informatie die IT-dienstverleners aanleveren niet direct of in het geheel niet te kunnen relateren aan de voor de organisatie relevante wet- en regelgeving. Dit wil zeggen dat in tweederde van de gevallen nog een vertaalslag nodig is ter verantwoording aan de stakeholders van de betreffende organisaties.
Geen van de aanwezigen ziet hierbij kostenverlaging als belangrijkste drijfveer. Als eerste worden genoemd ‘efficiencyverhoging’ en ‘overall zekerheid over IT-controle’ en vervolgens ‘verbeteren van transparantie’ en ‘verbeteren effectiviteit van IT-controle’ (figuur 7).

C-2009-0-Wolters-07

Figuur 7. Belangrijkste drijfveer voor de organisatie om een integraal IT-controleraamwerk in te richten?

Alle aanwezigen verwachten dat het implementeren van een geïntegreerd IT-controleraamwerk een meerjarentraject is.

Volwassenheidsmodel

Om een beeld te geven van waar organisaties staan in de ontwikkeling van geïntegreerde IT-controleraamwerken, hebben de auteurs een volwassenheidsmodel opgesteld. In figuur 8 is dit model grafisch weergegeven.

C-2009-0-Wolters-08

Figuur 8. Volwassenheidsmodel geïntegreerde IT-controleraamwerken.

In tabel 1 zijn de vijf niveaus nader toegelicht.

C-2009-0-Wolters-t01

Tabel 1. Volwassenheidsmodel voor het hanteren van geïntegreerde IT-controleraamwerken.

Net als bij de meeste volwassenheidsmodellen betreft niveau 5 ‘Single audit’ hier een niveau waarnaar gestreefd kan worden, maar wat uiteindelijk voor veel organisaties slechts een ijkpunt zal zijn dat in de nabije toekomst niet snel zal worden gehaald. Uit de workshops bleek dat vrijwel alle deelnemers zich op niveau 0 tot en met 3 bevinden. Drie deelnemers (nog geen tien procent) schatten in dat zij op niveau 4 actief zijn. Geen van de deelnemers bevindt zich op niveau 5.

Praktijkervaringen

Het opzetten van een geïntegreerd IT-controleraamwerk zoals hiervoor geschetst is geen sinecure. Het vergt de nodige ervaring met de betreffende wet- en regelgeving en ook met de ins en outs van modellen zoals Cobit. De diverse wet- en regelgeving geeft veel ruimte voor interpretatie. Ook de betrokken partijen hebben vanuit hun eigen achtergrond een eigen voorkeur voor de interpretatie van deze wet- en regelgeving en de wijze van koppeling van de wet- en regelgeving aan de Cobit controls.

Vaststellen raamwerk

De belangrijkste uitdagingen bij het vaststellen van een geïntegreerd IT-controleraamwerk zijn:

het vaststellen welke regelgeving allemaal voor de organisatie van toepassing is én relevant is voor de IT-omgeving;
de specifieke vertaling van eisen vanuit de wet- en regelgeving naar eisen voor de IT-omgeving van de organisatie;
het verkrijgen van overeenstemming over de inhoud van het raamwerk en de diepgang waarmee het raamwerk wordt opgezet;
het interpretatieloos vastleggen van de controles in het IT-controleraamwerk;
het overtuigen van de betrokken partijen dat door één uniform IT-controleraamwerk in te voeren en te steunen op de controles van anderen, de mate van beheersing van de IT-omgeving niet minder wordt.

In figuur 9 is een voorbeeld gegeven van de vastlegging van een IT-controleraamwerk zoals dat voor een organisatie in de financiële sector is vormgegeven.

C-2009-0-Wolters-09

Figuur 9. Voorbeeld van een IT-controleraamwerk.

In deze figuur is voor het onderdeel AI6.1 Manage Changes / Change Standards and Procedures uit Cobit 4.1 te zien aan welke in- en externe wet- en regelgeving deze gedetailleerde controledoelstelling is gekoppeld. Daarnaast is een duidelijk onderscheid gemaakt tussen het aantal keren dat de control is gekoppeld aan interne en externe wet- en regelgeving. Ook is aangegeven hoe vaak de control in totaal is gekoppeld. Deze statistische informatie kan belangrijke uitgangspunten bieden bij het bepalen van het belang van een bepaalde controledoelstelling. Het mag duidelijk zijn dat de mate waarin de interne en externe wet- en regelgeving gekoppeld is aan een controledoelstelling, indiceert in hoeverre de controledoelstelling een belangrijke bijdrage levert aan de beheersing van de IT-omgeving van de organisatie.

In figuur 10 is als voorbeeld een gedeelte van een koppeling van ISO 27001 naar Cobit 4.1 weergegeven.

C-2009-0-Wolters-10

Figuur 10. Voorbeeldmapping ISO 27001.

Gebruik raamwerk

In onze ervaring is het opzetten en vastleggen van het raamwerk echter niet het moeilijkste onderdeel van de implementatie. Wanneer het raamwerk uiteindelijk is vastgelegd, is de grootste hobbel die nog genomen moet worden, het daadwerkelijk in gebruik nemen van het framework.

De lijn- en IT-organisatie dienen de juiste controls te selecteren bij de controledoelstellingen en deze door te voeren in IT-processen en -procedures. Waar nodig dienen interne controles te worden uitgevoerd op de juiste werking van deze controls. De controlerende stafafdelingen en externe toezichthouders, in het bijzonder de externe accountant, dienen op basis van dit model reviews, controles en audits uit te voeren. In geval van uitbesteding van de IT-dienstverlening dient een deel van deze controls te worden overgedragen aan IT-dienstverleners, wat wil zeggen dat gesteund moet worden op verantwoordingsinformatie die door de IT-dienstverlener wordt verstrekt, bijvoorbeeld in de vorm van een TPM of SAS 70-verklaring.

De belangrijkste uitdagingen bij het implementeren van een geïntegreerd IT-controleraamwerk zijn:

het maken van duidelijke afspraken over de wijze waarop invulling wordt gegeven aan het IT-controleraamwerk. Wie gaan met het raamwerk werken en op welke manier?
het bepalen van de manier waarop toetsing door de controlerende instanties (intern en extern) plaatsvindt. Is dit op basis van de controledoelstellingen of dient het raamwerk nog te worden uitgebreid naar meer gedetailleerde controles?
het bepalen van de manier waarop het raamwerk aan mogelijke externe partijen wordt gecommuniceerd.
het zorgen voor eigenaarschap van het IT-controleraamwerk, maar ook voor eigenaarschap van de koppelingen met wet- en regelgeving, zodat wijzigingen in wet- en regelgeving ook worden doorgevoerd in het raamwerk.

Aan het einde van dit artikel zijn de belangrijkste succesfactoren voor het implementeren van een geïntegreerd IT-controleraamwerk kort samengevat.

C-2009-0-Wolters-f2

Ruben de Wolf geeft een nadere toelichting over het IT-controleraamwerk tijdens de terugkoppelingssessie.

Conclusies

Een goed functionerend geïntegreerd IT-controleraamwerk kan een zegen zijn voor een organisatie die gebukt gaat onder de zoveelste auditor, externe toezichthouder of certificerende instantie die langskomt om voor de zoveelste keer in hetzelfde jaar dezelfde vragen te stellen aan net die ene medewerker die al overladen is met werk. Met de juiste expertise en middelen, de juiste mindset bij de stakeholders en de bereidheid van partijen om te steunen op het werk van anderen kan een dergelijk raamwerk voor werklastverlichting zorgen.

Daarnaast heeft een dergelijk raamwerk ook nog andere voordelen, zoals:

transparantie (in- en extern één taal spreken ten aanzien van beheersing);
effectiviteit (voorkomen van blinde vlekken in de aanpak);
kostenverlaging;
verhogen van de overall zekerheid over de beheersing van de IT-omgeving;
toegevoegde waarde naar klanten.

Vooral organisaties die te maken hebben met een groot aantal verschillende toezichthouders en met diverse typen wet- en regelgeving op het vlak van IT-beheersing en die met meerdere IT-dienstverleners zaken doen, kunnen baat hebben bij een dergelijk raamwerk.

Het succes van de invoering van een geïntegreerd IT-controleraamwerk is zowel afhankelijk van de intrinsieke kwaliteit van het raamwerk, als van de mate waarin de betrokken partijen bereid zijn om het raamwerk te adopteren en te steunen op elkaars controleresultaten. In de kern komt dit neer op een deel van de eigen IT-controlewerkzaamheden durven loslaten. Hierin dient ons inziens de externe IT-auditor een voortrekkersrol te vervullen. Niet alleen beschikt deze over een gedegen kennis van relevante wet- en regelgeving en passende controleraamwerken, ook is de externe IT-auditor één van de belangrijkste spelers die moet durven loslaten en zijn controleaanpak meer systeemgericht dient in te richten.

Belangrijkste succesfactoren voor de implementatie van een geïntegreerd IT-controleraamwerk:

Betrek alle partijen direct vanaf het begin bij de totstandkoming van het raamwerk.
Neem voldoende tijd voor de uitwerking van het raamwerk, net als bij zoveel zaken is ook in dit geval haastige spoed zelden goed.
Stel duidelijk vast welke partijen stakeholder zijn en neem al deze partijen stap voor stap mee in de totstandkoming van het raamwerk.
Maak gebruik van interne of externe expertise op het gebied van het te gebruiken IT-controleraamwerk (bijvoorbeeld Cobit), de te koppelen interne en externe wet- en regelgeving en de meer gedetailleerde standaarden met concrete maatregelen en procedures.
Formuleer de reikwijdte van het raamwerk en communiceer dit aan de stakeholders.
Tracht een zo integraal mogelijk model vast te stellen.
Borg een actieve bijdrage vanuit de verschillende disciplines binnen de (lijn)organisatie.
Zorg voor een werkbare tool waarin de koppeling tussen de verschillende interne en externe wet- en regelgeving goed kan worden geadministreerd.
Gebruik voor deze koppeling één integraal raamwerk zoals Cobit.
Zorg voor een zorgvuldig en geformaliseerd afstemmingsproces.
Beleg het eigenaarschap van het totale IT-controleraamwerk.
Maak afspraken over de wijze waarop na vaststelling met het raamwerk zal worden gewerkt.
Maak zoveel mogelijk gebruik van algemeen geaccepteerde koppelingen tussen de verschillende standaarden en wet- en regelgeving, bijvoorbeeld van ISACA (zij heeft diverse standaardmappings van wet- en regelgeving naar Cobit).

Afweging tussen businessflexibiliteit en control via functiescheiding

Functiescheiding en een goede taakverdeling zijn basisvoorwaarden voor een adequate besturing en beheersing van een organisatie. Echter, de vraag is tot hoever je functiescheiding moet doorvoeren. En wat is het risico indien meerdere kritische taken door eenzelfde persoon worden uitgevoerd? De meningen verschillen hier nog wel eens tussen enerzijds businessmanagers en projectleiders en anderzijds risicomanagers en auditors. De auteurs geven in dit artikel (óók vanuit een businessmanagersoptiek) inzicht hoe met deze problematiek op een praktische manier kan worden omgegaan.

Inleiding

Dit artikel is interessant voor de auditor en de adviseur die de achtergrond en redenen voor functiescheiding willen kennen en willen weten op welke wijze deze efficiënt en effectief kan worden ingericht. En voor organisaties die bezig zijn of op het punt staan een ERP-pakket te implementeren en concreet inhoud willen geven aan de inrichting van functiescheiding. Ook is dit artikel interessant voor managers die een brug willen slaan van flexibele organisaties naar effectieve risicobeheersing.

Functiescheiding en een goede taakverdeling zijn basisvoorwaarden voor een adequate besturing en beheersing van een organisatie en worden al jaren toegepast. Maar … slechts enkele organisaties zijn in staat functiescheiding echt effectief in te richten met als resultaat een goed beheersbare maar ook werkbare situatie. Dit blijkt uit verschillende onderzoeken op het gebied van SOx en Basel II ([GeMc05; Doyl06]), waarbij functiescheiding een van de belangrijke gebieden is waarop organisaties vaak een materiële tekortkoming rapporteren. In een van deze onderzoeken, waarbij de disclosures van 261 bedrijven zijn onderzocht, komt naar voren dat functiescheiding op nummer vijf staat van de meest voorkomende materiële tekortkomingen. Zie hiervoor figuur 1.

C-2008-3-Roest-01

Figuur 1. Aantal materiële tekortkomingen in internal control per deficiency type ([GeMc05])

Historisch gezien heeft het gebrek aan functiescheiding een belangrijke rol gespeeld in verliezen die zijn geleden bij banken. Denk bijvoorbeeld aan het spraakmakende faillissement van Barings in de jaren negentig en zeer recent een van de grootste fraudegevallen in de geschiedenis bij Sociéte Générale, waarbij dit bedrijf miljarden heeft verloren doordat één eigen medewerker in staat was (zeer verliesgevende) posities in te nemen zonder dat hij gecorrigeerd werd door zijn leidinggevenden. Een goede scheiding van bevoegdheden inclusief de juiste inrichting van signalerings- en verantwoordingsinformatie had dit mogelijk kunnen voorkomen.

Uit onderzoek ([Litt03]) komt ook naar voren dat de opinie van interne en externe auditors over functiescheiding veelal een belangrijke graadmeter is voor het beoordelen van het totale risicobeheersingsraamwerk van een organisatie. Dit is ook de ervaring van de auteurs.

Dit artikel gaat in op de afweging die gemaakt dient te worden tussen businessflexibiliteit en control via functiescheiding. De problematiek en randvoorwaarden om deze afweging op een verantwoorde manier te kunnen maken, worden ook nader beschreven. Het artikel is gebaseerd op ervaringen bij diverse grote internationale organisaties met zowel grote als kleine businessunits. Afwegingen, problematiek en randvoorwaarden voor succes zijn echter ook toepasbaar voor kleinere organisaties. Wij sluiten dit artikel af met onze visie op dit onderwerp.

Theoretische aspecten

Controlemaatregelen

Om bedrijfsprocessen ‘in control’ te houden worden de volgende vier soorten controlemaatregelen toegepast:

Preventieve maatregelen worden toegepast om vooraf de kans op schade of ongewenste handelingen te voorkomen. Voorbeelden van preventieve beheersingsmaatregelen zijn functiescheiding, geprogrammeerde systeemcontroles en de aanwezigheid van antivirussoftware.
Repressieve maatregelen zijn erop gericht de schade te verminderen. Hierbij valt te denken aan gescheiden netwerken om de impact van een virus te beperken.
Detectieve maatregelen worden toegepast om achteraf te ontdekken of ongewenste handelingen zich hebben voorgedaan, bijvoorbeeld het controleren van rapportages.
Correctieve maatregelen worden gebruikt om ongewenste handelingen te corrigeren en de situatie weer te herstellen, zoals het gebruik van back-upfaciliteiten.

Bedrijven maken gebruik van alle vier de maatregelen. Voorkomen is echter beter dan repareren. Preventieve maatregelen zoals functiescheiding en repressieve maatregelen genieten daarom de voorkeur. Echter, vanwege de afweging tussen het risico en de benodigde middelen om preventieve maatregelen te implementeren komen de andere soorten maatregelen veelvuldig voor. Bovendien kan men niet preventief grip houden op alle risico’s.

Wat is functiescheiding

Functiescheiding is gebaseerd op het creëren van belangentegenstellingen en voorkomt dat een enkeling verantwoordelijk is voor meerdere opeenvolgende kritische handelingen in een bedrijfsproces, die mogelijkerwijs tot onregelmatigheden kunnen leiden die niet tijdig en gedurende de normale procesgang ontdekt worden ([CISA05]). Voorkomen moet worden dat slechts één persoon ongecontroleerd transacties of verplichtingen kan aangaan, autoriseren, verwerken en afwikkelen en toegang heeft tot activa ([DNB01]).

Aan functiescheiding zijn twee voordelen verbonden:

Bewust fraude plegen wordt ontmoedigd omdat hiervoor samenwerking van twee of meer personen nodig is.
De kans dat onbedoelde fouten optreden door het handelen van één enkele medewerker, is geringer.

Toepassing van functiescheiding

Autorisaties in het systeem zijn dé manier om functiescheiding strikt in te richten. Uiteraard zal er ook altijd functiescheiding buiten het systeem bestaan, maar de inrichting van autorisaties biedt de mogelijkheid om scheiding echt af te dwingen en is bovendien een efficiënte controle. Echter, het komen tot een goede inrichting waarbij een volledige scheiding bestaat tussen de handelingen, kijkrechten/rapportages en tussen de verschillende afdelingen van de organisatie is lastig te realiseren. Zo is de kwaliteit van de inrichting van het SAP R/3-autorisatieconcept in veel gevallen nog onvoldoende ([Vree06]). De praktijkervaringen van de auteurs sluiten hierbij aan. De auteurs hebben in diverse software-implementaties de risicomanagement- en/of kwaliteitsbewaking (quality assurance) -rol ingevuld en in deze projecten kwam het geregeld voor dat de autorisaties op het allerlaatste moment nog ingericht moesten worden op basis van vaak onvolledige informatie en met onvoldoende aandacht voor beheerprocedures.

Een aantal basiseisen voor functiescheiding is bij de meeste managers bekend. Hieronder vallen de bevoegdheden tot betalen, het storten van geld, het beoordelen van de bankafschriften en het aangaan van verplichtingen met leveranciers of klanten. Dit zijn meestal individuele kritische stappen die gescheiden worden van andere taken in een proces. Scheiding over de processen heen wordt vaak onvoldoende meegenomen. Ook wordt er inefficiënt te werk gegaan doordat functiescheiding niet aan het begin van het bedrijfsproces adequaat is ingeregeld, en hierdoor worden ook de voordelen van het ERP-pakket onvoldoende benut. Bij gebruik van een ERP-pakket waarbinnen handelingen uitgevoerd kunnen worden op basis van toegekende autorisaties is het vaak minder evident hoe een persoon bewust of onbewust onwenselijke handelingen kan uitvoeren. Dit vereist inzicht in het autorisatiemanagementsysteem. Bovendien is functiescheiding breder dan de autorisaties alleen. Activiteiten buiten het ERP-pakket kunnen immers essentieel zijn om te scheiden, zowel onderling als van activiteiten in het systeem.

Praktijkvoorbeeld

Probleemsituatie

In een praktijkvoorbeeld bij een grote internationale organisatie met grote en kleine businessunits wordt gebruikgemaakt van standaardprocessen met standaardrollen voor het toekennen van taken en verantwoordelijkheden. Op centraal niveau is hiervoor een functiescheidingsmatrix opgesteld. In deze matrix waren conflicten over processen heen niet gedefinieerd. Ook waren er afwijkingen tussen de formele taken van rollen en de autorisaties in het ERP-pakket. In de functiescheidingsmatrix waren alleen verboden rolcombinaties aangegeven zonder toelichting of risicobeschrijving. Bovendien werden er geen mogelijkheden geboden om bepaalde rolcombinaties toch toe te staan bij een gering risico en met de implementatie van compenserende maatregelen. Daarnaast werd in de functiescheidingsmatrix geen rekening gehouden met specifieke verschillen tussen de businessunits. Bepaalde rolcombinaties werden hierdoor onmogelijk terwijl deze voor een aantal businessunits geen grote risico’s met zich meebrachten. Hierdoor was het voor risicomanagers niet goed uit te leggen waarom bepaalde rolcombinaties binnen de business verboden waren. Ook voor de interne auditdienst was dit een probleem. Het gevolg was dat met name in kleinere businessunits de centrale beleidsrichtlijnen slecht werden nageleefd. Bovendien werd op de naleving van centrale beleidsrichtlijnen beperkt gecontroleerd. Vandaar dat er werd besloten een verbeteringstraject op te starten.

Gekozen aanpak voor verbetering

Om functiescheiding effectief en efficiënt toe te passen is het noodzakelijk om zowel op centraal als op decentraal niveau een aantal activiteiten uit te voeren. De activiteiten kunnen worden doorlopen zoals aangegeven in figuur 2. Tevens zijn enkele randvoorwaarden van toepassing om transparantie en draagvlak te creëren en te behouden.

C-2008-3-Roest-02

Figuur 2. Stappen voor het gebruik van een organisatiebrede functiescheidingsmatrix.

Centrale activiteiten

Stap 1. Creëer commitment

Zorg ervoor dat er vooraf commitment is van alle belangrijke stakeholders (inclusief Managing Board) voor een bedrijfsbrede functiescheidingsmatrix. Uit onze praktijkervaring is gebleken dat het hier vaak aan schort, waardoor er bij het valideren en later bij het implementeren onvoldoende draagvlak bestaat. Een heldere governancestructuur, waarbij centrale beleidsrichtlijnen formeel belegde stappen doorlopen ter goedkeuring, kan hier zeker bij helpen.

Stap 2. Gebruik standaardrollen

Een functiescheidingsmatrix is op verschillende manieren in te steken. Dit kan op basis van functies, op basis van taken en verantwoordelijkheden, op basis van autorisaties in het systeem, of op basis van standaardrollen. Een functiescheidingsmatrix op basis van functies biedt te weinig flexibiliteit voor de inrichting op businessunitniveau. Op basis van taken en verantwoordelijkheden ontstaat vaak een onnodig complexe situatie, waarbij niet eenvoudig duidelijk is bij wie welke activiteit belegd kan worden; bovendien zal een aantal activiteiten tussen de businessunits verschillen waardoor een uniforme matrix onhaalbaar is. Wanneer alleen gekeken wordt naar autorisaties, wat goed mogelijk is, worden alle essentiële activiteiten die buiten het ERP-pakket plaatsvinden niet meegenomen. Wanneer gebruik wordt gemaakt van standaardbedrijfsprocessen waarbij standaardrollen de essentiële activiteiten van deze bedrijfsprocessen uitvoeren, is een belangrijke basis gelegd voor het implementeren van functiescheiding op rolbasis. Hiermee is het mogelijk breder te kijken dan de autorisaties in het systeem, is eenvoudig inzichtelijk welke persoon wat mag en wordt voldoende flexibiliteit geboden aan de businessunits om de juiste mensen op de juiste plek in te zetten.

Het is belangrijk om businessunits flexibiliteit te geven voor eigen invulling, maar wel de essentiële activiteiten in de standaardprocessen strikt te scheiden. Het gebruik van standaardrollen biedt deze mogelijkheid. Het is aan de business om te bepalen aan welke personen deze standaardrollen worden gegeven. Tussen de businessunits zullen hierdoor verschillen ontstaan in de toewijzing. Zij bepalen immers zelf de functies met bijbehorende rollen die de organisatie het beste past. Dit is geen enkel probleem omdat scheiding tussen bepaalde activiteiten wel afgedwongen wordt via de rolcombinaties in de functiescheidingsmatrix.

Deze flexibiliteit is een belangrijke voorwaarde voor support binnen de organisatie. Hier treden echter ook vaak problemen op. Om de organisatie draaiende te houden, zeker in het geval van een beperkt aantal personeelsleden of bij ziekte/uitval van medewerkers, krijgen medewerkers vaak ruimere bevoegdheden dan wenselijk is vanuit een risicoperspectief. Daarnaast is het zo dat de kans dat bewuste of onbewuste fouten worden gemaakt, wordt onderschat. De meeste managers hebben een groot (vaak grenzeloos) vertrouwen in hun medewerkers en verzaken daarmee het toepassen van een correcte functiescheiding omdat het in hun ogen vooral geld kost, een hoop problemen veroorzaakt, het vertrouwen van het personeel schaadt en weinig tot niets oplevert.

Stap 3. Definieer principes

Starreveld beschrijft scheiding tussen de registrerende, beschikkende, bewarende, controlerende en uitvoerende functie ([Star02]). Enkele basiselementen van functiescheiding zoals beschreven door Starreveld blijken niet meer goed toepasbaar. Zo is de strikte scheiding tussen de uitvoerende functie en de registrerende functie niet meer van deze tijd. Bijvoorbeeld in een ERP-pakket worden via primaire transacties vrijwel gelijktijdig journaalposten in het grootboek gemaakt zonder dat de eindgebruiker hier weet van heeft. Het nastreven van deze functiescheiding heeft in moderne goed uitgeteste ERP-omgevingen vrijwel geheel zijn kracht verloren. De principe-insteek hoeft echter niet losgelaten te worden.

Door het evalueren van de waardekringloop, zoals weergegeven in figuur 3, is een opzet gemaakt op welke punten functiescheiding vereist is. Grootboekadministratie en stamgegevens zijn hierin als aparte functiegebieden opgenomen. Tussen de verschillende uitvoerende (lichte) stappen en bewarende (donkere) stappen zijn bij het combineren risico’s onderkend. In de figuur is aangegeven waar scheiding als essentieel wordt gezien. Daarnaast is binnen de processtappen zelf scheiding aangebracht tussen het zetten van doelen en standaarden (targets) en het ermee werken. Ook tussen het controleren van deze doelen en standaarden en het ermee werken is scheiding aangebracht. Tevens is besloten een scheiding aan te brengen tussen alle autoriserende taken binnen het verkoopproces en het inkoopproces. Dit heeft geresulteerd in zeven principes die als basis dienen om functiescheiding toe te passen (de relatie met de basisprincipes van Starreveld is opgenomen in tabel 1).

C-2008-3-Roest-03

Figuur 3. Waardekringloop met voorbeelden van functiescheiding.

C-2008-3-Roest-04

Tabel 1. Toegepaste principes voor functiescheiding.

Stap 4. Classificeer risico’s

In de organisatiebrede functiescheidingsmatrix is gekozen om te werken met drie risicocategorieën. Deze zijn respectievelijk laag, gemiddeld en hoog risico. Combinaties van rollen met een laag onderling risico zijn toegestaan. Natuurlijk zal er nog wel gekeken moeten worden of de betreffende persoon over de juiste kwalificaties beschikt en of voor het betreffende organisatieonderdeel geen aanvullende risico’s gepaard gaan met de combinatie. Het competentievraagstuk is echter geen onderdeel van de functiescheidingsmatrix.

Rolcombinaties met een gemiddeld onderling risico zijn toegestaan mits hiervoor aanvullende maatregelen zijn getroffen. Hierbij valt te denken aan een extra maandelijkse rapportage die gecontroleerd wordt of een inperking qua financiële of autorisatietechnische bevoegdheden.

Rolcombinaties met een hoog onderling risico zijn niet toegestaan. Door de onderlinge combinatie van deze rollen worden dusdanige bevoegdheden gegeven dat er een reële kans is op grote fouten of fraude.

Deze indeling is gekozen omdat gebleken is dat een strikte scheiding vanuit risicoperspectief niet altijd nodig is. Wanneer bijvoorbeeld wordt gewerkt met goederen die niet interessant zijn voor persoonlijke verrijking of eenvoudigweg niet zijn mee te nemen, is het risico met betrekking tot verduistering zeer gering. De combinatie tussen goederenontvangst, -opslag en -uitgifte kan hierdoor een mogelijke combinatie zijn.

Stap 5. Maak risicobeschrijvingen

Er is voor gekozen om bij iedere rolcombinatie met een gemiddeld risico of hoog risico een risicobeschrijving toe te voegen. Deze risicobeschrijvingen zijn met name gebaseerd op financiële, operationele en compliancerisico’s. Bij het afstemmen van het ontwerp van de matrix ontstond veel discussie waarom bepaalde rolcombinaties niet mogelijk waren. Procesmanagers hadden hierbij het idee dat bepaalde combinaties geen risico’s opleveren, aangezien die combinaties de gebruikelijke situatie binnen de unit weergeven. Door het opnemen van goed doordachte risicobeschrijvingen wordt het voor medewerkers duidelijk welke risico’s met de combinatie gepaard gaan en zal er eerder bereidheid ontstaan om organisatiewijzigingen door te voeren.

Bij een vervolgproject kwam naar voren dat bepaalde rolcombinaties wel een hoog risico vormden indien externe verplichtingen werden aangegaan, maar dat indien de verplichtingen tussen businessunits onderling werden aangegaan het risico beperkt is. Dit is vervolgens toegevoegd in de betreffende risico-omschrijvingen. Het aantal te treffen compenserende maatregelen is hierop ook af te stemmen.

Bij het beoordelen van verzoeken om af te wijken van de functiescheidingsmatrix dient goed geëvalueerd te worden of de afwijking terecht is gezien het risico, en vervolgens of de matrix of risicobeschrijving hierop wellicht aangepast dient te worden. Het kan ook zijn dat dit zeker niet wenselijk is, maar dat het een tijdelijke situatie betreft door het niet beschikbaar hebben van voldoende personeel door bijvoorbeeld ziekte. Het is aan de business om hier rekening mee te houden en waar mogelijk back-upoplossingen te creëren die voldoen aan de gestelde functiescheidingseisen. Dit zal bij audits ook naar voren komen.

Stap 6. Organiseer validatiesessies

Na het opzetten van de functiescheidingsmatrix op basis van standaardrollen zijn diverse validatiesessies gehouden met alle belangrijke stakeholders zoals risk managers op businessunitniveau, proceseigenaren en businessmanagers om de functiescheidingsmatrix te toetsen. Bij deze discussies kwamen specifieke businessvoorbeelden naar boven die inzicht gaven of een bepaalde combinatie wel of niet mogelijk moest zijn, wanneer risicovolle combinaties toch toegestaan konden worden en onder welke specifieke voorwaarden.

Stap 7. Publiceer

Publiceer de functiescheidingsmatrix zodat deze voor de hele organisatie beschikbaar is. Na publicatie is het essentieel om ondersteuning te leveren bij de implementaties. Dit zorgt voor draagvlak en geeft zekerheid dat er op een juiste manier mee wordt omgegaan.

Ondersteuning

Het gebruik van tools voor het realiseren van functiescheiding en het monitoren is belangrijk. Echter, het beoogde doel dient bij de keuze hiervan niet uit het oog te worden verloren. Standaardtools bieden goede manieren om te kijken welke systeembevoegdheden bij eenzelfde persoon zijn belegd. Ze geven inzicht in welke kritische taken door wie uitgevoerd worden en kunnen uitkomst bieden om te kijken wie welke bevoegdheden in het systeem ook werkelijk nodig heeft. Een aantal tools biedt zelfs de mogelijkheid om naar meerdere applicaties te kijken. Buiten het systeem om verliezen deze tools echter hun waarde. Voor meer informatie over de inrichting van bijvoorbeeld SAP-autorisatietools zie [Hall08].

Audit

Audits op de implementatie geven garantie dat er ook werkelijk gewerkt wordt met de functiescheiding zoals beoogd. Audits worden nu vaak alleen uitgevoerd op de toegekende autorisaties in het systeem. Functiescheiding is breder en gaat over de totale toekenning van bevoegdheden. Daarom is het belangrijk om inzicht in het totale bedrijfsproces te hebben voor het geven van een juist oordeel. Voor audits op de toegekende autorisaties worden vaak standaardtools gebruikt waarbij veelal geen rekening wordt gehouden met de opgestelde functiescheidingsmatrix. Uiteraard is het interessant om te evalueren wat de verschillen zijn en waarom iets bijvoorbeeld wel is toegestaan volgens de functiescheidingsmatrix. Laat het duidelijk zijn dat hier soms bewuste redenen voor kunnen zijn doordat mitigerende maatregelen al standaard in het bedrijfsproces zijn ingebakken en het risico van de gegeven autorisatie daarmee is ingeperkt.

Doorvoeren verbeteringen

Organisaties zijn onderhevig aan verandering, dit moet ook voor de functiescheidingsmatrix gelden. Het is niet de bedoeling om continu verbeteringen door te voeren. Documentatie en tools dienen immers aan te sluiten en de kans dat de interne audit dienst en de businessunits grip verliezen op de eisen wordt hierdoor vergroot. Bij aanpassingen in de processen of rollen en op basis van herevaluaties is het mogelijk bijvoorbeeld jaarlijks in een update te voorzien.

Randvoorwaarden

Daarnaast is het van groot belang dat de rollen zoals opgenomen in de functiescheidingsmatrix niet afwijken van:

de centrale beleidsrichtlijnen;
de aanwezige rolbeschrijvingen;
de procedures en procesbeschrijvingen;
de autorisaties in het ERP-pakket.

Het in lijn houden van documentatie, regels en autorisaties in het systeem is geen eenvoudige opgave. Afspraken wanneer en op welke manier wijzigingen kunnen worden doorgevoerd, zijn hierbij van belang. Hierdoor is voor iedereen duidelijk waarover gesproken wordt en hoe de conflicten in de functiescheidingsmatrix zich verhouden tot de bedrijfsprocessen.

Decentrale activiteiten

Stap 8. Impact assessment

Tijdens deze stap wordt gekeken in hoeverre de functiescheidingsmatrix aansluit bij de huidige manier van werken en de toegekende autorisaties in het systeem. Bij het implementeren van een nieuwe functiescheidingsmatrix zullen deze verschillen waarschijnlijk groot zijn. Op basis van deze inventarisatie kan bepaald worden welke projecten gestart kunnen worden om te gaan voldoen. Het is immers niet een kwestie van de autorisaties in het systeem op orde brengen, maar de mensen ook werkelijk op de nieuwe manier laten werken. Dit traject is natuurlijk al gestart bij het standaardiseren van de processen, echter er is nog veel ruimte voor eigen invulling in de toekenning van de rollen aan personen. Deze toekenning dient uiteindelijk wel in lijn te zijn met de functiescheidingsmatrix.

Stap 9. Risicoanalyse

Nadat vastgesteld is wat de issues zijn bij de huidige manier van werken, dient bepaald te worden wat de mogelijke oplossingen zijn. Hierbij moeten de risico’s van de organisatiewijzigingen worden geëvalueerd. Het gaat hier niet om de risico’s van de rolcombinaties – deze zijn immers al beschreven op centraal niveau –, maar wel om de impact van de wijzigingen op de businessunit. Het verplaatsen van taken en bevoegdheden vraagt om adequaat verandermanagement. Uit de risicoanalyse kan volgen dat bepaalde activiteiten en autorisaties bij andere personen belegd dienen te worden of dat activiteiten en autorisaties wel bij dezelfde persoon kunnen blijven, maar dat compenserende maatregelen nodig zijn zoals het draaien van een additioneel controlerapport of het invoegen van een extra goedkeuringsstap. In deze fase wordt de risicobereidheid bepaald door een afweging te maken tussen businessflexibiliteit en control (zie figuur 4).

Stap 10. Implementeer wijzigingen/mitigerende maatregelen

Deze activiteit vergt meer inspanning dan vaak wordt gepland. Het wijzigen van de businessunit en de manier van werken vergt tijd en middelen. Hiermee dient rekening te worden gehouden bij het opstellen van de functiescheidingsmatrix, omdat een te rigide matrix veel extra werk en kosten met zich meebrengt. Het blijft voor de organisatie ten slotte een afweging tussen flexibiliteit en control. Flexibiliteit geeft meer vrijheid en minder kosten, maar brengt ook meer risico. Deze afweging staat centraal.

Monitor & Rapporteer

In hoeverre wordt voldaan aan de functiescheidingsmatrix dient gemonitord te worden. De redenen waarom bepaalde verboden combinaties toch aanwezig zijn, dienen gerapporteerd te worden aan het businessmanagement en te worden voorgelegd aan de centrale organisatie. Ook de getroffen mitigerende maatregelen dienen gedocumenteerd te worden en te worden goedgekeurd door de risicomanager van de businessunit en het management. Hierdoor is binnen de businessunit duidelijk dat er bewust is nagedacht over de afwijkingen en is tijdens een audit ook helder welke afwijkingen geconstateerd zullen worden.

C-2008-3-Roest-05

Figuur 4. Afweging businessflexibiliteit en control.

Complexiteit bij kleine businessunits

Vooral in kleine businessunits levert functiescheiding nogal eens problemen op. Vaak beschikken zij niet over het benodigde aantal fte’s voor het invullen van een organisatiebrede functiescheidingsmatrix. Om toch te kunnen voldoen aan centrale beleidsrichtlijnen kan het noodzakelijk zijn om additioneel personeel aan te trekken. Deze oplossing heeft vaak niet de voorkeur in verband met de aanzienlijke personeelskosten. Een andere optie is om bepaalde processen te centraliseren op een meer centraal niveau, dit kan bijvoorbeeld met shared service centers. Voorbeelden van processen die vaak gecentraliseerd worden, zijn masterdatamanagement, het doen van betalingen en het definiëren, monitoren en controleren van bedrijfsprocessen. Een voorwaarde voor het succesvol (intern) uitbesteden van processen is standaardisatie en tot op zekere hoogte ook de harmonisatie van data. De auteurs hebben in de praktijk meegemaakt dat een shared service center op tien verschillende ERP-systemen inlogde voor het uitvoeren van een centraal proces. Dit is een verre van ideale situatie.

Echter, bepaalde activiteiten moeten nu eenmaal lokaal gebeuren. Vooral in landen waar direct contact met leveranciers en klanten essentieel is en activiteiten rondom facturatie lokaal moeten gebeuren. Bovendien wordt hier vaak niet met langlopende contracten gewerkt en in veel gevallen zelfs nog met contant geld betaald. Wanneer standaardprocessen niet of niet volledig worden gebruikt, moeten additionele controlemaatregelen worden getroffen.

Het is dan ook zinvol hier een risicoanalyseaanpak te gebruiken. Het startpunt is de meest kritieke activiteiten zoveel mogelijk te centraliseren op bijvoorbeeld regionaal niveau. De essentiële functies lokaal en de scheiding daartussen, daarnaast het beperken van het risico door bijvoorbeeld afspraken te maken over maximale aankopen of verkopen door de unit zelf. Een controlerende taak vanuit de overkoepelende organisatie blijft natuurlijk een must. Hierbij valt te denken aan het maken van vergelijkingen van data tussen businessunits, en het periodiek uitvoeren van onafhankelijke reviews om afwijkingen van de procedures te constateren.

De absolute ondergrens van kleine businessunits dient ook te worden bepaald, aangezien het voor hen onmogelijk is om volledige functiescheiding te realiseren. De ervaring van de auteurs is dat zelfstandige businessunits tussen de tien en vijftig fte problemen hebben met het realiseren van volledige functiescheiding. In grote organisaties wordt deze zelfstandigheid voor belangrijke en risicovolle processen opgeheven en worden deze processen gecentraliseerd (bijvoorbeeld op regionaal niveau). Voor businessunits met minder dan tien fte is het praktisch gezien onmogelijk om volledige functiescheiding te realiseren. Het beperken van risico’s door het centraliseren van activiteiten en inperken van de financiële mogelijkheden biedt hier uitkomst.

Conclusie & visie auteurs

Het implementeren van functiescheiding op een dusdanige wijze dat voldoende scheiding wordt gerealiseerd en een goed werkende situatie ontstaat, is een lastige klus. Een kapstok hiervoor is het gebruik van standaardprocessen. Het doel is immers niet het voldoen aan opgelegde eisen maar het neerzetten van effectieve en ‘in control’ zijnde bedrijfsprocessen. Om dit voor de gehele organisatie helder te krijgen dient gewerkt te worden op basis van begrijpbare principes. Deze principes zijn eenvoudig te communiceren en zorgen voor draagvlak binnen de organisatie. Risicobeschrijving bij rolcombinaties geeft inzicht, wat extra zal bijdragen aan support binnen de organisatie. In kleine organisaties zal vooral de focus moeten liggen op het beperken van het risico. Hier liggen uitdagingen bij het centraliseren of uitbesteden van bepaalde processen en het inperken van bijvoorbeeld financiële mogelijkheden. Op basis van een goede risicoanalyse, waarbij de echte business- en procesrisico’s in kaart worden gebracht, is het mogelijk een juiste afweging te maken tussen strikte functiescheiding en flexibiliteit binnen de business.

Wanneer het risico van een bepaalde combinatie van activiteiten beperkt is heeft het geen zin om een scheiding aan te brengen. Sterker nog, dit zal alleen maar weerstand oproepen binnen de organisatie. Wanneer niet goed is uit te leggen waarom een bepaalde scheiding nodig is, zal het functiescheidingsmodel niet of onvoldoende gedragen worden en verworpen worden om de business doorgang te laten vinden. Hiermee zullen ook de wel essentiële scheidingen in twijfel worden getrokken. Het is dus belangrijk om hier niet dogmatisch naar te kijken en de business te betrekken bij het ontwerp. Vaak is het ook mogelijk andere maatregelen te treffen om risico’s te mitigeren. Te denken valt in dat opzicht aan het stellen van tolerantielimieten, bijvoorbeeld een kleine unit waar de inkoopfunctie (aanvraag, goedkeuring, order) gecombineerd wordt maar waarbij alleen inkopen tot een bepaald bedrag mogen plaatsvinden en een bepaald volume per maand of jaar. Dit is in de huidige ERP-systemen goed inzichtelijk te maken.

Het geven van ondersteuning aan de businessunits bij het communiceren en implementeren van functiescheiding is noodzakelijk. Er zal hierdoor meer bereidheid ontstaan om te voldoen, zeker wanneer het gevoel ontstaat dat er ook werkelijk rekening wordt gehouden met de specifieke businesssituatie en -problemen. De specifieke situatie kan ook nieuw inzicht verschaffen om de eisen aan te passen. Hierbij blijft de risicogebaseerde aanpak essentieel. Het blijven voldoen aan de functiescheidingsmatrix vereist inzicht bij de businessunits. Zij zijn immers verantwoordelijk voor de toekenning van taken en bevoegdheden aan het personeel. Bij het monitoren of wordt voldaan aan de opgelegde eisen, is inzicht nodig in wat bij welke persoon is belegd. De inzet van tooling is belangrijk in sterk geautomatiseerde omgevingen. Wel is het essentieel dat er op dezelfde manier wordt gekeken naar functiescheiding, bij voorkeur op rolbasis, en dat niet alleen naar de toegekende autorisaties wordt gekeken, maar ook naar activiteiten buiten het systeem. Standaard-autorisatiescans kunnen een goede indicatie geven van problemen, maar het werkelijke risico betreft het totaal van maatregelen in de bedrijfsprocessen. Onze verwachting is dat er meer producten op de markt zullen verschijnen die hierop inspelen en de mogelijkheid bieden voor een goede aansluiting met de bedrijfsprocessen. Meer inzicht in de mogelijkheden voor risicobeheersing zal het gevolg zijn en daardoor kan naar verwachting een betere afweging worden gemaakt tussen businessflexibiliteit en control.

Literatuur

[Aren02] A.A. Arens and J.K. Loebbecke, Auditing: an integrated approach, Eighth Edition, Prentice Hall, Upper Saddle River, New Jersey, 2000.

[CISA05] Segregation of Duties within Information systems; CISA Review Manual 2005, pp. 88-91; www.isaca.org/cisabooks.

[DNB01] De Nederlandse Bank, Richtlijnen Organisatie en Beheersing, 2001, www.dnb.nl.

[Doyl06] Jeffrey Doyle, Weili Ge and Sarah McVay, Determinants of weaknesses in internal control over financial reporting, 2006.

[Gart07] Paul E. Proctor, Jay Heiser, Neil MacDonald, MarketScope for Segregation of Duties Controls Within ERP, 2007, R2183 05222007.

[GeMc05] Weili Ge and Sarah McVay, The Disclosure of Material Weaknesses in Internal Control after the Sarbanes-Oxley Act, Accounting Horizons, Vol. 19, No. 3, September 2005, pp. 137-158.

[Hall08] D. Hallemeesch en A. Vreeke, De schijnzekerheid van SAP-autorisatie-tools, Compact 2008/2.

[KPMG06] KPMG Practice Aid – Segregation of Duties, 2006, 673d0ef31.

[Litt03] Adam G. Little and Peter J. Best, A Framework For Separation Of Duties In An SAP R/3 Evironment, Managerial Auditing Journal, XVIII (5), 2003, pp. 419-430.

[Over00] P. Overbeek, E.R. Lindgreen en M. Spruit, Informatiebeveiliging onder controle: grondslagen, management, organisatie en techniek, 2000.

[Star02] R.W. Starreveld, O.C. van Leeuwen en H. van Nimwegen, Bestuurlijke informatieverzorging Deel 1: Algemene grondslagen, 2002.

[Vree06] A. Vreeke en D. Hallemeesch, ‘Zoveel functiescheiding in SAP – dat kan nooit’, en waarom is dat eigenlijk een risico?, Compact 2006/2.

Oracle eBS en een geautomatiseerde gegevensgerichte controle

Ontwikkelingen in de toepasbaarheid van tools op het gebied van governance, risk and compliance (GRC) bieden niet alleen mogelijkheden tot een efficiëntere uitvoering van de jaarrekeningcontrole, maar ook tot het verder uitbouwen van beheersingsmaatregelen in de administratieve organisatie. De IT-auditor is de spil in het aanreiken van mogelijkheden op dit gebied naar zowel de klant als de accountant van de klant. Oracle heeft deze ontwikkeling op het gebied van GRC onderkend en dit jaar Oracle GRC gelanceerd.

Inleiding

De invoering van de regelgeving die de betrokkenheid van de IT-auditor vereist bij controleklanten van een bepaalde omvang, heeft ertoe geleid dat de IT-auditor steeds meer wordt ingezet bij werkzaamheden in de internal en external audit. Veelal betreft dit het beoordelen van de IT general controls van de te beoordelen systemen en de application controls die onderdeel uitmaken van deze systemen. De kennismaking tussen het vakgebied van de accountant en IT-auditor heeft als bijkomend effect geleid tot een groeiend aantal initiatieven waarbij gezocht wordt naar nieuwe wegen om tot een efficiëntere wijze van het uitvoeren van een jaarrekeningcontrole met behulp van de inzet van de IT-auditor te komen.

Parallel aan deze ontwikkeling binnen de accountancy is een steeds verdergaande ontwikkeling zichtbaar op het gebied van tools die het analyseren van gegevens in ERP-systemen gemakkelijker maken. Deze tools worden in toenemende mate door zowel de IT-auditor als de gebruiker gehanteerd ([Brou07]).

Dit artikel heeft als doel het pad te verkennen en gebieden te identificeren waar door geautomatiseerde gegevensgerichte controle efficiencyverbetering haalbaar is bij het toetsen van beheersingsmaatregelen in omgevingen waar gebruik wordt gemaakt van het ERP-systeem Oracle eBS.

Controlebenaderingen

Tijdens de jaarrekeningcontrole richt de accountant zijn werkzaamheden op het vaststellen van de inhoudelijke juistheid van de verantwoording in de jaarrekening. Bij het opstellen van de controleaanpak bepaalt de accountant welke controlebenadering wordt gehanteerd.

Controlebenaderingen waar de accountant onder meer uit kan kiezen zijn:

De systeemgerichte controlebenadering. Deze benadering richt zich op de adequate werking van de AO/IC van de organisatie. Bij het toetsen van de AO/IC gaat de aandacht onder meer uit naar beheersingsdoelstellingen van het type IT general controls en application controls, die zijn ingericht in het administratieve systeem, het ERP-pakket. Het toetsen van de IT general controls en application controls is in de regel het werkterrein van de IT-auditor.
De gegevensgerichte controlebenadering. Deze benadering richt zich op toetsing op basis van cijferbeoordelingen, verbandcontroles en totaalcontroles, waarbij niet wordt gesteund op de mogelijk aanwezige beheersingsmaatregelen in de organisatie. Deze activiteiten zijn in de regel het werkterrein van de accountant ([West01]).

Vaak wordt gekozen voor een combinatie van de twee, waarbij systeemgerichte controlebenadering wordt aangevuld met gegevensgerichte controlebenadering. De analyse van de RoSM (Risk of Significant Misstatement) bepaalt in welke mate aanvullend gegevensgericht gecontroleerd moet worden. Voor deze analyse wordt onder meer gekeken naar de IT general controls en de application controls. Indien de toetsing van de IT general controls en de application controls aantoont dat beide categorieën van beheersingsmaatregelen effectief zijn, dan heeft deze vaststelling geen verhogend effect op de risk of significant misstatement (RoSM) en zal de accountant steunen op deze beheersingsmaatregelen. Zijn de beheersingsmaatregelen van de IT general controls en de application controls niet effectief, dan heeft dit mogelijk aanvullende gegevensgerichte werkzaamheden tot gevolg.

Hoewel het uitvoeren van de aanvullende gegevensgerichte werkzaamheden in de regel het werkterrein van de accountant is, is op dit terrein een toenemende betrokkenheid van de IT-auditor waar te nemen. De IT-auditor beschikt immers over tools die hem in staat stellen om gericht naar bepaalde, specifieke transacties te zoeken in het ERP-systeem en hierover te rapporteren. De omvang van de administratie is hierbij geen of nauwelijks een beperkende factor. Dit stelt de IT-auditor zelfs in staat de volledige populatie van transacties te onderzoeken op afwijkende, in het kader van de jaarrekeningcontrole, ongewenste transacties (volledig gegevensgerichte aanpak, controlebenadering 3). Vervolgens kan de IT-auditor de totale set aan ongewenste transacties in samenwerking met de accountant analyseren en rubriceren. Daarnaast kan de IT-auditor de juiste werking van de beheersingsmaatregelen aantonen door de geconstateerde afwijkingen te analyseren op basis van de volledige set transacties en gegevens (gegevensgericht de AO/IC testen).

De beschreven controlebenaderingen zijn in figuur 1 schematisch weergegeven.

C-2008-3-Nunen-01

Figuur 1. Schematische weergave van de drie controlebenaderingen.

Kenmerken van deze drie controlebenaderingen zijn:

De systeemgerichte controlebenadering richt zich op beheersingsmaatregelen in en rond het ERP-systeem. In geval van application controls betreft het controls die een bepaald gedrag van de administrateur afdwingen bij het vastleggen van transacties. Als aangetoond is dat de beheersingsmaatregelen effectief zijn, dan wordt verondersteld dat de vastlegging juist heeft plaatsgevonden. Echter, als niet aangetoond kan worden dat beheersingsmaatregelen effectief zijn, dan mag niet meer verondersteld worden dat de vastlegging juist heeft plaatsgevonden, wat effect heeft op de RoSM en aanvullende werkzaamheden. Toch is het niet ondenkbaar, dat ondanks een niet-werkende beheersingsmaatregel een juiste vastlegging heeft plaatsgevonden. Helaas biedt deze benadering geen handvatten voor deze situatie.
De (reguliere) gegevensgerichte controlebenadering concentreert zich primair op de opbouw vanuit de primaire registraties tot aan de financiële administratie, de rubricering en samenvatting in de saldibalans en tot slot de jaarrekening. In de top-downbenadering (de analytische controle) worden de primaire registraties alleen bekeken als daar aanleiding toe is vanuit de cijferbeoordeling. Als de aanleiding er is, dan wordt op basis van een aselect getrokken sample uit de registratie een uitspraak gedaan over de gehele registratie. Helaas biedt deze benadering van aselect sampling beperkt handvatten om de aandacht direct te richten op afwijkende transacties in de registraties. Het is bovendien mogelijk dat de getrokken sample geen afwijkende transacties bevat, terwijl deze wel bestaan.
De geautomatiseerde gegevensgerichte controlebenadering is als de reguliere gegevensgerichte controlebenadering, met het verschil dat in de geselecteerde primaire registraties direct gezocht kan worden naar afwijkende transacties, waarna een betere inschatting van de RoSM te maken is. Helaas staat of valt deze methode bij een betrouwbare werking van de tools waarmee de gegevens van de transacties uit het ERP-systeem worden gehaald.

In de volgende paragraaf wordt toegelicht op welke wijze de drie controlebenaderingen een uitwerking hebben in een Oracle eBS-omgeving.

De toegevoegde waarde van een geautomatiseerde gegevensgerichte benadering in een Oracle eBS-omgeving

Waarom is in een Oracle eBS-omgeving de geautomatiseerde gegevensgerichte benadering te verkiezen boven een systeemgerichte benadering?

Om deze vraag te kunnen beantwoorden moet gekeken worden naar het internecontrolerisico (het risico dat het administratieve stelsel een betekenisvolle onjuistheid niet heeft kunnen voorkomen) van een systeemgerichte controle van een Oracle eBS-omgeving. Voor dit ERP-systeem is de veronderstelde hardheid van een aantal, door de accountant vaak getoetste application controls zoals de 3-way match, betaaltermijnen, kredietlimieten in werkelijkheid niet zo hard. Dit heeft te maken met de filosofie waarmee Oracle eBS is opgezet; namelijk het bieden van flexibiliteit naar de gebruiker.

In Oracle eBS worden geprogrammeerde instellingen gebruikt om de gebruiker van het systeem zoveel mogelijk te faciliteren bij het invoeren van transacties door zoveel mogelijk velden automatisch te vullen volgens de geprogrammeerde instelling. Echter, deze door het systeem ingevulde veldwaarden zijn in standaard Oracle eBS overschrijfbaar voor degene die de transactie invoert. Hierdoor is er geen sprake meer van door de applicatie afgedwongen gedrag en wordt op dit moment in de regel de bevinding genoteerd dat de application control niet effectief werkt. Indien geen compenserende maatregelen zijn getroffen, heeft deze bevinding nadelige gevolgen voor de hoeveelheid door de accountant uit te voeren additionele gegevensgerichte werkzaamheden.

Bovengenoemde bevinding, hoewel juist vastgesteld volgens de definitie, hoeft niet te betekenen dat er sprake is geweest van een risico. Want hoewel de geprogrammeerde instelling in Oracle eBS slechts fungeert als een automatische veldwaardengenerator, is het toch mogelijk dat dit voldoende is om de gebruikers van het systeem het gewenste gedrag op te leggen. De vervolgvraag is daarom: Op welke wijze kan worden vastgesteld in welke mate de administrateur heeft afgeweken van de door het systeem standaard ingevulde veldwaarden?

De IT-auditor kan geautomatiseerde gegevensgerichte werkzaamheden uitvoeren in het IT-systeem, waardoor aangetoond kan worden aan de accountant, dat een application control niet gewerkt heeft, maar dat er geen of slechts een beperkt risico is geweest. De wijze waarop dit plaatsvindt zal in de volgende paragraaf worden toegelicht aan de hand van een voorbeeld over 3-way matching, de meest door de accountant gevraagde beheersingsmaatregel.

Een voorbeeld van geautomatiseerd gegevensgericht toetsen van een beheersingsdoelstelling

Een veelvuldig gehanteerde beheersingsdoelstelling is: ‘Alle crediteurenfacturen worden gevalideerd voordat tot betaling wordt overgegaan.’

Voor het halen van deze beheersingsdoelstelling wordt voor een groot deel gesteund op de beheersingsmaatregel die stelt dat de zogenaamde 3-way match plaatsvindt. De 3-way match is een geautomatiseerde validatie van een crediteurenfactuur op basis van een reeds eerder gecreëerde en gevalideerde inkooporder in combinatie met een registratie van de goederenontvangst of ontvangst van de ingekochte dienst.

In een aantal ERP-systemen, anders dan Oracle eBS, bestaat vaak een instelling in de applicatie die afdwingt dat voor bepaalde typen transacties een 3-way match vereist is ter validatie van een inkoopfactuur. In deze situatie kan een systeemgerichte controle gericht op de IT general controls en application controls volstaan om gerechtvaardigd te mogen steunen op de 3-way match als beheersingsmaatregel.

In Oracle eBS bestaat een dergelijke instelling ook. Echter, vanwege de filosofie van Oracle waarbij de flexibiliteit van Oracle eBS ten gunste van de klant prevaleert, is deze instelling, zoals eerder beschreven, niet dwingend van karakter. Er kunnen zich nu twee situaties voordoen:

De administrateur heeft in geen enkele transactie de standaardwaarde, 3-way match, aangepast. Alle transacties van het betreffende type zijn gevalideerd volgens de gewenste 3-way match. Deze bevinding betekent voor de accountant dat geen aanvullende, handmatige, gegevensgerichte werkzaamheden nodig zijn.
De administrateur heeft, om nog onbekende redenen en voor een onbekend aantal transacties, de vanuit de instelling voorgestelde 3-way match overschreven met een andere matchoptie, waarschijnlijk 2-way match. De 2-way match stelt uitsluitend de inkooporder als voorwaarde voor het valideren van de factuur. Hierdoor is het mogelijk dat de administratie facturen betaalt van goederen die niet geleverd zijn. Deze bevinding betekent voor de accountant dat aanvullende werkzaamheden uitgevoerd moeten worden om de materialiteit van deze afwijking te bepalen.

Voor het vaststellen van beide hier geschetste situaties kan de IT-auditor ondersteuning bieden aan de accountant door uitvoering van een geautomatiseerde gegevensgerichte controle.

De door de IT-auditor uitgevoerde werkzaamheden bestaan uit de volgende activiteiten:

Alle transacties van het betreffende transactietype in de te controleren periode worden opgevraagd.
De opgevraagde transacties worden gefilterd op transacties die afwijken van de standaard ingestelde 3-way match.

Indien geen afwijkingen gevonden worden, dan is vastgesteld dat sprake is van de eerste situatie. Indien afwijkingen zijn geconstateerd, dan is er sprake van de tweede situatie. De IT-auditor zal deze bevinding in ieder geval rapporteren aan de accountant. Dit betekent niet dat daarmee de werkzaamheden van de IT-auditor zijn afgerond. Want ook bij het uitvoeren van de aanvullende werkzaamheden kan de IT-auditor ondersteuning bieden aan de accountant. De IT-auditor beschikt immers over de gegevens van alle uitzonderingstransacties. Deze gegevens kunnen voor de accountant relevante informatie bevatten, op basis waarvan hij zijn aanvullende werkzaamheden kan bepalen.

De vervolgstappen zijn:

Vaststellen van de omvang van de afwijkende fractie. De fractie van de afwijkende transacties ten opzichte van de gewenste transacties wordt bepaald. Indien deze fractie klein genoeg is, kan de accountant besluiten dat de afwijking van niet materieel belang is en dat er dus geen aanvullende werkzaamheden nodig zijn.
Uitvoeren van een analyse van de afwijkende fractie. Uit de beschikbare gegevens kan worden afgeleid of er een bepaalde gemene deler is aan te duiden voor de afwijking. Indien de gemene deler is aan te duiden en deze toelaatbaar is, kan de accountant alsnog besluiten dat er geen noodzaak is om aanvullende werkzaamheden uit te voeren.
Bepalen van aanvullende werkzaamheden. Als is vastgesteld dat er geen gemene deler is voor de afwijkingen, of dat er sprake is van een niet toelaatbare oorzaak voor bepaalde afwijkingen, kan de accountant besluiten om een aanvullende gegevensgerichte controle uit te voeren.

De beschikbaarheid van detailinformatie van alle afwijkende of ongewenste transacties biedt de accountant meer mogelijkheden bij het bepalen van de aanvullende gegevensgerichte werkzaamheden. De accountant kan de aanvullende werkzaamheden immers volledig richten op de afwijkende transacties.

Toepasbaarheid op andere gebieden

Er zijn vele mogelijkheden om geautomatiseerde gegevensgerichte controle toe te passen. Hierbij valt bijvoorbeeld te denken aan automatisering van de volgende controlewerkzaamheden:

inzicht verschaffen in de volledigheid van facturatie;
vaststelling dat tegenover alle voor verzending afgeboekte goederen een daaraan gerelateerde factuur staat;
identificatie van potentiële inkoopfacturen die betrekking hebben op verplichtingen die zijn aangegaan in de voorgaande periode;
bepaling van het onderhanden werk;
identificatie van verkoopfacturen waarvan de boekingsdatum mogelijk is aangepast;
alle aspecten van autorisaties en functiescheiding.

Deze werkwijze kan uitgebreid worden naar andere werkzaamheden die traditioneel door de accountant zelf worden uitgevoerd.

Naast de werkzaamheden die door de accountant worden uitgevoerd, bestaan er ook mogelijkheden voor de gebruiker van Oracle eBS, de cliënt van de accountant. Deze kan dezelfde methodiek gebruiken om beheersingsmaatregelen in te richten in de eigen AO/IC, en wel:

Detectief toetsen van beheersingsmaatregelen. De cliënt voert periodiek een test uit, waarmee afwijkingen van de norm gesignaleerd worden. Op basis van de geconstateerde afwijkingen kan de cliënt maatregelen treffen.
Preventief toetsen van beheersingsmaatregelen. De applicatie signaleert op het moment dat een afwijking dreigt te ontstaan. De applicatie kan deze afwijking signaleren of actief voorkomen. In de laatste situatie is sprake van een application control, waar de accountant op kan steunen bij zijn werkzaamheden.

Tools ter ondersteuning van de geautomatiseerde gegevensgerichte controle

Onderstaande ontwikkelingen onderschrijven de tendens dat de laatste jaren de tools voor het analyseren van gegevens een snelle groei in volwassenheid en efficiëntie aan het doorlopen zijn.

De oorspronkelijke methode voor het verkrijgen van gegevens was voornamelijk gericht op het on-site verzamelen van de gegevens rechtstreeks vanaf een werkstation van de cliënt. In deze methode wordt gebruikgemaakt van de standaardrapporten van Oracle eBS. Voordeel van deze methode is, dat de juistheid van de gegevens gegarandeerd is. Nadeel is dat deze rapporten zich niet goed lenen voor analyse in Excel. Een ander nadeel van Oracle’s standaardrapporten is dat slechts een beperkt deel van de in het systeem aanwezige gegevens daar deel van uitmaakt. De kans is groot dat de door de standaardrapporten opgeleverde gegevens geen ondersteuning bieden aan de uit te voeren analyse van de afwijking.
Vervolgens heeft men zich gericht op het automatiseren van het verkrijgen van gegevens door middel van extractiescripts. De verkregen gegevens worden daarna verwerkt door bijvoorbeeld zelf in MS Access gebouwde tools. Voordeel van deze methode is, dat alle in het systeem aanwezige gegevens beschikbaar zijn voor de analyse. Nadeel is dat vraagtekens geplaatst kunnen worden bij de juistheid en volledigheid van de gerapporteerde gegevens. Eén factor die afbreuk doet aan de juistheid en volledigheid is de kans dat het datamodel van Oracle eBS niet juist door de bouwer van de MS Access-tool is geïnterpreteerd. Een andere factor is dat het niet ondenkbaar is dat de gebruiker van het Access-rapport onbewust een verkeerde selectie bij het ophalen van de gegevens opgeeft. Beide hebben de rapportage van ‘false positives’ tot gevolg, wat afbreuk doet aan de juistheid en volledigheid van de bevinding.

Een belangrijk kenmerk van deze methode is dat het efficiencyvoordeel pas te behalen valt als de Access-tool bij herhaling in te zetten is. Het bouwen van de tool vergt immers een investering. Deze investering is in het bijzonder gericht op het bouwen van de zogenaamde content. De content is een vertaling van de controleactiviteiten zoals deze verwoord zijn in het werkprogramma van de accountant, naar de te rapporteren gegevens ter onderbouwing van die controleactiviteiten.

Naarmate de tijd vordert vereist de zelfbouwtool bovendien onderhoud. Dit onderhoud is gericht op het synchroon houden van de scripts met de Oracle-releases. Immers, na elke release bestaat de mogelijkheid dat uit te lezen tabellen zijn gewijzigd, waardoor het script niet meer werkt.
De volgende stap is dat professionele, niet-Oracle-partijen zich hebben toegelegd op het professionaliseren van de zelfbouwtools. Deze tools werken in wezen precies hetzelfde als de zelfbouw-Access-tools. Een voordeel van deze tools is dat de kosten voor het bouwen en beheren van de tool nu bij een externe partij liggen. Een ander te verwachten voordeel is, dat verwacht mag worden dat het aantal gerapporteerde ‘false positives’ lager is. Dit kan in de praktijk overigens tegenvallen. Een nadeel is dat de standaard meegeleverde rapporten minder goed aansluiten bij de rapportagebehoefte.
Tot slot heeft Oracle zelf onderkend dat er een behoefte is aan rapportages voor het doel van Governance, Risk and Compliance (GRC) en andere KPI’s waarover gebruikers periodiek wensen te rapporteren. Dit jaar heeft Oracle een nieuwe productsuite gelanceerd, die aan alle rapportagebehoeften omtrent GRC en breder wil voldoen. Voordeel van deze tool is dat de juistheid van de output wederom gegarandeerd is, dat de rapportage flexibel is en dat alle gegevens beschikbaar zijn voor rapportage. Daartegenover staat dat Oracle GRC een relatief nieuw product is, dat de komende periode verder geoptimaliseerd zal worden.

Een belangrijk punt dat bij bovenstaande ontwikkelingen vermeld dient te worden, is dat de toepassing van de tools ook afhankelijk is van de volwassenheid van de organisaties aangaande risk en compliancy. Er kan gesteld worden dat de afgelopen jaren, onder meer vanwege SOx-vereisten, er een aanzienlijke professionaliseringsslag heeft plaatsgevonden binnen organisaties als het gaat om het vastleggen en bewaken van risico’s en controles. Echter, er kan ook worden gesteld dat de mate waarin deze professionaliseringsslag is doorgevoerd en wordt bewaakt, sterk per organisatie verschilt, hetgeen gevolgen heeft voor de toepassing van de tools.

Figuur 2 geeft de levenscycli weer die men kan onderscheiden en de vertaling ervan naar ondersteunende tooling. Bijvoorbeeld: de toepassing van Oracle GRC verlangt een sterkere professionalisering dan het bewaken van risico’s en controles door middel van standaardrapporten. Indien men deze fasen echter succesvol heeft doorlopen, is men ook beter in staat het gehanteerde ‘control framework’ in te zetten bij het realiseren van performanceverbeteringen in de business.

C-2008-3-Nunen-02

Figuur 2. Volwassenheidsfasen GRC in relatie tot tooling.

De GRC-suite van Oracle

De Oracle GRC-suite is een ruim palet van tools dat bedoeld is om de gebruiker te ondersteunen bij alle aspecten van GRC. Het gaat hierbij om fact-finding direct op Oracle eBS, rapportage door middel van dashboards, en ondersteuning bij het vastleggen en archiveren van elektronische werkpapieren. De Oracle GRC-suite is verder dusdanig flexibel opgezet dat het mogelijk is op meer dan uitsluitend GRC-gerelateerde beheersingsdoelstellingen te rapporteren. Daarmee is rapportage van elke door de gebruiker van belang geachte KPI mogelijk.

Verder biedt de Oracle GRC-suite de mogelijkheid om preventief dan wel detectief om te gaan met beheersingsmaatregelen. Indien de GRC-suite preventief wordt ingezet, ontstaat de mogelijkheid om application controls die in de basis van Oracle eBS niet effectief in te zetten zijn (zoals de 3-way match) door toevoeging als preventieve controle in de GRC-suite toch aantoonbaar effectief te laten werken.

C-2008-3-Nunen-03

Figuur 3 Dashboard in Oracle GRC.

In figuur 3 is een dashboard uit Oracle GRC weergegeven waarin de afwijking ten opzichte van de beoogde matchingmethode gekwantificeerd is.

Oracle GRC is in principe bedoeld om geïmplementeerd te worden op de omgeving van de gebruiker. Het is ook mogelijk gegevens van klanten op een stand-alone omgeving te analyseren met behulp van een standaardset van regels. Daarmee biedt de GRC-suite ook mogelijkheden voor de werkzaamheden van de auditor.

Conclusie

Oracle GRC brengt de geautomatiseerde gegevensgerichte controle dichterbij waardoor de mogelijkheden voor de accountant om efficiënter en gerichter controlewerkzaamheden uit te voeren toenemen.

De tools die de geautomatiseerde gegevensgerichte controle mogelijk maken, bieden de gebruiker de mogelijkheid om zelf actief te sturen op de door de accountant te toetsen beheersingsmaatregelen. Hierdoor kan de gebruiker zelf een efficiencyslag realiseren binnen de eigen administratieve processen en de mate van beheersing beter aantoonbaar maken aan de accountant.

Een belangrijke randvoorwaarde voor het succesvol toepassen van de tools is het bepalen van de volwassenheidsfase van een organisatie als het gaat om het vastleggen en bewaken van risico’s en controles. Indien men dit inzichtelijk heeft gemaakt, kan men de stappen bepalen die men moet doorlopen om het control framework effectief te kunnen inzetten bij het verbeteren van de business performance.

Literatuur

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

[West01] B. Westra en M.T. Mooijekind, Compendium van de accountantscontrole, Pentagan, 2001.

‘Embedded Testing’ – uitrol naar IT controls?

Inmiddels zijn al velen bekend met de term ‘Embedded Testing’, vooral in de SOx 404-context. In artikelen, webcasts en roundtables valt de term veelvuldig en ook internationaal duikt deze term steeds vaker op. ‘Embedded Testing’ komen we intussen ook niet meer alleen met betrekking tot SOx tegen, maar bijvoorbeeld ook in het kader van SAS 70-trajecten en de bredere interne beheersing. Daarnaast is het concept ook van toepassing op de IT controls, waarop verder wordt ingegaan in het artikel.

Inleiding

Internationaal zien we een duidelijke behoefte om de ‘cost of compliance’ zoveel mogelijk terug te dringen. Deze kosten worden gemaakt om te kunnen voldoen aan de wet- en regelgeving, zoals SOx, J-Sox (Japanese Sox), Basel (voor banken), etc. De ingegeven verplichtingen om de interne beheersing te verbeteren, te documenteren en aan te tonen, hebben geleid tot een significante kostenverhoging bij de bedrijven. Dit wordt door alle partijen onderkend en er wordt gezocht naar diverse methoden om de lasten te verlagen; denk in dit verband onder andere aan SEC’s Interpretive Guidance for Management ([SEC07]) en Auditing Standard 5 ([PCAO07]).

Daarnaast zien we dat bedrijven zogenaamde control-rationalisatieprojecten uitvoeren om zo meer focus aan te brengen op de allerbelangrijkste risico’s. In dit verband wordt ook gezocht naar methoden en technieken om efficiënter de interne beheersing aan te kunnen tonen. ‘Embedded Testing’ is een voorbeeld van een dergelijke methode. In het artikel wordt kort aangegeven wat ‘Embedded Testing’ is en wat dat voor IT controls kan betekenen.

‘Embedded Testing’

Voor diegenen die misschien al wel de term een keer hebben gehoord, maar er nog niet voldoende beeld bij hebben, of voor diegenen die nieuwsgierig zijn naar de laatste ‘Embedded Testing’-ontwikkelingen, volgt onderstaand een korte toelichting op het concept.

‘Embedded Testing’ is het optimaal gebruikmaken van reguliere monitoringactiviteiten (op beheersingsmaatregelen) met het doel de interne beheersing zo efficiënt mogelijk aan te kunnen tonen. Deze monitoringactiviteiten zijn bijvoorbeeld managementreviews op de adequate werking van opgenomen beheersingsmaatregelen in de onderliggende processen.

De hoeveelheid testwerk wordt met toepassing van ‘Embedded Testing’ in veel gevallen aanzienlijk verminderd. Er zijn bedrijven die zelfs een besparing van de testinspanning hebben bereikt van wel negentig procent! Deze besparingen kunnen worden gerealiseerd zonder de hoeveelheid beheersingsmaatregelen te beperken. Naast de besparing op de hoeveelheid testwerk is er ook een potentiële besparing op de hoeveelheid werk die de externe accountant moet uitvoeren. Het klinkt te goed om waar te zijn, maar is het toch.

‘Embedded Testing’ versus controlrationalisatie

Naast ‘Embedded Testing’ zijn er ook andere methoden om de kosten van interne beheersing te verlagen, bijvoorbeeld door middel van het reduceren van het aantal ‘key’ controls. Dit vindt in de praktijk veelal plaats onder de vlag van controlrationalisatie. In wezen is controlrationalisatie een manier om een inefficiënt beheersingsproces (zoals SOx 404) zo klein mogelijk te maken om zo de totale inefficiëntie tot een minimum te beperken. Hoewel dit in diverse gevallen een prima aanpak kan zijn om de kosten te verlagen, zien wij in ‘Embedded Testing’ meer toegevoegde waarde. ‘Embedded Testing’ maakt, door middel van een fundamenteel andere benadering, het beheersingsproces zélf efficiënt waardoor de behoefte om het zo klein mogelijk te maken in de regel verdwijnt. Sterker nog, we constateren dat bedrijven die hun beheersing via ‘Embedded Testing’ slimmer verkrijgen, dit uitrollen buiten de verplichte onderdelen van de organisatie. Ofwel, zij gaan verder dan de noodzaak vanuit de wet- en regelgeving.

Ten slotte willen we benadrukken dat controlrationalisatie in veel gevallen wel degelijk een prima instrument is om kosten te reduceren, maar SOx en vergelijkbare complianceprogramma’s kunnen pas écht efficiënt worden na toepassen van ‘Embedded Testing’.

COSO: monitoring van controls

De COSO-commissie heeft op 4 juni jl. een Exposure Draft uitgebracht met betrekking tot de monitoringcomponent van hun Internal Control – Integrated Framework. Zij benadrukt in de executive summary dat nog te veel bedrijven te weinig gebruikmaken van de resultaten van hun reguliere monitoringactiviteiten, waardoor er nog te veel onnodig separaat testwerk wordt verricht. Dit is precies de boodschap van ‘Embedded Testing’. Daarmee herhaalt COSO de aanbevelingen die de SEC en de PCAOB in 2007 in het kader van SOx reeds hebben gedaan. In de Interpretive Guidance for Management en in Auditing Standard 5 wordt eveneens gewezen op de mogelijkheden om te steunen op de monitoringactiviteiten die veelal binnen de processen aanwezig zijn.

De kern van het ‘Embedded Testing’-concept ligt in het onderscheid tussen ‘controls’ en ‘monitoringactiviteiten’. De eerste hebben betrekking op het voorkomen of detecteren en oplossen van fouten die in processen kunnen optreden, de tweede betreffen het toezien op de effectieve werking van die ‘controls’. Verreweg de meeste van deze monitoringactiviteiten worden uitgevoerd binnen de reguliere procesgang teneinde de risico’s zo dicht mogelijk bij de bron te kunnen managen. Deze zogenaamde ‘on-going’ monitoringactiviteiten hebben ook de voorkeur, naast separaat ingestelde monitoringactiviteiten, bijvoorbeeld door interne auditors.

Feitelijk moeten we constateren dat het COSO-raamwerk weliswaar op grote schaal door organisaties wereldwijd is aangewezen als het raamwerk dat ze voor hun interne beheersing willen hanteren, maar dat de concrete toepassing ervan in de praktijk, in ieder geval op het monitoringaspect, nog onvoldoende handen en voeten heeft gekregen. Want het COSO-raamwerk zoals dat in 1992 verscheen, bevatte al de nodige handvatten voor het efficiënt inrichten van monitoringactiviteiten en het steunen daarop vanuit interne beheersing.

Op zich is de ‘Embedded Testing’-gedachte uiteraard niet revolutionair. Wat echter wel nieuw is, is de concrete vertaling van de monitoringprincipes, zoals deze onder andere door COSO zijn bedoeld, naar de praktijk van alledag. Lijnmanagers, risk managers, compliance officers, controllers, CFO’s, internal auditors, externe accountants alsook audit committees en andere toezichthouders, hebben allemaal behoefte aan een duidelijke rolverdeling als het gaat om het verkrijgen van zekerheid over de inrichting en werking van interne beheersingsmaatregelen. Er worden vaak nog te veel, of niet de juiste, testactiviteiten uitgevoerd – zoals ook door COSO zelf geconstateerd.

Control selfassessment-activiteiten, zoals veel organisaties de laatste jaren in gang hebben gezet, zijn daarbij wel een stap in de goede richting; echter, deze gaan in de regel niet zo ver en zijn niet zo concreet als COSO aanbeveelt. Voorbeelden hiervan zijn de verankering binnen de reguliere bedrijfsactiviteiten door middel van maand/kwartaalafsluitingen en het gebruikmaken van overkoepelende controles.

Monitoring van IT controls

Het ‘Embedded Testing’-concept en de monitoring controls zijn uiteraard ook van toepassing op de IT- omgeving, maar hoe gaat dat in de praktijk en welke ervaringen worden daarbij opgedaan? We kunnen in dit verband onderscheid maken tussen het geautomatiseerd en het ‘handmatig’ vaststellen dat IT controls hebben gewerkt. In het tweede geval kan worden gedacht aan de review controls door het management, waarbij gebruik wordt gemaakt van informatie uit het systeem. Beide opties werken we iets concreter uit.

Geautomatiseerd controlebewijs verkrijgen

Bij het geautomatiseerd vaststellen of IT controls hebben gewerkt, wordt bewijsmateriaal direct uit de onderliggende systemen verkregen. Door middel van ingestelde ‘regels’ wordt vastgesteld of er zich geen functiescheidingsconflicten hebben voorgedaan of wordt vastgesteld dat bijvoorbeeld de 3-way match heeft gewerkt binnen de gestelde limieten. Het geautomatiseerd vergaren van dergelijk bewijs, vindt plaats met behulp van GRC-tooling zoals Approva of SAP GRC (zie elders in deze Compact voor meer details over deze tools en mogelijkheden). Dit bewijs kan ook worden verkregen door gebruik van dataminingtechnieken (gegevens direct verkrijgen uit de bronsystemen en deze analyseren). Het testen is als het ware ‘ingebed’ in de processen van de organisatie. Als de organisatie zelf de werking van de ingerichte controles test, noemen we dat continuous monitoring. Wordt de werking specifiek door de interne/externe auditor uitgevoerd, dan noemen we dit continuous auditing.

C-2008-3-Klumper-01

Figuur 1. Continuous auditing vs. continuous monitoring.

We zien dat veel organisaties zich in het proces bevinden waarin handmatige controles worden vervangen door geautomatiseerde controles en dat toegangsbeveiligingssoftware wordt geïmplementeerd. Het gebruikmaken van een geïntegreerde oplossing voor de gehele organisatie zien we nog niet zoveel in de praktijk.

Daarnaast worden de uitkomsten van het gehele testproces veelal geregistreerd in zogenaamde ERM-tools, zoals Bwise, Axentis of Paisley ([Forr07]). Met behulp van dashboards, eventueel via aparte reporting tools opgesteld, kan het management de status en voortgang van zijn interne beheersing volgen. Deze ‘c-level’-controle is ook een belangrijke monitoring control, maar dan van het internecontroleproces.

Handmatig controlebewijs verkrijgen

De werking van de IT controls kan ook door middel van ‘handmatige’ controls worden vastgesteld. Dit zijn de management review controls, waarbij er geen tools aanwezig zijn om de werking vast te stellen. Een goed voorbeeld in dit verband is het beoordelen van de logische toegangsbeveiliging. We zien doorgaans dat ingerichte beveiligingsinstellingen (zoals wachtwoordlengte), autorisatiecontroles (toekennen bevoegdheden) en review controls naast elkaar worden beoordeeld, zonder onderscheid te maken naar het soort controles. Ook hier zou de goede werking van review controls enige zekerheid moeten verschaffen dat onderliggende process level controls goed hebben gewerkt. Indien bijvoorbeeld periodiek wordt vastgesteld dat de ingerichte functiescheiding overeenkomt met de vereiste functiescheiding en dat de mutaties tussen de perioden (in-/uitdienst) worden beoordeeld door het management, in hoeverre zijn de process level controls omtrent in- en uitdiensttreding dan voldoende afgedekt?

C-2008-3-Klumper-02

Figuur 2. Review control IT vs. process level controls.

Uiteraard hangt de exacte invulling sterk af van de feitelijke omstandigheden, bijvoorbeeld wat is het risico als een fout in de functiescheiding pas na drie maanden wordt ontdekt?

Hetzelfde principe van de monitoring controls geldt min of meer voor de review controls in het change-managementproces. Ook hier kan het management beoordelen dat de verplichte stappen zijn gevolgd aan de hand van een checklist en met behulp van enkele deelwaarnemingen vaststellen dat de diverse goedkeuringen in het proces (acceptatietest, etc.) terecht zijn gegeven. Dit vervangt dan uitgebreid testwerk op de onderliggende controles en kwalificeert zich als ‘Embedded Testing’.

Wij constateren in de praktijk dat monitoring controls volop worden toegepast met betrekking tot IT controls, maar dat organisaties hier vaak nog onvoldoende efficiënt gebruik van maken om hun beheersing aan de buitenwereld aan te tonen. Veel werk wordt als gevolg hiervan nog dubbel gedaan.

Conclusie

Er is steeds meer aandacht voor het ‘Embedded Testing’-concept in de praktijk en vanuit gezaghebbende organisaties, en met heel goede redenen. Wij verwachten dat deze aandacht in de toekomst verder zal toenemen op alle terreinen waar interne beheersing van belang is. Dit wordt versterkt door uitingen zoals die van COSO, maar vooral ook door bedrijven en organisaties die ‘Embedded Testing’ in de praktijk toepassen en er de voordelen van ervaren.

Daarnaast is het ‘Embedded Testing’-concept ook zeker van toepassing op IT controls, waar naar de mening van de auteurs een inhaalslag zal kunnen plaatsvinden om hier efficiënter gebruik van te kunnen maken, al dan niet met behulp van beschikbare tooling. De GRC-tooling, waarover meer in deze Compact, zal hieraan bijdragen.

Literatuur

[COSO08] Exposure draft Guidance on Monitoring Internal Control Systems, COSO, 2008, www.coso.org/guidance.htm

[Forr07] The Forrester Wave™, Enterprise Governance, Risk, and Compliance Platforms, by Chris McClean and Michael Rasmussen for Security & Risk Professionals, Q4, December 21, 2007.

[PCAO07] PCAOB’s Auditing Standard no. 5, 2007.

[SEC07] SEC’s Interpretive Guidance for Management, 2007.

Het effect van GRC-software op de jaarrekeningcontrole

Veel ondernemingen zijn bezig GRC-software in gebruik te nemen. Deze Governance Risk & Compliance-software ondersteunt ondernemingen bij het documenteren en testen van internecontrolemaatregelen en het opvolgen van issue met betrekking tot internecontrolemaatregelen. Tijdens de jaarrekeningcontrole zal de accountant steeds ondernemingen tegenkomen die GRC-software in gebruik hebben. Welke mogelijke invloed heeft GRC-software op de werkzaamheden van een accountant?

Inleiding

Bedrijven moeten veel bewerkstelligen om te voldoen aan de verschillende wet- en regelgevingen, zoals bijvoorbeeld ingegeven door SOx. In het kader van SOx zijn ondernemingen verplicht om aan te tonen dat hun stelsel van internecontrolemaatregelen effectief is. Dit vereist veel werkzaamheden, al is dat sinds de publicatie van de Auditing Standard 5 van de PCAOB wel enigszins verlicht ([PCAO07]). De vereisten met betrekking tot het documenteren van processen, het documenteren van internecontrolemaatregelen en conclusies over afwijkingen zijn hoog. Simpel gezegd: ‘Als het niet gedocumenteerd is op een fatsoenlijke wijze, bestaat het niet’ ([Diek05]). De afgelopen paar jaar zijn er meer en meer softwarepakketten op de markt gebracht die het documenteren van processen en internecontrolemaatregelen ondersteunen. Daarnaast ondersteunen deze softwarepakketten ook nog eens het testen van (key) internecontrolemaatregelen en het rapporteren over de internecontrolemaatregelen. In dit artikel noemen we deze software GRC-software.

Het gebruik van GRC-tools door een onderneming kan mogelijk van invloed zijn op de werkzaamheden die een accountant tijdens de jaarrekening uitvoert. Wat is de mogelijke invloed van het gebruik van GRC-software door een onderneming op het werk van een accountant? Die vraag zullen we beantwoorden in dit artikel.

We beginnen met kort uiteen te zetten uit welke onderdelen de audit bestaat. Vervolgens beschrijven we wat voor mogelijkheden GRC-software biedt. Ten slotte leggen we het verband tussen de mogelijkheden van GRC-software en de onderdelen van de jaarrekeningcontrole.

Bij de jaarrekeningcontrole bevat de accountantscontrole risico’s

De jaarrekeningcontrole, of financial audit, bestaat uit een aantal stappen. We gaan er niet te gedetailleerd op in, aangezien de inhoud van de jaarrekeningcontrole bekend mag worden geacht. Maar een aantal aspecten is in dit kader dusdanig belangrijk dat we ze zullen bespreken. De belangrijkste is het accountantscontrolerisico (Audit Control Risk, ACR).

Het accountantscontrolerisico wordt bepaald door drie risico’s

Tijdens de financial audit wordt beoordeeld of de financiële gegevens van bedrijven een getrouw beeld geven van de werkelijkheid, en of de interne controle effectief is. Bij het beoordelen van de effectiviteit van de interne controle worden drie risicofactoren in acht genomen, te weten: inherente risico, internecontrolerisico en detectierisico. Deze drie vormen samen het accountantscontrolerisico.

C-2008-3-Ibrahim-01

Figuur 1. Accountantscontrolerisico ([Knec01]).

Ten eerste wordt gekeken naar het inherente risico. Dit risico geeft de kans aan dat er material weaknesses[Fouten (tekortkomingen in de interne controle) die voor significante afwijkingen in de jaarrekening kunnen zorgen.] ontstaan zonder dat er rekening wordt gehouden met internecontrolemaatregelen ([Aren06]). Het is afhankelijk van factoren als het marktsegment of het management van een organisatie. Bijvoorbeeld: als in een bepaald marktsegment veel gefraudeerd wordt, dan is het risico dus groter dat er bij een organisatie die zich in dat segment bevindt material weaknesses worden aangetroffen. Ten tweede wordt er gekeken naar het internecontrolerisico. Dit is de kans dat materiële fouten niet worden voorkomen of opgemerkt door de internecontrolemaatregelen. Ten slotte is er ook nog het detectierisico. Dit is de kans dat er bij de gegevensgerichte controle material weaknesses onopgemerkt zijn gebleven.

De accountant kan met zijn werkzaamheden het detectierisico beïnvloeden

De drie genoemde risico’s vormen samen het accountantscontrolerisico. Dit beschrijft het risico dat er na de audit materiële fouten onopgemerkt zijn. Als het inherente risico, het internecontrolerisico en het detectierisico laag zijn, dan is het accountantscontrolerisico logischerwijs ook laag. Het is het doel van de accountant om het accountantscontrolerisico zo laag mogelijk te houden, wat betekent dat hij de audit naar behoren heeft uitgevoerd. De gedachtegang achter het accountantscontrolerisico is dat naarmate het inherente risico en het internecontrolerisico kleiner worden, er een hoger detectierisico geaccepteerd wordt. Zijn het inherente en internecontrolerisico hoog, dan moet een lager detectierisico dat compenseren. In sommige literatuur wordt deze gedachtegang verpakt in een formule, maar dat is niet juist. Het accountantscontrolerisico is namelijk een denkmodel. Tabel 1 geeft dit model weer. Het grijze vlak laat zien wat de hoogte van het detectierisico mag zijn in het geval van het bijbehorende inherente risico en internecontrolerisico.

C-2008-3-Ibrahim-02

Tabel 1. Accountantscontrolerisico ([NIVR02]).

Normaal gesproken heeft de accountant geen invloed op het inherente risico en het internecontrolerisico. Die worden van tevoren en tijdens de beoordeling van de interne controle vastgesteld. Echter, op de hoogte van het detectierisico kan wel invloed worden uitgeoefend. Hoe meer en hoe intensiever de accountant controleert bij de gegevensgerichte controle, des te kleiner de kans dat er onjuistheden in de financiële gegevens van de klant onopgemerkt blijven. kan in dit geval gebruikt worden om te bepalen hoe de accountant de gegevensgerichte controle gaat uitvoeren. Als het inherente risico en het internecontrolerisico laag zijn, dan mag het detectierisico wat hoger zijn.

Internecontrolemaatregelen

Over het algemeen heeft een onderneming een mix van controlemaatregelen geïmplementeerd. Deze mix bestaat uit een aantal verschillende soorten controlemaatregelen die grofweg te verdelen vallen in preventieve en detectieve controles. Hierbij is een preventieve controle een controlemaatregel met als doel te voorkomen dat een risico zich manifesteert, en heeft een detectieve controle als doel het opsporen van een risico dat zich heeft gemanifesteerd. Hierbij geldt dat een preventieve maatregel over het algemeen sterker is dan detectieve controles, omdat de eerstgenoemde het zich manifesteren van een risico voorkomt.

GRC-software biedt nuttige functionaliteiten voor de jaarrekeningcontrole

Sinds de invoering van de SOx-wetgeving zijn bedrijven verplicht om aan te tonen dat ze in control zijn. Onder meer de effectiviteit van de interne controle wordt daarbij beoordeeld. GRC-software wordt gebruikt om organisaties te helpen in het aantonen van compliance. We zullen nu dieper ingaan op de mogelijkheden van GRC-software. Wat kan hij allemaal, waar moet hij aan voldoen, waarom zouden bedrijven of accountants er gebruik van moeten maken en wat zijn de nadelen? Voorbeelden van tools op het gebied van Governance, Risk & Compliance zijn onder andere:

ACL Services;
Approva;
Control Software International (CSI);
D2C Solutions;
LogicalApps;
Oracle;
Oversight Systems;
SAP GRC Access Controls en SAP GRC Process Controls.

C-2008-3-Ibrahim-03

Figuur 2. Resultaten uit The Global CFO Study 2008 ([IGGS08]).

GRC-software is efficiënt en effectief

Automatisering speelt een belangrijke rol in de verbetering van de effectiviteit van de interne controle. In een onderzoek onder leidinggevenden ([IGGS08]) bleek dat ongeveer 66 procent van de ondervraagden het beheersen en verminderen van risico’s prioriteit geeft, terwijl dit een factor is die bepaalt of een bedrijf financieel succesvol is. Dit is weergegeven in figuur 2. GRC-software kan belangrijk zijn bij het automatiseren van interne controle. Deze software biedt als voordeel dat hij effectief en efficiënt is. Ook werkt hij doorgaans consistenter en gebruikersvriendelijker dan het handmatig beoordelen van de effectiviteit van interne controle.

SAP GRC is een voorbeeld van een bruikbare tool

Bij het beschrijven van functionaliteiten van GRC-software wordt in dit artikel in eerste instantie gekeken naar de GRC-oplossingen van SAP. Er zijn nog veel meer oplossingen, maar om het afgebakend te houden wordt er hier naar één oplossing gekeken. Bovendien biedt SAP meerdere oplossingen voor de verschillende problemen die kunnen optreden bij het in compliance blijven van bedrijven. Het GRC-platform van SAP bevat een aantal verschillende onderdelen die hier kort worden behandeld.

SAP GRC Access Controls bekijkt en voorkomt kritieke toegangsrechten en functiescheidingsconflicten

De SAP GRC Access Controls-oplossing richt zich op de toegangsrechten in SAP en een aantal andere ERP-applicaties. De basis van GRC Access Controls betreft een module voor ‘risk identification & remediation’. De basis van deze module is als het ware een grote lijst waarin regels voor functiescheiding en kritische systeemtoegang staan gedefinieerd. Met behulp van deze functionaliteit (ook wel compliance calibrator genoemd) kan een onderneming in kaart brengen welke gebruikers functiescheidingsconflicten (wie kan er crediteuren onderhouden en betalen) in hun bevoegdheden hebben en welke gebruikers toegang hebben tot kritische functionaliteit in het systeem (wie kan er crediteuren aanleggen of wie kan er betalen). Indien een gebruiker een combinatie van kritieke bevoegdheden dient te hebben (bijvoorbeeld een kleine afdeling of vestiging), dan is het mogelijk een mitigerende maatregel aan het risico voor de gebruiker te koppelen.

Daarnaast kan met behulp van GRC Access Controls worden voorkomen dat functiescheidingsconflicten in het systeem worden geïntroduceerd. Hiervoor bestaat de module ‘complaint user provisioning’, waarmee kan worden voorkomen dat conflicten worden geïntroduceerd door middel van toekenning van rollen aan gebruikers. Indien een gebruiker een conflicterende rol krijgt, zal GRC Access Controls de toekenning blokkeren totdat er goedkeuring wordt gegeven en het conflict direct wordt gemitigeerd door het toekennen van een mitigerende maatregel. Ook bestaat de module ‘enterprise role management’, waarmee wordt voorkomen dat er conflicten in een autorisatierol worden geïntroduceerd.

Het laatste onderdeel van GRC Access Controls betreft het onderdeel ‘super user privilage management’. Deze oplossing biedt de mogelijkheid om eindgebruikers of beheerders extra functionaliteit te geven. Indien de gebruikers de extra functionaliteit moeten gebruiken, moeten zij voordat ze starten aangeven waarom ze de functionaliteit gaan gebruiken. Vervolgens wordt de activiteit gelogd en kan aan een reviewer een mail worden gestuurd om de activiteit (in de logging) te controleren. Het grote voordeel van deze functionaliteit is dat er geen echte reden meer is om een beheerder niet alle bevoegdheid in het systeem te geven. De beheerder kan nu wel super user rechten krijgen omdat alles wat hij of zij doet, wordt gelogd.

De grootste voordelen van het gebruik van GRC Access Controls voor een onderneming zijn:

De onderneming heeft de functiescheidingsconflicten kunnen identificeren.
Door het gebruik van GRC kan de onderneming het aantal functiescheidingsconflicten beperken.
De onderneming heeft noodzakelijke conflicten op het netvlies en heeft de risico’s kunnen mitigeren.
Het concept zal in de toekomst, bij de juiste toepassing, verschoond blijven van nieuwe, ongemitigeerde conflicten.
Super user bevoegdheid kan gecontroleerd worden uitgegeven waarbij uitgevoerde activiteiten worden gemonitord.

Andere voorbeelden van GRC tooling die zich richt op het beheersen van toegangsrechten en functiescheidingsconflicten zijn Approva Bizrights, Security Weaver, CSI Authorization Auditor en SecurInfo.

SAP GRC Process Controls ondersteunt de vastlegging van internecontrolemaatregelen

In de SAP GRC Process Controls-oplossing kan een onderneming voor elke organisatie het stelsel van internecontrolemaatregelen definiëren. In de tool wordt allereerst een organisatorische hiërarchie vastgelegd. Vervolgens kunnen van de verschillende organisaties de relevante subprocessen worden vastgelegd. Per subproces kan in de tool worden aangegeven wat de control objectives, de assertions en de te ondersteunen account(group)s zijn. Vervolgens kunnen aan de subprocessen de relevante risico’s worden gekoppeld en kunnen de gedefinieerde controlemaatregelen aan de processen worden gekoppeld. Met behulp van deze inrichting kunnen het ontwerp van een proces en de risico’s worden beoordeeld en kan de effectiviteit van de controls worden getest. Daarna kunnen er in de tool met behulp van assessment surveys een aantal assessments worden uitgevoerd:

een control design assessment: het nagaan of een control een risico afdekt;
een control self assessments: het laten testen van een control;
een subprocess design assessment: het laten beoordelen van een subproces (zijn alle risico’s gedefinieerd);
een entity level control assessments: het laten beoordelen van controles die worden uitgedragen door het hogere management.

Daarnaast kan met behulp van GRC Process Controls een workflow worden ingericht om de gedefinieerde controls te laten testen op hun effectiviteit. Per control wordt een testplan gedefinieerd. Een tester zal vervolgens een mail krijgen waarin staat opgenomen welke control getest moet worden, hoe de control getest moet worden en wat de sample size van de control is. Indien de control niet effectief is, dient de tester in de tool aan te geven dat de control niet effectief is. Vervolgens wordt er een remediationplan gemaakt waarmee de control deficiency zal moeten worden opgelost. De uitkomsten van de test en eventueel de test evidence kunnen in de tool worden vastgelegd. Indien de controlemaatregelen niet voor de deadline getest worden, bestaat de mogelijkheid om een escalatie te sturen naar een andere persoon, die er vervolgens voor kan zorgen dat de controlemaatregel alsnog getest kan worden.

De belangrijkste voordelen van SAP GRC Process Controls met betrekking tot handmatige controls zijn:

het vastleggen van internecontrolemaatregelen;
het inzichtelijk maken of de gedefinieerde controlemaatregelen alle risico’s adequaat afdekken (aan de hand van de assertions gekoppeld aan de control objectives);
het faciliteren van het testen van de effectiviteit van de controlemaatregelen.

In de markt is een aantal tools beschikbaar die soortgelijke functionaliteit bevatten. Hierbij kan onder andere gedacht worden aan de oplossing van Bwise en bijvoorbeeld de ARIS audit manager.

SAP GRC Process Controls bevat nuttige en efficiënte automatische controles

Een tweede belangrijk onderdeel in deze tools betreft het gedeelte automatische controls. Binnen SAP GRC Process Controls (en bijvoorbeeld in GRC-tools zoals Synnaxion of Approva) kunnen automatische controls worden geactiveerd. Deze controls haken in op:

customizing controls (komen de ingerichte instellingen overeen met voorgedefinieerde threshold);
masterdata (identificeert kritische velden die worden veranderd);
transactionele data (identificeert exceptions gebaseerd op voorgedefinieerde waarden).

Het gebruik van de aangeboden automatische controle kan tot gevolg hebben dat bepaalde handmatige controles vervangen worden door geautomatiseerde controles. In plaats van op lijsten naar exceptions te zoeken, worden de exceptions nu automatisch geïdentificeerd en ter review aangeboden. Dit heeft tot gevolg dat een onderneming veel eerder een exception identificeert en dus ook veel sneller kan ingrijpen op een exception indien noodzakelijk.

Het laten uitvoeren van automatische controles door GRC-software leidt tot continuous monitoring van controls. De voordelen van continuous monitoring zijn legio:

Efficiency:

het automatiseren van controls die handmatig veel tijd in beslag zouden nemen;
het reageren op controls die stoppen met werken in plaats van het testen van de effectiviteit van controlemaatregelen;
het kunnen identificeren van alle exceptions in plaats van steekproefsgewijs;
het direct kunnen reageren op exceptions.

Verbeterde controlemaatregelen:

transitie van handmatige, detectieve controlemaatregelen naar preventieve controlemaatregelen;
automatische fraudepreventie en -detectie.

Verbeterde informatievoorziening:

versneld uitvoeren van controlemaatregelen (continu);
versnelde rapportagemogelijkheden (real-time);
gebruik van resultaten in de auditplanning (definiëren van aandachtsgebieden);
centraal kunnen uitvoeren van audits;
verbeterd gebruik van automatisering.

Lagere complexiteit:

versterkte focus op echte control issues;
demonstreren van good governance aan het management;
mogelijkheid tot business process improvement.

Overige SAP GRC-applicaties

Overige modules binnen SAP GRC zijn de modules SAP GRC Risk Management voor het identificeren en beheersen van risico’s op strategisch niveau, SAP GRC GTS voor het voldoen aan de verschillende handels- en exportwetgeving en SAP Environmental & Safety, dat een oplossing biedt voor de verschillende wetgeving betreffende de verschillende environmental en health & safety gerelateerde wetgevingen.

GRC-software brengt zaken aan het licht waar de auditor naar zoekt

Hoe hebben de functionaliteiten effect op de jaarrekeningcontrole? Dat wordt duidelijk door te kijken naar welke zaken bij de audit vaak aan het licht komen.

De procedures die een accountant uitvoert tijdens de normale gang van zaken kan een aantal soorten bevindingen opleveren, welke in onderstaand rijtje zijn opgenomen ([Knec01]).

onvolledige transacties;
mogelijk ongeautoriseerde transacties;
mogelijk frauduleuze transacties;
gebrek aan documentatie bij transacties;
ongebruikelijke verplaatsingen van fondsen;
belastingtransacties onjuist of onvolledig vastgelegd;
betalingen aan overheidsfunctionarissen.

Een aantal van dit type bevindingen kan reeds door de onderneming gedeeltelijk zijn ondervangen door het inzetten van GRC-software. Immers, de organisatie heeft continuous monitoring geïmplementeerd. In dit geval monitort de onderneming op een continue basis een of meer internecontrolemaatregelen. Doordat de organisatie zelf al bevindingen in kaart kan brengen, kan de accountant op deze resultaten steunen. Daarnaast is bekend aan welke processen meer aandacht moet worden geschonken doordat er vaker problemen rond de controlemaatregelen voorkomen.

Het blijkt dus dat het gebruik van GRC-software door de onderneming invloed kan hebben op de werkzaamheden die door de accountant moeten worden uitgevoerd. Wat voor effect het werkelijk heeft kunnen we concluderen aan de hand van de Audit Control Risk.

GRC-software vermindert de gegevensgerichte activiteiten van de accountant

We weten dat de inspanningen van de accountant worden bepaald door de hoogte van het detectierisico dat hij accepteert. Ook weten we dat de hoogte van het detectierisico mede afhankelijk is van de hoogte van het inherente risico en het internecontrolerisico. Afhankelijk van de ingezette GRC functionaliteit heeft GRC een positieve invloed op het internecontrolerisico:

Functiescheidingsconflicten zijn beperkt, bekend en gemitigeerd.
Super user bevoegdheid is niet meer noodzakelijk in het systeem. Er zijn weinig tot geen gebruikers die alle functionaliteit kunnen uitvoeren.
Continuous monitoring van bepaalde controls is ingezet, waardoor mogelijk risico’s direct worden geïdentificeerd en gecommuniceerd.
De GRC-applicatie dwingt het testen van handmatige interne controles af. De onderneming kan op elk moment aantonen wat de status is ten aanzien van het testen van internecontrolemaatregelen en het oplossen van mogelijke issues ten aanzien van deze maatregelen.
Testen wordt onderdeel van de manier waarop de onderneming haar processen uitvoert (embedded testing).

Bij het gebruik van GRC-software wordt het internecontrolerisico dus lager. We weten aan de hand van het accountantscontrolerisico dat het detectierisico dan hoger mag liggen. Er kan dus een hoger detectierisico geaccepteerd worden, wat weer betekent dat de accountant minder gegevensgerichte activiteiten hoeft te verrichten bij de jaarrekeningcontrole.

De accountant kan bij bepaalde voorwaarden steunen op GRC-software

We kunnen concluderen dat het gebruik van GRC-software van invloed is op de werkzaamheden van de accountant. Immers, de accountant kan naar alle waarschijnlijkheid voor een gedeelte steunen op de uitkomsten van de testen van de controlemaatregelen door de onderneming.

Er is echter een aantal voorwaarden te stellen die door de accountant onderzocht moeten worden, wil hij op de uitkomsten van de GRC-tools kunnen steunen. Hierbij kan onder andere gedacht worden aan:

Staan in de GRC-tool alle internecontrolemaatregelen opgenomen die relevant zijn voor de jaarrekening controle?
Zijn de regels zoals gedefinieerd voor functiescheidingen en voor continuous monitoring technisch goed gedefinieerd? Zijn de uitkomsten van continuous monitoring betrouwbaar?
Hoe waarborgt de onderneming dat de mitigerende maatregelen voor functiescheidingsconflicten ook daadwerkelijk worden uitgevoerd?
Welke procedures heeft de onderneming geïmplementeerd in het geval dat een exception wordt gerapporteerd? Hoe lost de onderneming mogelijke gebreken in de internecontrolemaatregelen op?
Hoe kan het testen van de IT general controls rondom de GRC-applicaties worden uitgevoerd?

Daarnaast staat het de accountant natuurlijk vrij om zelf nog aanvullende of andere controles op effectiviteit te testen.

Conclusie: GRC-software beïnvloedt de jaarrekeningcontrole

De afgelopen paar jaar zijn diverse ondernemingen gestart met de implementatie van tooling voor Governance Risk & Compliance. Hierbij kan gedacht worden aan functiescheidingstools, controledocumentatietools, tools die het testen van controlemaatregelen ondersteunen en tools voor continuous monitoring. Door het gebruik van dergelijke geavanceerde tooling door ondernemingen voor het documenteren en testen van internecontrolemaatregelen kan het internecontrolerisico voor de accountant worden verlaagd. De accountant blijft echter eindverantwoordelijk voor de jaarrekeningcontrole. Hij zal dus moeten bepalen in hoeverre hij kan steunen op de resultaten van GRC-software. Echter, aangezien hij voor een zeer groot gedeelte zal gaan steunen op de werking van de GRC-tooling voor de internecontrolemaatregelen, zullen de GRC-tools zelf onderwerp van onderzoek worden.

Literatuur

[Aren06] A.A. Arens, R.J. Elder en M.S. Beasley, Auditing and Assurance Services. An Integrated Approach, Pearson Prentice Hall, 2005.

[Diek05] P. Diekman, Rapporteren over interne controle, Bestuurlijke informatieverzorging, oktober 2005.

[IBGS08] IBM Global Business Services, The Global CFO Study 2008.

[Knec01] W.R. Knechel, Auditing, Assurance & Risk, South-Western College Publishing, 2001.

[NIVR02] NIVRA, NOvAA, Richtlijnen voor de Accountantscontrole, Koninklijk NIVRA, Amsterdam, 2002.

[PCAO07] Public Company Accounting Oversight Board (PCOAB), An Audit of Internal Control over Financial Reporting That Is Integrated with An Audit of Financial Statements, Auditing Standard No. 5, 2007.

Auditing van single client ERP

Wij komen bij onze klanten steeds vaker in aanraking met zogeheten single client ERP-systemen, ofwel ERP-systemen waarin de klant de ERP-systemen van meerdere organisatie-entiteiten heeft ondergebracht in één overkoepelend ERP-systeem. Op het eerste gezicht lijkt er voor de auditor (en adviseur) weinig te veranderen, maar wanneer in meer detail wordt gekeken dient met een aantal specifieke aandachtspunten rekening te worden gehouden. In dit artikel gaan wij in op het fenomeen single client ERP-systeem en geven we een toelichting op de belangrijkste aandachtspunten.

Inleiding

De introductie van Enterprise Resource Planning (ERP)-systemen heeft bijgedragen aan de verschuiving van eilandautomatisering naar meer geïntegreerde systemen. Aan het eind van de jaren negentig hadden veel ondernemingen, al dan niet onder invloed van de hype die rondom ERP was ontstaan, een ERP-oplossing geïmplementeerd. In de loop der jaren bleek bij veel multinationals echter ook dat de afzonderlijke (nationale) organisatieonderdelen, ofwel de operating companies (afgekort tot OpCo) elk hun eigen ERP-systeem gebruikten. Het gebruik van verschillende ERP-systemen of het gebruik van hetzelfde ERP-systeem maar met verschillende versies of functionaliteit binnen één (multinationale) onderneming leidt tot een gebrek aan uniformiteit en standaardisatie van bedrijfsprocessen binnen de operating companies.

Een recente ontwikkeling is dat steeds meer (multinationale) organisaties kiezen voor het technisch samenvoegen van meerdere (en uiteindelijk alle) OpCo ERP-systemen in één ERP-systeem om zo de gewenste standaardisatie en efficiëntieverbetering na te streven. Het samenvoegen van meerdere ERP-systemen heeft echter ook mogelijk negatieve gevolgen. De risico’s die in de oude situatie van toepassing waren op de bedrijfsprocessen van elke afzonderlijke OpCo (bijvoorbeeld inkoop, verkoop, financieel) zijn in de single client omgeving niet plotseling verdwenen. Het is echter nog maar de vraag of de internecontrolemaatregelen die in elke afzonderlijke OpCo geïmplementeerd waren, ook nog steeds toepasbaar en effectief zijn in de nieuwe single client omgeving. Naast dit beheersingvraagstuk eisen nog vele andere aandachtsgebieden een rol, zoals het opzetten van het functionele en technische applicatiebeheer, het opzetten van een organisatiebreed beveiligingsconcept en het onderhoud van stamgegevens.

In dit artikel gaan wij in drie stappen verder in op single client ERP-systemen door eerst aan te geven wat ‘single client’ is, vervolgens de impact van het single client ERP-systeem op de interne beheersing (AO/IC) te beschrijven en tot slot in te gaan op de belangrijkste aandachtspunten van een single client ERP-systeem voor de IT-auditor.

De ontwikkeling van ERP naar single client ERP-systemen

De ontwikkeling van afzonderlijke ERP-systemen naar single client ERP heeft zich voltrokken in drie fasen, namelijk:

afzonderlijke ERP-systemen per organisatieonderdeel – OpCo ERP-systeem;
afzonderlijke ERP-systemen ingericht op basis van een template – template ERP-systeem;
één ERP-systeem voor de gehele organisatie – single client ERP-systeem.

OpCo ERP-systeem

Het startpunt is de situatie waarin elke OpCo van een (multinationale) organisatie een eigen ERP-systeem heeft ingericht. Dit scenario komen wij in onze dagelijkse praktijk veelvuldig tegen, waarbij elke OpCo meestal sterk verschilt van de andere. Niet elke OpCo maakt gebruik van hetzelfde ERP-pakket en als dit wel zo is dan zijn er niet zelden verschillen in versienummer of gebruikte functionaliteit. Het gebruik van afzonderlijke ERP-systemen zonder concrete richtlijnen over de wijze waarop het ERP-systeem zal worden ingericht, noemen wij in dit artikel het OpCo ERP-systeem. In figuur 1 is deze situatie weergegeven.

C-2008-3-vdHeuvel-01

Figuur 1. OpCo ERP-omgeving met eigen ERP-systeem per organisatieonderdeel.

Template ERP-systeem

Sommige organisaties, die de mogelijke problemen van losse ERP-systemen al vroeg onderkenden, kozen ervoor om een centrale template (ook wel core of kernel genoemd) te ontwikkelen waarin de belangrijkste functionaliteit van het ERP-systeem was opgenomen. Dit gaf een aanzienlijke verbetering in het gebruik van het ERP-systeem door de mogelijkheden voor standaardisering van de bedrijfsprocessen en de wijze waarop deze door het ERP-systeem worden ondersteund. Een belangrijke gedachte bij een template ERP-systeem is dan ook dat een onderneming die in verschillende landen hetzelfde product fabriceert, dezelfde processen heeft ingericht in elk van de landen. Immers, bijvoorbeeld de manier waarop een frisdrank wordt gemaakt in Nederland, is in de basis dezelfde als in Engeland[Dit is tevens één van de redenen waarom SAP ‘Industry Solutions’ heeft ontwikkeld. Dit zijn SAP-systemen met voorgedefinieerde functionaliteit voor bepaalde bedrijfstakken. Voorbeelden hiervan zijn IS Healthcare, IS Oil, IS Telecom, IS Automotive en IS Consumer Products and Food.]. Het gebruik van de template biedt de lokale OpCo een versnelde inrichting van het ERP-pakket. De template wordt uitgerold naar elke OpCo en mag waar nodig lokaal worden uitgebreid voor specifieke lokale processen.

In figuur 2 staat de template ERP-omgeving weergegeven.

C-2008-3-vdHeuvel-02

Figuur 2. Template ERP-omgeving met eigen ERP-systeem per organisatieonderdeel en sturing vanuit centrale template.

Single client ERP-systeem

Ondanks de voordelen van template ERP werkt de organisatie bij toepassing daarvan nog steeds met afzonderlijke ERP-systemen. De OpCo mag de applicatie in principe verder ontwikkelen en aanpassen, waardoor deze na verloop van tijd niet meer gelijk is aan de andere ERP-omgevingen. Een recente ontwikkeling is dan ook dat steeds meer (multinationale) organisaties kiezen voor het technisch samenvoegen van meerdere OpCo ERP-systemen in één overkoepelend single client ERP-systeem. In figuur 3 is een schematische weergave van het single Client ERP-systeem weergegeven.

C-2008-3-vdHeuvel-03

Figuur 3. Single client ERP-omgeving met één ERP-systeem voor de gehele organisatie.

In tabel 1 worden de belangrijkste kenmerken van deze drie typologieën toegelicht aan de hand van de vier aandachtsgebieden ‘Management en Organisatie’, ‘Processen’, ‘Infrastructuur en beheerorganisatie’ en ‘Mensen en Cultuur’.

C-2008-3-vdHeuvel-tab01-kl

Tabel 1. Overzicht kenmerken ERP-technologieën.

De invloed van single client ERP op interne beheersing

De wijze waarop een organisatie wordt ingericht en waarop noodzakelijke stuur- en verantwoordingsinformatie wordt verkregen om de bedrijfsprocessen te kunnen besturen en beheersen ligt vast in de administratieve organisatie. Aangezien een single client ERP-systeem onderdeel is van deze inrichting heeft dit dus invloed op de administratieve organisatie.

Naast de administratieve organisatie heeft single client ERP ook invloed op het stelsel van interne controle, ofwel de wijze waarop het management via een gedegen proces- en risicoanalyse tot een stelsel van internecontrolemaatregelen komt en controleert of deze maatregelen hebben gewerkt.

Single client ERP en de administratieve organisatie

De administratieve organisatie beschrijft de wijze waarop de organisatie van de informatievoorziening is ingericht en wordt voor dit artikel ingedeeld in de componenten organisatiestructuur, processen en procedures, gegevensverzamelingen en controle- en beheersingsinformatie. Het gebruik van single client ERP is een onderdeel van de administratieve organisatie en van invloed op de verschillende componenten.

Organisatiestructuur

De organisatiestructuur bevat het geheel van functies, afdelingen en personen inclusief een beschrijving van de taken en verantwoordelijkheden. Het gebruik van een single client ERP-systeem heeft invloed op zowel de gebruikersorganisatie als de IT-organisatie.

De succesvolle inrichting en invoering van een single client systeem betekent onder meer dat mogelijkheden bestaan voor het centraliseren van bepaalde activiteiten, zoals factuurinvoer of stamgegevensbeheer in daarvoor opgezette shared service centers. Deze shared service centers zullen dan bepaalde activiteiten zoals factuurinvoer, het uitvoeren van de betaalrun of het verwerken van salarissen centraal uitvoeren, waardoor op operating company-niveau deze taken en verantwoordelijkheden kunnen verdwijnen. Schaalvoordelen zijn door het gebruik van shared service centers op grote schaal mogelijk.

In de IT-organisatie vinden tevens veranderingen plaats. Door standaardisatie van de infrastructuur wordt de infrastructuur als geheel minder complex. Daarnaast hoeven er door het samenvoegen van meerdere ERP-systemen minder productieve systemen te worden beheerd. In OpCo ERP wordt elk lokaal ERP-systeem vaak nog door een lokale beheerorganisatie onderhouden. Voor single client ERP zal de organisatie in ieder geval het technisch beheer van de ERP-applicatie en bijbehorende infrastructuur dienen te centraliseren. Het beheer van een single client systeem kan dus efficiënter worden uitgevoerd dan wanneer meerdere OpCo ERP-systemen moeten worden beheerd. In dat geval zijn er immers meerdere lokale beheerorganisaties die de lokale ERP-systemen beheren. In een single client ERP-systeem zal er een centrale beheerorganisatie zijn die het ERP-systeem beheert, waardoor er ten opzichte van OpCo ERP-systemen op het gebied van technisch beheer schaalvoordelen mogelijk zijn.

Het zelfde geldt voor functioneel beheer. Doordat de OpCo’s binnen een single client systeem met gestandaardiseerde bedrijfsprocessen werken zijn er minder medewerkers nodig voor het functioneel beheer van het systeem. Daarnaast zijn deze functioneel beheerders fulltime bezig met het functionele beheer van het systeem, waardoor ook het kennisniveau van het functionele beheerteam ten aanzien van de specifieke inrichting van het systeem hoger is.

Processen en procedures

Processen en procedures bepalen de wijze waarop producten en diensten tot stand komen. Door gebruik van single client ERP kan vaak standaardisatie worden doorgevoerd, waardoor de manier waarop en de specifieke plaats in het proces waar ERP ondersteuning biedt, kunnen veranderen.

Een belangrijke afweging die hierbij gemaakt moet worden is of de lokale entiteiten zich volledig moeten aanpassen aan het single client ERP-systeem of dat het systeem zo moet worden ingericht dat het de specifieke lokale procesgang kan blijven ondersteunen. Op hoofdlijnen voeren alle entiteiten dezelfde processen uit (bijvoorbeeld inkopen van grondstoffen, productie, verkopen van eindproduct, financiële administratie) waardoor standaardisatie mogelijk kan zijn. De mate waarin is echter afhankelijk van de lokale omstandigheden (bijvoorbeeld wetgeving, interfaces) welke bepalen of de uitgevoerde activiteiten ook daadwerkelijk overal gelijk kunnen zijn.

Het (in meerdere of mindere mate) standaardiseren van de processen leidt ook tot de mogelijkheid om procedures te standaardiseren. Hierdoor kunnen bijvoorbeeld trainingsmaterialen en werkinstructies centraal worden aangemaakt en (al dan niet na vertaling of kleine aanpassingen) worden gebruikt door de lokale entiteiten.

Gegevensverzamelingen

Het belang van betrouwbare gegevens is in een ERP-omgeving groot omdat verschillende processen binnen één entiteit gebruikmaken van dezelfde gegevensverzamelingen. Bij single client ERP is dit belang nog groter omdat niet alleen meerdere processen gebruikmaken van dezelfde gegevens, maar ook meerdere entiteiten.

Een belangrijke groep van gegevens zijn de stamgegevens, zoals leveranciers en materialen. Aangezien stamgegevens veelvuldig worden gebruikt binnen ERP-transacties is adequaat beheer van stamgegevens zeer belangrijk voor effectieve en efficiënte bedrijfsprocessen. Doordat stamgegevens een organisatiespecifiek element hebben, zoals klantinformatie die specifiek is voor een bedrijfsnummer, dient de bevoegdheid om stamgegevens bij te werken beperkt te worden. Het bijwerken van organisatiespecifieke gegevens voor entiteiten waarvoor een gebruiker niet werkzaam is, dient zoveel mogelijk te worden voorkomen.

Meer nog dan in regulier ERP-systeem dient het eigenaarschap van stamgegevens en transactionele gegevens te worden vastgelegd. De eigenaar is vervolgens bevoegd om beslissingen te nemen over bevoegdheden rondom deze gegevens.

Bestuurlijke informatievoorziening

Deze informatie betreft alle informatie die nodig is voor een adequate besturing van processen. Hierbij gaat het niet alleen om informatie uit de gebruikersorganisatie, maar ook uit de IT-organisatie. Door de invoer van single client ERP kan steeds meer gebruik worden gemaakt van controlepunten in de ERP-applicatie zelf (bijvoorbeeld een verschillencontrole tussen factuur en bestelling, controle op dubbele facturen) als vervanging van handmatige controles. Dit resulteert er mede in dat het management niet noodzakelijk informatie nodig heeft over alle details van de procesgang maar alleen over de uitzonderingen in de procesgang.

Bij het gebruik van single client ERP ontstaat het voordeel dat de kennis die elke afzonderlijke OpCo opdoet in het werken met de applicatie, gedeeld kan worden. Vooral op het gebied van rapportagemogelijkheden biedt dit voordelen, bijvoorbeeld wanneer een lokale OpCo een rapportage of query heeft ontwikkeld die voor een andere OpCo nuttig kan zijn.

Single client ERP-systeem en interne controle

Het management van een organisatie heeft bepaalde doelstellingen die het wil realiseren en het is daarom van belang dat risico’s die deze doelstellingen in gevaar kunnen brengen, worden geïdentificeerd en (afhankelijk van de inschatting van het risico) worden afgedekt door een stelsel van internecontrolemaatregelen.

Het uitvoeren van een proces- en risicoanalyse verschilt bij een single client ERP-systeem in principe niet van het reguliere ERP-systeem. Men dient zich vooral te realiseren dat de risico’s die al bestonden in de OpCo ERP-omgeving ook bij single client ERP-systemen van toepassing zijn, maar dat vooral de impact sterk toeneemt en dat de kwaliteit van de risicoanalyse van een lokale entiteit daarom ook van invloed kan zijn op de andere entiteiten.

In de praktijk zien we dat organisaties met een single client systeem zich dit langzaam beginnen te realiseren en vanuit het centrale management een risicoanalyse uitvoeren in samenwerking met de lokale entiteiten. Deze analyse leidt tot een centraal risicoanalysedocument waarin de overkoepelende processen met risico’s zijn opgenomen en waarin, voor zover nodig, aanvullende processen en risico’s zijn opgenomen voor de lokale onderdelen.

Figuur 4 geeft de relatie weer tussen de verschillende controlemaatregelen. De IT general controls zijn de controls die zekerheid bieden over de continue effectiviteit van de geconfigureerde controlemaatregelen en de controlemaatregelen die afhankelijk zijn van de IT-applicatie. Eén van de belangrijkste IT general controls is hierbij het wijzigingsbeheer.

C-2008-3-vdHeuvel-04

Figuur 4. Relatie tussen diverse typen controls.

Business process controls

De impact van single client ERP komt vooral naar voren als moet worden vastgesteld welke internecontrolemaatregelen gekozen gaan worden. Gezien de impact die risico’s kunnen hebben op de single client omgeving, is een belangrijke rol weggelegd voor de IT application controls, de preventieve maatregelen, zoals configuratie en autorisaties. Een OpCo kan echter niet zomaar harde maatregelen implementeren zonder daarvan de mogelijke impact te kennen op andere organisatieonderdelen.

We zien in de praktijk dat organisaties steeds meer op centraal niveau vaststellen welke maatregelen worden ingevoerd. Waar de lokale entiteiten afwijken van de standaard, worden – al dan niet als maatwerk – aanvullende maatregelen opgesteld. Het is bij deze centrale analyse vanzelfsprekend van belang dat alle risico’s voor de lokale entiteiten worden meegenomen.

In de praktijk blijkt dat organisaties met single client vaak nog niet voldoende in staat zijn voor de single client omgeving organisatiebrede interne beheersing op te zetten. Naast de standaardisatie van bedrijfsprocessen is ook uniformering van internecontrolemaatregelen nodig. Op centraal niveau wordt vaak wel een raamwerk voor interne beheersing ontwikkeld en beschikbaar gesteld, maar blijkt tegelijkertijd dat het management van de lokale OpCo’s zelf ook bezig is met het uitvoeren van een risicoanalyse en het identificeren en implementeren van beheersingsmaatregelen. Hierbij maakt het management van de lokale OpCo lang niet altijd gebruik van het centraal aangeleverde raamwerk.

Daarnaast is een belangrijke voorwaarde voor het effectief en efficiënt beheersen van de single client omgeving dat voornamelijk gekozen wordt voor harde preventieve maatregelen en deze alleen aan te passen wanneer dit geen problemen oplevert voor de single client als geheel. In de praktijk blijkt nog maar beperkt gebruik te worden gemaakt van deze maatregelen, niet alleen door ontbrekende kennis over de mogelijkheden van de applicatie maar ook doordat in de praktijk de standaardisatie van de processen geringer is dan in theorie beschreven, waardoor eenduidige configuratie en autorisaties nog niet mogelijk zijn.

In de volgende paragraaf wordt in meer detail ingegaan op de invloed van single client ERP op configuratie en autorisaties.

IT general controls

Door het gebruik van single client ERP neemt ook het belang van de IT general controls toe. Niet alleen maken meerdere organisatie-entiteiten nu gebruik van hetzelfde systeem, maar ook wordt vaak meer gesteund op de geprogrammeerde, preventieve maatregelen binnen het ERP-systeem waardoor wijzigingsbeheer en gebruikers- en autorisatiebeheer van groter belang worden.

De IT-organisatie zelf verschuift veelal van lokale beheerorganisaties naar meer centraal beheer, bijvoorbeeld via een shared service center met een helpdesk waardoor betere beheersing van IT mogelijk is. Veel beslissingen en goedkeuringsactiviteiten worden genomen in samenwerking met de lokale entiteiten. Hiervoor worden nieuwe overleggroepen in het leven geroepen of het eigenaarschap van delen van het systeem (bijvoorbeeld een deel van de autorisatiestructuur) wordt belegd bij het lokale management.

Gebruikers- en autorisatiebeheer

Het wijzigen van gebruikers en autorisaties en het toekennen van autorisaties aan gebruikers mogen alleen plaatsvinden na expliciete goedkeuring. Daarom dient het eigenaarschap van gebruikers en autorisaties te zijn belegd en dient in de processen steeds rekening te worden gehouden met de impact van een wijziging op het single client ERP-systeem als geheel.

Het eigenaarschap van reguliere gebruikers ligt bij de lokale entiteiten. Het eigenaarschap van speciale gebruikers zoals systeembeheerders, batchgebruikers, workflowgebruikers, interfaces en de helpdesk ligt op centraal niveau.

Voor het onderhoud van autorisaties geldt dat in een single client ERP-systeem bij voorkeur een zogeheten autorisatietemplate aanwezig dient te zijn, waarin de standaardtaken en -functies zijn vastgelegd die vervolgens kunnen worden uitgerold naar de diverse entiteiten. Het eigenaarschap van de template dient, gezien de impact op de gehele organisatie, altijd centraal te zijn toegewezen. Het eigenaarschap van de afgeleide sets autorisaties ligt bij de OpCo.

De security manager zal aan de hand van beschikbare autorisatierichtlijnen moeten vaststellen of aangevraagde wijzigingen op centraal niveau kunnen worden doorgevoerd. De security manager dient de eigenaar van de template te adviseren over de impact van de geplande wijziging.

Door de complexiteit van autorisaties, vooral in een single client ERP-systeem, dient de organisatie te beschikken over geautomatiseerde tools (bijvoorbeeld SAP GRC Access Controls, Approva, CSI AA) om de autorisaties op een beheerste wijze toe te kennen en te monitoren. Rapportages kunnen centraal worden uitgevoerd en gedistribueerd aan de lokale entiteiten.

Wijzigingsbeheer

Net als bij gebruikers- en autorisatiebeheer geldt dat voor wijzigingen goedkeuring vereist is en dat het eigenaarschap van de systeemconfiguratie dus toegekend moet zijn. Voor configuratie-instellingen die onafhankelijk zijn van een OpCo geldt in principe dat het eigenaarschap centraal ligt. Bij een verzoek tot wijziging dient dan een uitgebreide impactanalyse te worden uitgevoerd om vast te stellen wat de gevolgen voor de single client als geheel kunnen zijn.

Naast OpCo-onafhankelijke (systeemoverstijgende) parameters kent ERP ook instellingen die in meerdere of mindere mate afhankelijk zijn van het organisatieonderdeel (bijvoorbeeld factuurtoleranties). Alhoewel deze instellingen zijn gebaseerd op centrale richtlijnen (bijvoorbeeld inkoopbeleid) zal de OpCo eigenaar zijn van deze instellingen. Wederom geldt dat een impactanalyse vereist is voordat een wijziging wordt doorgevoerd.

De invloed van single client ERP-systeem op de audit

De IT-auditor kan op diverse wijzen betrokken zijn bij het beoordelen van (onderdelen van) de interne controle in een single client ERP-omgeving. Dit kan bijvoorbeeld zijn in opdracht van de accountant bij het uitvoeren van werkzaamheden voor de jaarrekeningcontrole. Daarnaast kan ook het management van een organisatie zelf de opdrachtgever zijn, bijvoorbeeld in het kader van Sarbanes-Oxley of in het kader van een pre- of post-implementatie-audit.

Het auditproces

Een belangrijke stap in het auditproces is het bepalen van de opdrachtgever en daaraan gerelateerd het eenduidig vaststellen van de scope van de audit. Het maakt een groot verschil of op verzoek van lokaal management of een lokale accountant de configuratie van één specifieke entiteit binnen de single client ERP wordt bekeken of dat vanuit een centrale audit alle entiteiten worden meegenomen. De reden waarom dit binnen single client ERP-systemen zo belangrijk is, is dat er zoveel entiteiten in één systeem zijn opgenomen dat er makkelijk te veel of te weinig entiteiten worden meegenomen in de werkzaamheden. De auditor dient specifiek vast te stellen welke entiteiten worden meegenomen (vergelijkbaar met regulier ERP), maar dient daarna ook concreet te maken hoe deze entiteiten in het single client ERP-systeem zijn gedefinieerd (bijvoorbeeld welke bedrijfsnummers).

Overigens betekent het auditen in een single client omgeving ook dat ondanks de gedetailleerde scoping issues kunnen worden gespot die niet direct binnen de scope vallen. Door het gebruik van tools en het bekijken van centrale tabellen verkrijgt de auditor veelal informatie over het gehele single client ERP-systeem. Als er hierbij specifieke punten worden opgemerkt, bijvoorbeeld de tolerantiegrenzen voor de OpCo in scope staan prima, maar voor andere OpCo’s staan deze helemaal verkeerd, dan dient de auditor hier wel iets mee te doen.

Het te hanteren normenkader is een ander aandachtspunt. In eerdere paragrafen is al genoemd dat in de single client omgeving steeds vaker vanuit het centrale management een controleraamwerk wordt opgesteld. Wanneer de opdrachtgever het centrale management is dan dient te worden besproken hoe het centrale raamwerk is opgesteld en welke betrokkenheid de OpCo’s hierin hebben gehad. Wanneer een opdracht wordt uitgevoerd voor het lokale management dan dient te worden nagegaan hoe het lokale controleraamwerk tot stand is gekomen. In de praktijk levert een snelle blik op het controleraamwerk voor de auditor al voldoende signalen op om het controlebewustzijn van de organisatie in te schatten. Bevat het document alleen standaardprocessen of zijn ook kenmerkende lokale processen opgenomen? Wat is de diepgang van de risicoanalyse? Is het een centraal aangeleverd of lokaal opgesteld document? Waar nodig worden voor aanvullende lokale processen aanvullende doelstellingen, risico’s en controlemaatregelen opgesteld.

Organisatie van de audit

Door het opnemen van meerdere entiteiten in een single client ERP-systeem komt de vraag op wie de audit zal moeten uitvoeren. Denk bijvoorbeeld aan een jaarrekeningcontrole waarbij de diverse lokale entiteiten geaudit moeten worden maar waarbij het risico van dubbel werk op de loer ligt als iedereen voor zichzelf lokaal de configuratie in het ERP-systeem gaat beoordelen.

Het zal niet verbazen dat een centraal en een lokaal auditteam betrokken zullen moeten zijn bij de audit op een single client systeem. Het centrale auditteam zal hierbij verantwoordelijk zijn voor het opstellen van het generieke controleplan. Dit generieke plan zal door de lokale auditteams vervolgens specifiek gemaakt moeten worden voor de lokale OpCo. Hierdoor worden andere belangrijke systemen ook in de scope meegenomen en kan het lokale auditteam andere aandachtspunten, zoals het voldoen aan de lokale wetgeving ook in de scope meenemen. Een mogelijk nadeel is de communicatie tussen de verschillende partijen en het risico dat controleplannen, wanneer deze eenmaal door centraal zijn aangeleverd, niet als zodanig gebruikt worden of juist te veel worden aangepast. Dit houdt in dat vanuit het centrale auditteam een team de leiding moet krijgen over de volledige audit.

Het centrale team voert de controle uit op configuratie en autorisaties en levert deze gegevens aan de lokale teams aan. Deze beoordelen vervolgens de gebruikerscontroles. Een veelgebruikte wijze om de centrale bevindingen aan de lokale auditors kenbaar te maken, welke vooral wordt gebruikt bij de jaarrekeningcontrole, is de zogeheten ‘comfort letter’. In de comfort letter is beschreven welke activiteiten de centrale auditors hebben uitgevoerd en wat de uitkomsten hiervan waren. Uit deze comfort letter zal dus blijken of de lokale auditors kunnen steunen op de centraal geteste internecontrolemaatregelen.

Inhoudelijke aandachtspunten

In dit laatste gedeelte wordt een aantal specifieke aandachtspunten genoemd rond het beoordelen van de interne controle in het single client ERP-systeem: configuratie, autorisaties en rapportages.

Configuratie

Bij het beoordelen van de configuratie van het systeem is het vooral van belang dat de IT-auditor zich realiseert wat de impact is van specifieke instellingen op het single client ERP-systeem als geheel. ERP kent instellingen op meerdere niveaus. Ten eerste zijn er de instellingen op gebruikersniveau, zoals gebruikersparameters. Ten tweede zijn er instellingen op organisatieniveau, zoals factuurtoleranties ingesteld per bedrijfsnummer. Tot slot zijn er de instellingen op systeemniveau, waarbij gedacht kan worden aan verplichte velden voor documenten.

Het type instelling bepaalt mede wie verantwoordelijk is en hoe wordt omgegaan met wijzigingen. Voor gebruikersafhankelijke instellingen ligt het eigenaarschap lokaal. De auditor zal de details van de instellingen moeten opvragen en bepalen hoe lokaal wordt omgegaan met wijzigingen hierin. Overigens betekent lokaal eigenaarschap niet dat geen centrale richtlijnen kunnen zijn opgesteld.

Instellingen op organisatieniveau zijn alle instellingen die de bedrijfsprocessen beïnvloeden op basis van de organisatie die wordt gebruikt bij het uitvoeren van een transactie zoals vrijgavestrategie op basis van vestiging. Voor instellingen op organisatieniveau geldt dat het eigenaarschap vrijwel altijd bij de OpCo ligt tenzij het overkoepelende organisatieonderdelen behelst. Voor instellingen die zijn gebaseerd op centrale richtlijnen – bijvoorbeeld inkoopbeleid bepaalt type vrijgavestrategie, financieel beleid bepaalt type tolerantiegrenzen – ligt de keuze voor de configuratiemaatregel veelal centraal maar kan de specifieke waarde – mandaten binnen vrijgave, hoogte tolerantiegrenzen – door de lokale entiteit worden bepaald.

Organisatieoverschrijdende instellingen zijn alle instellingen die het ERP-systeem beïnvloeden zonder directe relatie met een organisatieonderdeel. Denk hierbij niet alleen aan functionele instellingen zoals verplichte velden maar ook aan systeemsettings. Een wijziging in deze instellingen heeft zonder meer gevolgen voor elke OpCo die gebruikmaakt van het ERP-systeem. Het eigenaarschap van deze instellingen ligt altijd centraal en de wijziging zelf wordt, net als bij de overige typen instellingen, centraal uitgevoerd. De auditor zal vast moeten stellen dat de bevoegdheden tot wijziging beperkt zijn en alleen aan de juiste functies zijn toegekend.

Autorisaties

Autorisaties (en daarbij ook gerekend de authenticatie) dienen ervoor te zorgen dat gebruikers alleen die activiteiten kunnen uitvoeren die benodigd zijn voor hun functie en dat functiescheiding wordt gerealiseerd. De impact van single client ERP op autorisaties is vooral dat een dimensie wordt toegevoegd door te eisen dat gebruikers, tenzij anders bepaald, alleen transacties mogen uitvoeren voor de OpCo waarin zij werkzaam zijn. Niet goed ingerichte autorisaties geven al snel bevoegdheid om voor andere entiteiten werkzaamheden uit te voeren. De praktijk laat zien dat aan de simpele basiseis van ‘alleen autorisaties voor eigen entiteit’ vaak niet wordt voldaan.

Autorisatieconcept

Het realiseren van een solide autorisatiestructuur in een single client ERP-systeem begint met het opzetten van een centraal autorisatieconcept. Dit beschrijft de wijze waarop de functionaliteit van ERP wordt ingezet om de beveiliging vorm te geven. Om het autorisatieconcept in een single client ERP-omgeving beheerbaar te houden kan de organisatie gebruikmaken van templaterollen en afgeleide rollen. Indien een onderneming single client ERP heeft geïmplementeerd, dan heeft mogelijk in meerdere of mindere mate standaardisatie over de bedrijfsprocessen plaatsgevonden. In dat geval kan binnen het autorisatieconcept ook gewerkt gaan worden met standaardtaken en -functies door bijvoorbeeld samengestelde rollen te gebruiken. De auditor zal moeten vaststellen of deze functionaliteit in gebruik is en op een juiste manier wordt toegepast. Het gebruik van afleidingen en samengestelde rollen biedt de organisatie een hulpmiddel bij het inrichten van autorisaties voor meerdere entiteiten. Fouten zijn echter snel gemaakt en kunnen dan een tegengesteld effect opleveren.

Functiescheidingen

Functiescheiding in een single client ERP-systeem is in principe niet anders dan functiescheiding in een OpCo ERP-systeem, namelijk het voorkomen dat een gebruiker een kritische combinatie van transacties kan uitvoeren. Een verschil ligt echter in het feit dat er meer entiteiten in het single client ERP-systeem aanwezig zijn. Wanneer functiescheiding wordt bekeken, dient de auditor er zeker van te zijn dat beide transacties voor dezelfde OpCo kunnen worden uitgevoerd. Het invoeren van een inkooporder voor een vestiging van Operating Company A is immers niet in conflict met de mogelijkheid tot het invoeren van een goederenontvangst op een vestiging van Operating Company B.

Super users en systeembevoegdheden

Het gebruik van bijzondere bevoegdheden zoals zogenaamde ‘super users’ dient zoveel mogelijk te worden voorkomen (of in elk geval extra te worden bewaakt) omdat deze in single client ERP-omgevingen nog meer impact hebben dan in een regulier ERP-systeem. Hiermee wordt niet alleen functiescheiding tussen transacties verbroken maar ook de scheiding tussen organisatie-entiteiten.

Hetzelfde geldt voor de systeembevoegdheden. Dit zijn bevoegdheden voor de configuratie van het systeem of voor het beheer van het ERP-systeem inclusief uitvoeren van massawijzigingen. Misbruik van dit soort transactiecodes is bij ERP al kritisch maar kan in een single client omgeving extra grote gevolgen hebben omdat meerdere entiteiten afhankelijk zijn van de beschikbaarheid en de integriteit van het volledige ERP-systeem.

Maatwerk

Indien de standaardfunctionaliteit van een single client ERP-systeem niet voldoende is om alle bedrijfsprocessen te ondersteunen of om aan alle wensen van de gebruikers te voldoen, dan is het mogelijk dat maatwerk wordt ontwikkeld. Hierbij is het niet alleen van belang dat niet iedere gebruiker toegang heeft tot het maatwerk, maar ook dat de gebruikers die toegang hebben tot het maatwerk via dit maatwerk geen toegang krijgen tot gedeelten van de applicatie waartoe zij eigenlijk geen bevoegdheid moeten hebben. In de praktijk zien we lokaal veel maatwerk om specifieke deelprocessen te ondersteunen dat bovendien niet altijd is afgeschermd met de benodigde autorisatiecontroles voor specifieke acties of organisatie-entiteiten.

Rapportages

Rapportages zijn onder meer overzichtslijsten en uitzonderingslijsten die binnen het ERP-systeem worden uitgevoerd door eindgebruikers. Bij rapportages in single client ERP is het van belang dat deze met de juiste selectiecriteria worden uitgevoerd én met de juiste bevoegdheden. Indien een gebruiker een rapportage uitvoert voor zijn eigen OpCo maar hij past niet de juiste selectiecriteria toe dan kan dit leiden tot onjuiste uitkomsten. Hetzelfde geldt voor het uitvoeren van een rapportage met te weinig bevoegdheden. In dit geval kan de gebruiker verkeerde (= niet alle) uitkomsten krijgen zonder dat het systeem daarvoor een waarschuwing geeft. Het risico is dan aanwezig dat de gebruiker of het management beslissingen neemt op basis van onjuiste en/of onvolledige informatie.

Voor het maken van nieuwe rapportages of het wijzigen van bestaande rapportages gelden de eerder beschreven aandachtspunten rondom wijzigingsbeheer. Voor centrale (standaard)rapportages ligt het eigenaarschap centraal. Voor lokale (maatwerk)rapportages kan het eigenaarschap lokaal liggen.

Conclusie

Het uitvoeren van audit- en advieswerk gerelateerd aan single client ERP-omgevingen brengt specifieke aandachtspunten met zich mee. Hoewel op hoofdlijnen de werkzaamheden niet anders zullen zijn dan in een reguliere ERP-omgeving is het juist het detailniveau waarop een auditor de plank mis kan slaan. Hierbij is het van belang om voor start van de werkzaamheden duidelijk in kaart te hebben welke entiteiten binnen de single client in scope van de audit zijn. Daarnaast moeten er duidelijke afspraken worden gemaakt tussen het centrale auditteam en het lokale auditteam over welk team welke werkzaamheden uitvoert. Ten aanzien van controls is het duidelijk dat de General IT Controls van groot belang zijn, daar het single client systeem van groot belang zal zijn voor de organisatie. De mogelijke application controls die in een single client systeem kunnen worden aangetroffen, zijn gelijksoortig aan de application controls in een OpCo ERP-systeem. Bij het beoordelen van de application controls is het echter van groot belang dat de controls voor de OpCo’s in scope worden beoordeeld. Door duidelijke afspraken te maken tussen het lokale team en het centrale team zijn vervolgens schaalvoordelen mogelijk doordat de uit te voeren activiteiten ook maar eenmalig worden uitgevoerd.

Benchmarking IT application controls

Many organizations are implementing cost efficiency programmes to lower the cost of compliance. Besides the risk-based, top-down management assessment and audit approach, moving toward IT application controls in the (SOX) compliance framework also leads to additional cost efficiency. The challenge is, however, to implement a sustainable approach to test the operating effectiveness of these IT application controls on an annual basis. Benchmarking, or ‘baselining’ as it is also called, the IT application controls can enable that efficient approach to SOX. An ERP package such as SAP can facilitate this benchmarking strategy by clever use of the information and possibilities provided by the system, the specifics of which will be discussed in this article.

Introduction

The introduction of SOX placed enormous pressure on companies. During the first year, the demands to meet the basic requirements of the Act meant that many companies struggled simply to comply. In subsequent years, the issue of cost became more relevant. Now companies are struggling with how to react to IT opportunities and how to cut costs without endangering their compliance.

Because many companies faced serious dilemmas in striking a balance between complying with the regulations and keeping costs down, the SEC (US Securities and Exchange Commission) and PCAOB (Public Company Accounting Oversight Board, to oversee the auditors of public companies) issued new guidelines on what companies and auditors need to do in order to comply with SOX section 404. The new PCAOB standard, Accounting Standard no.5 (AS5), provides a more principle-based guideline on how auditors should conduct their audit of internal control (also known as Internal Control over Financial Reporting, or ICOFR). The new guideline does not change the fundamental requirements that SOX established for management and their auditors to report on the effectiveness of internal control systems. In short, the new guideline enables companies and their auditors to focus on high-risk areas, to concentrate only on areas that could harbour material misstatements, and to use the most practical routes to test the key controls and underlying systems.

The issuance of AS5 was followed by many discussions on how companies should adopt a risk-based control rationalization approach as part of a larger effort towards SOX optimization. These discussions centred on designing and deploying only the most effective and efficient controls to address financial reporting risks. Control rationalization applies a top-down, risk-based approach, eliminates unnecessary controls, uses risk-based testing plans, and optimizes the design of company-level and transaction controls. Other opportunities to further reduce the ‘cost of compliance’ may include using IT controls in the first place, embedding continuous testing or control framework integration ([Perk07]).

This article explores another opportunity AS5 provides to cut costs without endangering compliance. This is the possibility to use a benchmarking test strategy for automated controls, thereby significantly reducing an organization’s and external auditor’s efforts relating to testing controls on an ongoing basis. Although the efficient benchmarking strategy is applicable to automated controls in all ERP and IT systems, this article elaborates on practical implementation within a SAP environment.

The internal controls environment

Internal or external compliance is about behaviour in accordance with established guidelines, specifications or legislation, such as financial statements for example (focused on by SOX), but may also include intellectual property, privacy, etc. A risk assessment will identify the efficient and effective key internal controls in the main business processes. As the business processes are supported by IT or ERP systems, IT related business controls can be identified. Unfortunately, during the pressure of the first SOX years, it was primarily manual and detective controls that were identified. In the current SOX improvement projects, organizations are trying to find an optimum mix of manual and IT controls to leverage more of the relatively efficient and effective IT controls.

When talking about SOX management assessments or audits, three types of internal controls can normally be distinguished within the business processes (see also Figure 1):

Manual controls: these are the manual checks performed by people and can include monthly inventory counting, but also an activity such as checking the invoice against the goods receipt packing note and the purchase form before issuing a payment. As mentioned before, this type of control was mainly identified in the early SOX years and takes much time to test only ‘a sample’ to provide an indication of the operating effectiveness.
IT application controls: the IT application controls are the opposite of the manual controls. These controls are implemented in the IT or ERP systems and are used every time transactions go through the system. In other words, these controls are enabled and effective for the whole population, as these controls are normally settings in the IT or ERP systems. These controls can be tested in an efficient way, thereby reducing the cost of compliance. Examples of IT application controls are the three-way match, automatic invoicing after goods issue, purchase order approvals, interfaces, authorizations, and segregation of duties.
IT-dependent manual controls: these controls consist of a manual activity, on one hand, and of an automated activity determined by the system, e.g. the output of a report, on the other. The manual part still requires sample-testing if the organization used the report and the manual follow-up, and the automated part requires testing to determine if the report is reliable. The check by the accounts payable clerk to analyze possible errors and deviations on the invoice payment proposal list is an example of an IT-dependent manual control.

IT General Controls are embedded within IT processes that provide a reliable operating environment and support the effective operation of automated controls (application and IT-dependent manual controls) ([ITGI06]). IT general controls relevant for SOX include:

Program development
Program changes
Access to programs and data
Computer operations

When taking a benchmarking strategy into account, these IT general controls should be on a required level.

C-2008-3-deBruijn-01

Figure 1. Types of Internal controls in business processes.

The automated control challenge

The previous section outlined the opportunities of automated controls. Identification of automated controls and taking them into scope for management assessment or external audit constitute important steps in an efficient SOX approach. The next step is to test the design and operating effectiveness and to ‘baseline’ the controls. In general, the following ways or combinations can be distinguished ([Perk07]):

The user-acceptance test: automated controls should be part of a user-acceptance test (UAT). If the UAT is well documented and carried out at the appropriate quality level, these results can be taken into account for testing operating effectiveness.
Verification of settings / tables / parameters: in the current IT and especially ERP packages (like SAP), the mechanics of automated controls are ‘customized’ using the settings or parameters. Although it is often difficult to test the completeness of the operating effectiveness using the method, it can be very efficient.
Trial & error (falsification): test the operating effectiveness of the automated control in a test environment. In other words, does the automated control do what you would expect upfront? Of course, the test and production environment should be equal.
Audit software (CAAT): audit software can be used to provide evidence that all transactions of a specific business scenario have been processed according the expected script.
Application code analysis: a very time-consuming way to test the operating effectiveness of the automated control can be to analyze the application code.

There is no standard way to test the design and operating effectiveness of automated controls. Furthermore, methods are sometimes combined, as with the verification of settings and audit software when the IT general controls have some deficiencies, for example, or when absolute assurance is required for very important automated controls.

The assumption is that the automated controls do not change much after the first full test year (this is often a time-consuming change process). Although the test of operating effectiveness can be carried out much more quickly in subsequent years, a substantive effort has to be made by management and the external auditor. The challenge is to determine how the already more efficient reliance on automated controls can be used in an efficient test approach.

Benchmarking – the theory

The Special Topics appendix of AS5 deals with the benchmarking of automated controls. It states, ‘Entirely automated application controls are generally not subject to breakdowns due to human failure. This feature allows the auditor to use a “benchmarking” strategy.‘

And even though AS5 specifically addresses the possibility of using a benchmarking test strategy, it is not new, as section E122 of Auditing Standard No. 2 (AS2) specifically acknowledges benchmarking as a testing strategy permitted by the standard.

Traditionally, benchmarking referred to measuring a product or service according to specified standards in order to compare it with one’s own product or service. For example, the NASDAQ may be used as a benchmark against which the performance of technology stock can be compared. Another example is comparing or benchmarking IT costs with other business units or organizations.

Benchmarking as mentioned in AS5 is different in the sense that it implies a testing strategy for audited automated controls in subsequent-year tests. Benchmarking as such involves documenting and testing controls embedded in an organization’s applications and key reports, in order to determine whether they have maintained their integrity over time. In other words, if you are feeling well, you do not have to go the doctor every year or undergo a full-body scan. This approach is attractive since a full audit of controls in the first year without re-auditing them in subsequent years (unless a major change is made) represents a significant cost-saving opportunity.

AS5 set the ground rules for using a benchmarking test strategy. In short, if IT general controls related to change management are effective, and the automated control has been tested in the past, annual testing is not required. The benchmark only should be established periodically.

Preconditions

The following preconditions for using a benchmarking strategy must be taken into consideration:

The general controls over program changes, access to programs, and computer operations should be tested effectively when establishing the baseline (AS5 item B29).
The application should operate in a stable environment and there is only a limited number of changes (AS5 item B31).
The control should be matched to a specific program within the application (AS5 item B31).
There must be information regarding the programs in the production process to prove that controls within the program have not changed (AS5 item B31).
The benchmark must be re-established after a period of time (AS5 item B33).

Item 1 is self-evident, since the IT general controls provide a basic assurance regarding the performance of the automated controls.

For item 2, the frequency of changes is a strong indicator whether or not an automated control might be well-suited for benchmarking. Again this will be obvious, as benchmarking only works for automated controls that have not changed since setting the baseline.

Items 3 and 4 are less obvious, since much software no longer works with compilation dates for example. Complex ERP systems now cover large-scale business processes within the dynamic environments of today’s companies, so items 3 and 4 are certainly a challenge. This will be addressed specifically with respect to SAP later in the article.

Finally, item 5 is again self-evident, although it provides additional possibilities when companies integrate baseline activities into the extended scope of user-acceptance testing.

Defining the benchmarking test strategy

When defining a benchmarking test strategy, the following actions could be taken into account:

Step 1. Define the scope of automated controls for benchmarking

First and foremost, it is important to define the scope of automated controls that are well-suited for benchmarking. The controls should be either IT application controls or IT-dependent manual controls, where the IT part is the part to be benchmarked (the manual part should be tested for operational effectiveness each year). Generally, these controls are configurable parameters, custom-built routines, or queries that ensure the complete, accurate, timely and proper processing and reporting of (financial) transactions. Because automated controls often depend on more than one factor to work effectively, it is important to consider not only the front-end functionality but also the associated dependencies. For instance, an automated approval control in SAP R/3 may be configured to automatically approve three-way matched invoices below a specific Euro threshold. However, this control depends on the accuracy of the established threshold value (SAP setup or customization) and the assurance that only authorized individuals can access the configuration information. Similarly, as reports generated by an application depend on the integrity of the source data and the reporting system’s logic, it is critical to consider both when assessing the integrity of a report used to perform an IT-dependent manual control. This combined group of front-end automated controls and dependencies may be the starting point of your baseline scope definition.

When defining the scope, also consider efficiency. Given the work effort involved in establishing and maintaining the baselines, it is important for organizations to assess whether or not yearly testing might be a more efficient approach than benchmarking. For example, if testing a particular IT control can be established by a simple screen-print of configuration settings from the target system, this could cost less effort than providing evidence that the configuration control has not changed. To achieve the advantages of a baseline approach, organizations must limit their baseline scope to selected automated controls that require significant effort in testing. To ensure the benchmarking test strategy is beneficial, the following factors must be considered in advance:

The cost of the annual operating effectiveness testing of automated controls.
Whether and when changes to the applications, infrastructure, related infrastructure and controls are planned (an example is an upgrade of SAP R/3).
Whether there are any current deficiencies in IT general controls or application/automated controls.

Step 2. Validate that an initial baseline of scoped controls has been established

When defining the scope of the benchmarking tests, it is important to ensure that the existing key automated controls have already been identified and documented as part of the overall SOX approach. The baseline approach is less feasible for organizations that have known deficiencies in their IT general controls, especially in security and application change management. Before a benchmarking test strategy can redeem its promise, organizations must have demonstrated the effectiveness of their IT general controls.

C-2008-3-deBruijn-02

Figure 2. Example of benchmark strategy for automated controls.

Step 3. Define rotation schedule

Once the baseline has been established, the benchmarking test strategy provides evidence for a number of years. As mentioned, the benchmark must be re-established after a period of time (AS5 item B33). Although AS5 sets no rules, three years constitutes a good practice for an appropriate frequency for re-establishing baselines. It is also important to re-establish baselines where significant changes occur within the applications. When significant changes occur, integrating baseline activities into an extended scope of user-acceptance testing should only be considered when the application operates in a stable environment and a limited number of changes are expected after these significant ones.

Rather than re-establishing all baselines every few years, it may make sense to adopt a rotation schedule whereby a portion of automated controls are tested each year, thereby spreading the effort over several years. By carefully planning and extending the scope of user acceptance testing, the benchmarking test strategy provides a sustainable and efficient approach. As stated previously, the UAT must be well documented and carried out by (IT) staff with knowledge of process controls as well as of the functionality of the system.

Integrating baselining into the UAT process thus helps further reduce overall compliance costs, and facilitates early deficiency identification and rectification. In this way, you can begin to reap the long-term rewards of a benchmarking test strategy while the applications continue to maintain their integrity over time.

C-2008-3-deBruijn-03

Figure 3. Example of a benchmark rotation schedule.

The timing within a year of the rotation schedule is something to consider as well. Since there are three options, it is important to carefully plan them within the year. Testing to establish a baseline is best done early in the year (first quarter), so that if inaccuracies are detected there is time to rectify the control. The Baseline test itself, however, is best planned late in the year (end of third quarter) because little change can be expected in the rest of the year. And the User-Acceptance Test is mostly dependent on the delivery date of the automated system being developed and tested.

Benchmarking in a SAP environment

As described, benchmarking can be used to conclude that an automated control is effective without having to repeat the specific tests of the operation of the automated control. The nature and extent of the evidence that the auditor should obtain to verify that the control has not changed may vary depending on the circumstances, including the strength of the company’s program change controls.

A known challenge will be the AS5 requirement regarding the ‘compilation date’, which is not explicitly available in SAP. On this issue, the article will provide a practical solution for SAP with respect to the two types of automated controls that have been distinguished.

Although the following sections are more related to SAP, they nevertheless give guidelines for benchmarking automated controls in other ERP packages.

IT application controls

In SAP, many IT application controls have already been set up in the customization process (SAP transaction code SPRO). These settings are usually stored in tables. For example, the tolerance limits for the three-way matches are stored in the SAP table called ‘T169G‘. These settings are the current settings, in other words, there is no compilation date or audit trail on the previous settings (including dates). However, for the ‘compilation date’ required by AS5, there are two practical solutions in SAP:

Enabling logging on the specific customizing table

Standard SAP does not log all changes to the SAP tables. To allow SAP logging of specific SAP tables, the following steps should be performed.

First, the ‘REC/CLIENT‘ client setting or parameter should be set. Be careful when switching the REC/CLIENT in the client settings to Yes, because standard SAP will then log many tables including transactional tables. This will cause SAP to produce excessive logging, possibly slowing down the system and using considerable disk space.

The second step to select the SAP tables for logging is very important. The DD09L transaction code will enable you to include or exclude SAP tables in the logging. Besides selecting the SAP tables with the settings for the IT application controls to benchmark in scope (in the example T169G), logging other critical systems tables (such as T000, T001, TCURR, etc.) is also recommended. The transactional SAP tables should be excluded from logging, in order to prevent excessive logging.

Finally, the logging results for a certain period can be viewed using the RSTBHIST program. The program will give you a list of the current and previous setting, including the date of change. If the setting of an IT application control has not been changed since the last baseline, this control is suitable for benchmarking.

Using the SAP transport log

All transports to the production client are logged in SAP system tables, including the last transport (i.e. change) dates. The details of the changes to object classes in the transports are logged in the E071 SAP table. Object classes are also SAP tables, and enable to identify the last change dates to the settings of the IT application controls stored in those tables.

In the example (see Figure 2) you will find that table T169G has been transported a number of times to the production system. The Request/Task field can be linked to the E070 table to find the corresponding transport date.

C-2008-3-deBruijn-04

Figure 4. Benchmarking IT application controls using transport logs.

The last transport of the T169G table in the example shown in Figure 4 was 11 July 2006. If the baseline testing for this IT application controls was established after this date in 2006, the IT application control has not been changed since then. In other words, the setting is the same and the IT application control is suitable to be benchmarked for SOX purposes.

IT-dependent manual controls

IT-dependent manual controls in SAP are mainly the standard or custom-built SAP reports. The manual testing part of this IT-dependent manual control is dependent on the integrity of the SAP report. The purpose of benchmarking these reports is to identify whether or not the report has been changed since the last established baseline.

An easy way to identify the change dates of the SAP report is to use the TRDIR SAP table. The changes dates for all SAP reports and programs (including the custom-made, normally identified by a Z or a Y) can be found in this table (see Figure 5). This table shows the program name (i.e. SAP Report) and the last change date of that report. For example Z_RSPFPAR was created on 16 September 2006 and changed on 18 October 2006. This means that the report has not been changed in 2007 or 2008. If the baseline was established in 2007, this IT-dependent manual control is suitable for benchmarking.

Another example shows that although the Z0SAP_12 report was created in 2002, the report was changed in 2007. This report is therefore not suitable for benchmarking. A new baseline should be established first, before applying benchmarking in the future.

As mentioned previously, a well-executed and documented user-acceptance test could provide the required evidence for establishing baselines, which will really embed the compliance in the IT processes and further decrease the effort required.

C-2008-3-deBruijn-05

Figure 5. Benchmarking IT-dependent manual controls using change logs.

The above-mentioned methods for benchmarking the automated controls in a SAP environment are only possible in a well-controlled IT environment with effective IT general controls. However, in an environment with IT general control deficiencies, the methods explained above can still give the auditor insight into the changes to key IT application and IT-dependent manual controls. This information can be used in a risk assessment to choose a suitable IT management assessment or IT audit.

In conclusion

In the article entitled ‘Testing application controls’ by Van der Perk ([Perk07]) it was stated that the identification of IT controls in the business control frameworks is an important aspect of sustainable compliance. In a stable IT environment (limited IT general control deficiencies) using the benchmark strategy for automated controls, this can even lead to further reductions in the cost of SOX compliance.

This article gave a practical guidance for management and auditors on how to set up a benchmarking strategy for testing automated controls in their compliance testing. Organizations that want to embed the transparent benchmarking rotation schedule using UAT for re-establishing the baseline will need to have an already mature IT compliance organization.

One of the main challenges for benchmarking within a SAP environment is to identify the compilation dates. These compilation dates are not available in SAP, but the benchmark can still be conducted using the different change logs in SAP, as mentioned in this article. Another challenge is to identify the SAP tables that contain the IT application control settings.

In our opinion, the transparency needed to implement the benchmarking strategy can be seen as a step toward continuous monitoring of the effectiveness of automated controls using the upcoming GRC tooling.

References

[Brou06] P.P.M.G.G. Brouwers RE RA, M.A.P. op het Veld RE, and A. Lissone, Tool based monitoring en auditing van ERP-systemen, van hebbeding naar noodzaak, Compact 2006/2.

[ITGI06] IT Governance Institute (ITGI), IT control objectives for Sarbanes Oxley, 2006, (www.itgi.org).

[PCAOB AS2] www.pcaobus.org/Standards/Standards_and_Related_Rules/Auditing_Standard_No.2.aspx.

[PCOAB AS5] www.pcaobus.org/Standards/Standards_and_Related_Rules/Auditing_Standard_No.5.aspx.

[Perk07] L.J. van der Perk RA en P.N.M. Kromhout, Testen van applicatiecontroles, Compact 2007/3.

De impact van Supplier Relationship Management (SRM) op het bestaande inkoopproces

In de laatste jaren zien we een sterke toename in het gebruik van SAP Supplier Relationship Management (SAP SRM). Steeds meer organisaties zien SRM als het middel om het inkoopproces verder te stroomlijnen en beter te beheersen. Om deze resultaten ook daadwerkelijk te kunnen behalen dient SRM op een juiste wijze te worden ingezet. Dit betekent dat organisaties, maar ook externe partijen die op enigerlei wijze een oordeel of advies geven over beheersing van de inkoopprocessen, goed op de hoogte dienen te zijn van de impact die SRM heeft op de bedrijfsprocessen en het stelsel van internecontrolemaatregelen om die processen te beheersen. Tijd voor een overzichtsartikel waarin de auteurs meer inzicht geven in de functionaliteit van SRM, de integratie met het bestaande inkoopproces en de aandachtspunten voor interne controle.

Inleiding

Na een relatief langzame start zien we in de laatste jaren een sterke toename in het gebruik van SAP SRM. Steeds meer organisaties zien SRM als het middel om meer efficiency te kunnen behalen in het inkoopproces en het inkoopproces beter te kunnen beheersen. Denk bijvoorbeeld aan het gebruik van workflow ter ondersteuning van het inkoopproces. We zien echter ook genoeg organisaties die na implementatie van SRM niet tevreden zijn omdat SRM niet de verwachte resultaten oplevert. Er dient zich een vergelijking aan met de opkomst van Enterprise Resource Planning (ERP) in de jaren negentig waarbij veel organisaties kozen voor een ERP-implementatie als wondermiddel voor verdere integratie en optimalisatie van de bedrijfsprocessen maar hierbij lang niet altijd de gewenste resultaten behaalden.

Als we één ding geleerd hebben van ERP is het wel dat voor het behalen van de gewenste resultaten het maken van een juiste fit met de organisatie een randvoorwaarde is. Deze fit kan worden bereikt door het aanpassen van het systeem aan de bestaande processen en/of het herontwerpen van de bestaande processen om meer aan te sluiten bij de geïntegreerde aanpak van ERP. Voor SRM geldt hier min of meer hetzelfde. Er dienen belangrijke keuzen te worden gemaakt in het inkoopproces om vast te stellen op welke wijze SRM zal worden ingezet. Het feit dat SRM in meerdere varianten beschikbaar is (classic, extended classic en stand-alone) en bovendien zelf ook voortdurend aan verandering onderhevig is, maakt het er niet makkelijker op om deze keuzen te maken. Een gedegen kennis van de mogelijkheden en uitgangspunten van SRM is benodigd om niet voor onaangename verrassingen te komen te staan.

In dit artikel bieden wij een verder inzicht in SRM door naast het geven van een korte historie van SRM de functionaliteit van de diverse SRM-scenario’s toe te lichten. Hierbij wordt steeds de koppeling gemaakt met het reguliere inkoopproces zoals we dat kennen vanuit de SAP Enterprise Core Component (ECC)-omgeving waarin inkoop plaatsvindt met de SAP Materials Management (MM)-module.

Met de functionaliteit van SRM in gedachten maken we de stap naar interne controle. Door het gebruik van SRM vinden er verschuivingen plaats in de wijze waarop de organisatie risico’s binnen het inkoopproces af moet dekken. Niet alleen kunnen andere controlemaatregelen worden gebruikt, ook de plaats waar deze controlemaatregelen worden uitgevoerd kan sterk verschillen van de situatie zonder SRM. Denk bijvoorbeeld aan de keuze tussen het goedkeuren van bestellingen in SRM of in ECC en het realiseren van functiescheidingen over systemen heen. We lopen in dit artikel in vogelvlucht door de mogelijkheden van SRM heen waar het gaat om interne controle en laten zien dat de mogelijkheden van SRM impact hebben op de bestaande interne controle en de wijze waarop deze wordt geaudit.

Een korte historie

Elke organisatie heeft in meerdere of mindere mate te maken met een inkoopproces. Tot het inkoopproces worden alle activiteiten gerekend die gerelateerd zijn aan de aanschaf van materialen en diensten om goederen te produceren of te verhandelen en om de organisatie draaiende te houden (bijvoorbeeld kantoorartikelen en reserveonderdelen). Tot eind jaren negentig was het inkoopproces voornamelijk handmatig en daardoor veelal inefficiënt, foutgevoelig en duur. Ook was het moeilijk om daadwerkelijk inzicht te verkrijgen in het inkoopproces en het goed te kunnen beheersen.

Met de implementatie van ERP in de jaren negentig kon inkoop worden ondersteund door geautomatiseerde systemen waardoor inkoop al meer efficiënt kon worden uitgevoerd. Ook kon gebruik worden gemaakt van geautomatiseerde goedkeuringsstromen en werd het inzicht in de inkoopactiviteiten versterkt door rapportages. Met de doorbraak eind jaren negentig van het gebruik van internet ontstond bovendien de mogelijkheid tot het elektronisch inkopen via internet (e-procurement), waarbij onder meer gebruik kon worden gemaakt van elektronische catalogi al dan niet onderhouden door de leveranciers zelf.

Alhoewel e-procurement en daarmee het automatiseren van het inkoopproces een belangrijke stap was in de optimalisatie van het inkoopproces, kwamen organisaties ook tot de conclusie dat alleen het automatiseren van inkoop niet voldoende was om de echte kostenbesparingen en voordelen te realiseren die mogelijk zouden moeten zijn rondom inkoop. Andere aandachtsgebieden zoals sourcing, contractbeheer en spendanalyses werden ook belangrijk geacht om de daadwerkelijke voordelen te behalen die met e-procurement mogelijk moesten zijn. Sinds enkele jaren heeft e-procurement zich verder doorontwikkeld tot het huidige Supplier Relationship Management (SRM).

Naast SRM zien we de laatste jaren ook ontwikkelingen op het gebied van elektronische facturatie om de van oudsher tijdrovende papierstroom en factuurcontrole te verminderen. Bij elektronische facturatie wordt e-procurement gebruikt om op elektronische wijze facturen te versturen, ontvangen, verwerken en archiveren. Met deze vorm van facturatie wordt de digitale inkoopcyclus voltooid. In dit artikel zal de focus liggen op e-procurement en niet op e-invoicing.

Supplier Relationship Management

Het is goed zich te realiseren dat SRM geen vervanging of nieuwe vorm is van e-procurement maar veel meer een overkoepelende term waaronder alle activiteiten vallen rondom het managen van de interacties tussen een organisatie en haar leveranciers. Hier maakt e-procurement (of Operational Procurement) onderdeel van uit. Gangbare onderdelen van SRM zijn:

Operational Procurement: ondersteuning voor het uitvoeren van de dagelijkse activiteiten rond de aanschaf van goederen en diensten vanaf het moment dat een aanvraag tot bestellen wordt gedaan tot en met de verwerking van de factuur voor de ontvangen goederen en diensten.
Catalog Management: ondersteuning voor onderhoud en publicatie van catalogi waarin producten en prijzen zijn vastgelegd voor specifieke leveranciers op basis waarvan kan worden ingekocht.
(Strategic) Sourcing: ondersteuning voor alle activiteiten rondom het selecteren van leveranciers inclusief het voeren van onderhandelingen (bijvoorbeeld via veilingen of tenders) en het vastleggen van afspraken.
Contract Management: ondersteuning voor het vastleggen en monitoren van contractuele afspraken met leveranciers.
Spend Analysis: ondersteuning van inkopers bij de analyse van inkopen per leverancier, product of productgroep.
Supplier Enablement: ondersteuning voor samenwerking van leveranciers met de organisatie, bijvoorbeeld door de leverancier toegang te geven tot voorraadgegevens en deze verantwoordelijk te maken voor het tijdig aanvullen van voorraden.

Alhoewel elke SRM-applicatie een andere indeling kan hanteren, is de functionaliteit in grote lijnen steeds te herleiden naar de genoemde kernonderdelen.

Het gebruik van SRM beoogt een aantal belangrijke voordelen. Hieronder worden enkele genoemd:

stroomlijnen van het inkoopproces in SRM inclusief het vervangen van handmatige door geautomatiseerde stappen waardoor de doorlooptijd van het inkoopproces zal afnemen;
nieuwe internecontrolemaatregelen in SRM waardoor afname in het aantal fouten en daarmee in duur correctiewerk;
gebruik van catalogi waardoor in te kopen goederen en diensten makkelijk te vinden zijn en er meer waarborgen zijn dat er van geautoriseerde leveranciers wordt ingekocht;
gebruik van spendanalyse waardoor meer inzicht ontstaat in uitgaven en leveranciersprestaties ter ondersteuning van het sourcingvraagstuk;
sterkere gerichtheid op sourcing, want doordat minder tijd benodigd is voor operationele inkoopactiviteiten kunnen (centrale) inkopers zich meer richten op het selecteren van leveranciers, het onderhandelen over contracten en het onderhouden van relaties.

De markt voor SRM-pakketten wordt geleid door drie partijen, namelijk SAP (15%), Ariba (14%) en Oracle (12%). Wij zullen ons in dit artikel richten op SAP SRM. Dit niet alleen omdat SAP marktleider is maar vooral ook omdat de auteurs zich in de praktijk voornamelijk bezighouden met bedrijfsprocessen en interne controle in en rondom SAP-omgevingen. Alhoewel SAP SRM centraal staat is hetgeen genoemd wordt in dit artikel grotendeels ook toepasbaar op andere SRM-pakketten.

SAP SRM

De start van SAP op het gebied van e-procurement was in 1999 met Business-to-Business Procurement (BBP), dat vrijwel direct daarna Enterprise Buyer Professional (EBP) werd genoemd. EBP was nog niet zo uitgebreid als het huidige SRM en richtte zich primair op het onderdeel ‘Operational Procurement’ ofwel het meer efficiënt maken van de dagelijkse inkoopactiviteiten. In de jaren daarna is EBP doorontwikkeld tot het huidige SRM 2007 (SRM 6.0) waarmee een volledige oplossing wordt aangeboden voor het managen van interacties met de leveranciers. De gangbare SRM-versie die op dit moment bij klanten wordt aangetroffen, is SRM 4.0.

SAP SRM bestaat uit drie kerngebieden die tezamen de eerdergenoemde generieke SRM-onderdelen afdekken. De door SAP gekozen gebieden zijn:

Operational Procurement

Dit kerngebied is gericht op ondersteuning van de dagelijkse inkoopactiviteiten in SAP SRM en is onderverdeeld in de volgende gebieden:

Self-service procurement (indirect procurement): gericht op decentraal inkopen door eindgebruikers van doorgaans indirecte materialen zoals kantoorartikelen en reserveonderdelen welke vastliggen in een catalogus.
Plan-driven procurement (direct procurement): gericht op centraal inkopen van kernmaterialen (grondstoffen, etc.) waarbij inkopen gekoppeld kunnen worden aan bestaande planningsapplicaties.
Service procurement: gericht op ondersteuning van het inkopen van diensten, zoals consultancy, tijdelijk werk en onderhoudsdiensten.

Strategic Sourcing

Dit kerngebied is gericht op ondersteuning voor het aangaan, vastleggen en monitoren van leveranciersrelaties en afspraken:

Catalogus content management: ondersteuning voor onderhoud en publicatie van catalogi.
Strategic Sourcing and Contract management: ondersteuning voor alle activiteiten rondom het selecteren van leveranciers inclusief het voeren van onderhandelingen en het vastleggen en monitoren van contractuele afspraken met leveranciers.
Spend analysis: ondersteuning van inkopers bij het analyseren van inkopen.

Supplier Enablement

Dit kerngebied is gericht op integratie van leverancier met inkoopprocessen:

Supplier self-registration: ondersteuning voor inkopers om potentiële nieuwe leveranciers te identificeren doordat leveranciers zichzelf bij de organisatie kunnen aanmelden.
Design collaboration: ondersteuning voor integratie met leverancier tijdens ontwerpfase, waarbij leverancier bijvoorbeeld kan meekijken naar specificaties.
Order collaboration: ondersteuning voor automatisch uitwisselen van inkoopdocumenten zoals bestellingen en facturen.
Collaborative replenishment: gericht op integratie met leverancier rondom voorraadbeheer, bijvoorbeeld door de leverancier toegang te geven tot voorraadgegevens en deze verantwoordelijk te maken voor het tijdig aanvullen van voorraden.

Om de bovengenoemde ondersteuning te kunnen bieden maakt SAP SRM gebruik van een aantal technische componenten waarvan de belangrijkste zijn:

SAP Enterprise Buyer (EBP): de kernmodule van SRM voor het afhandelen van inkopen vanaf het aanleggen van een winkelwagen tot het verwerken van de factuur. Tevens de vroegere benaming van SRM toen dit nog slechts gericht was op de operationele inkoopactiviteiten, nu onderdeel van de meeromvattende SRM-applicatie.
SAP Bidding Engine: component voor het uitvoeren van leveranciersselecties door middel van biedingen en veilingen.
SAP Supplier Self-Services (SUS): component die het mogelijk maakt leveranciers te integreren in de inkoopprocessen van de organisatie.
SAP Catalog Content Management (CCM): component voor het onderhouden en publiceren van catalogi. De steeds verdergaande ontwikkeling rondom SAP Master Data Management (MDM), de overkoepelende oplossing van SAP voor het onderhoud van stamgegevens, heeft SAP doen besluiten CCM niet verder te ontwikkelen maar het catalogusbeheer op termijn op te nemen in MDM via de ‘SRM-MDM Catalog’-oplossing.
SAP Business Information Warehouse (BW): dit is de overkoepelende business intelligence tool van SAP die door SRM wordt gebruikt voor het leveren van rapportages rondom inkoop.
SAP Exchange Infrastructure (XI): overkoepelende interfacetechniek van SAP die bij SRM wordt gebruikt voor het koppelen van diverse technische componenten en voor het uitwisselen van inkoopdocumenten met leveranciers.
SAP Enterprise Portal: overkoepelende oplossing van SAP voor het geïntegreerd aanbieden van applicaties aan eindgebruikers via een zogeheten portaal dat bij SRM wordt gebruikt om bijvoorbeeld de inkoopapplicatie te tonen.

Het bovenstaande geeft een overzicht van de functionaliteit van SRM en de diverse componenten waaruit SRM is opgebouwd. In het vervolg van dit artikel gaan wij voornamelijk in op de onderdelen Operational Procurement, Catalog Management en de onderliggende SAP EBP-component omdat hiermee het daadwerkelijke inkoopproces (ook wel Purchase-to-Pay of PtP genoemd) wordt ondersteund.

We zullen de relatie leggen tussen het klassieke PtP-proces en SRM, en daarna aangeven wat de impact is van SRM op de interne controle in en om het PtP-proces.

De integratie van SAP SRM met PtP

Het gebruik van SRM heeft een grote impact op het PtP-proces zoals dat wordt uitgevoerd zonder SRM. Niet alleen betekent de integratie met SRM dat de uitvoer van specifieke activiteiten van het back-end ERP-systeem naar SRM wordt verplaatst, er dienen ook keuzen te worden gemaakt rondom interne controle in PtP. Voordat wij zullen ingaan op de integratie van SRM in het PtP-proces, wordt eerst het PtP-proces kort geschetst.

De basis van PtP bestaat hoofdzakelijk uit drie stappen: het aanleggen van een bestelling voor benodigde goederen en diensten, het boeken van de ontvangst hiervan en het verwerken en betalen van de bijbehorende factuur. Alle andere activiteiten zoals het aanleggen van een bestelaanvraag, het uitvoeren van voorraadplanning en het contractbeheer zijn in principe alleen aanwezig om de drie hoofdstappen efficiënter en betrouwbaarder uit te voeren. In een contract kunnen prijsafspraken worden vastgelegd welke (al dan niet verplicht) gebruikt worden in een bestelling, voorraadplanning zorgt voor tijdig initiëren van nieuwe inkopen, etc.

In figuur 1 is het volledige PtP-proces weergegeven. De binnenste cirkel (groen) geeft de PtP-activiteiten weer inclusief de naamgeving zoals gehanteerd in de back-end inkoopmodule SAP Materials Management (SAP MM) en de back-end financiële module voor crediteurenbeheer SAP Accounts Payable (SAP FI-AP). In de buitenste cirkel (oranje) zijn vervolgens de equivalenten van de PtP-activiteiten in SRM weergegeven. Hierbij worden de diverse SRM-scenario’s, waarbij de verdeling van activiteiten tussen back-end ERP en SRM varieert, vooralsnog even buiten beschouwing gelaten.

C-2008-2-vdHeuvel-01

Figuur 1. Het Purchase-to-Pay proces.

Het mag duidelijk zijn dat dit inkoopproces algemeen geldend is en niet ineens anders wordt nu SRM wordt gebruikt. SRM wordt vooral ingezet om het inkoopproces efficiënter te maken, wat in principe gebeurt door stappen in het inkoopproces uit te voeren in SRM. Doordat activiteiten in SRM worden ondersteund door geautomatiseerde workflows kunnen deze stappen sneller uitgevoerd worden (bijvoorbeeld de goedkeuring van winkelwagens) en is tevens meer inzicht aanwezig in de huidige status van een bestelling.

We lopen de figuur langs en geven een toelichting bij de diverse stappen.

Winkelwagen (Shopping cart)

Elke inkoop start met een winkelwagen, het SRM-equivalent van een bestelaanvraag in SAP MM. De winkelwagen kan worden gebruikt om een zogenoemde ‘vrije tekst inkoop’ te doen waarbij de gebruiker een omschrijving opgeeft van de benodigde producten die bijvoorbeeld niet in de catalogus te vinden zijn, maar beter is natuurlijk om producten te selecteren uit een catalogus. In de catalogus ligt precies vast wat de prijs is van een bepaald product als dit wordt ingekocht bij een specifieke leverancier. Denk bijvoorbeeld aan catalogi voor kantoorartikelen. Hoewel het back-end ERP-systeem catalogi niet als zodanig kent, kan de doelstelling hiervan (prijs-product-leveranciercombinatie) het best worden vergeleken met een contract of inforecord. Er wordt later meer specifiek ingegaan op het catalogusbeheer.

Nadat de winkelwagen is vastgelegd wordt, afhankelijk van de SRM-instellingen, een goedkeuringstraject gestart. Deze goedkeuring, het equivalent van de vrijgavestrategie in SAP MM, is bijvoorbeeld gebaseerd op de waarde van de winkelwagen, de productgroep en de volledigheid van de winkelwagen (in het geval van vrije tekst bestellingen of onvolledige bestellingen). Via workflow wordt de winkelwagen langs één of meer goedkeurders gestuurd. Nadat de winkelwagen is goedgekeurd, is deze beschikbaar voor verdere verwerking.

Bestelling (Purchase order)

Goedgekeurde winkelwagens worden in principe omgezet naar een bestelling in SRM en/of het back-end ERP-systeem. Waarin de bestelling wordt aangelegd, hangt af van het ingerichte SRM-scenario. Deze SRM-scenario’s worden later toegelicht.

Indien de bestelling in SRM wordt aangelegd, wordt een kopie naar het back-end ERP-systeem gestuurd. Indien de bestelling in het back-end ERP-systeem wordt aangelegd, is er in SRM geen bestelling aanwezig maar alleen de achterliggende winkelwagen die als bron diende voor de bestelling.

Het omzetten van een winkelwagen naar een bestelling kan volledig automatisch plaatsvinden, bijvoorbeeld indien deze is gebaseerd op een catalogus. Alle benodigde informatie is dan bekend en de bestelling kan direct worden verstuurd. Indien er een vrije tekst inkoop is gedaan of er ontbreekt informatie, dan wordt de afdeling inkoop betrokken bij de bestelling. Hiermee wordt ook direct duidelijk dat juist het werken met catalogi de meeste efficiency oplevert doordat inkoop er zo min mogelijk bij betrokken wordt en zich meer kan focussen op zaken als sourcing.

Goederenontvangst (Confirmation)

Wanneer goederen worden ontvangen, wordt in SRM een confirmation gedaan, het equivalent van de goederenontvangst in SAP MM. Tevens wordt een kopie van deze boeking naar het back-end ERP-systeem gestuurd en gekoppeld aan de bestelling. De ontvangst kan ook direct in SAP MM worden geboekt. In dat geval wordt een kopie van de ontvangstboeking naar SRM gestuurd en gekoppeld aan de bijbehorende winkelwagen.

Factuurontvangst (Invoice confirmation)

De factuur die wordt ontvangen voor de geleverde goederen en diensten kan net als de goederenontvangst zowel in SRM als in het back-end ERP-systeem worden verwerkt. Afhankelijk van het systeem waar de factuur wordt ingeboekt, wordt tevens een gerelateerde boeking gemaakt in het andere systeem.

Anders dan bij de goederenontvangst, die vaak al in SRM wordt afgehandeld, wordt de factuur vrijwel altijd nog in het back-end ERP-systeem geboekt. De voornaamste reden hiervoor is dat de goederenontvangst in SRM niet veel meer omvat dan het bevestigen dat hetgeen in de winkelwagen staat ook binnen is gekomen (een functionaliteit die kan worden gebruikt in een SRM-workflow en die geen directe boekingen tot gevolg heeft). Voor de factuur dient echter veel meer informatie te worden ingevoerd waardoor het minder gemakkelijk is deze activiteit over te zetten. De financiële administratie werkt daarnaast toch al voornamelijk in het back-end ERP-systeem, en dus wordt het verwerken van facturen daarin meegenomen.

Zoals eerder genoemd wordt de factuur in het back-end ERP-systeem wel steeds vaker verwerkt via elektronisch factureren, waarbij na het scannen van de factuur deze via workflow langs de diverse behandelaars en goedkeurders wordt gestuurd. In dit artikel wordt elektronisch factureren buiten beschouwing gelaten.

De betaling van de factuur is geen activiteit die in SRM wordt uitgevoerd en is onderdeel van de reguliere betaalactiviteiten van de financiële administratie.

Stamgegevens (Master data)

Bij het uitvoeren van inkoopactiviteiten, zowel in SRM als in SAP MM, wordt een grote hoeveelheid stamgegevens gebruikt. Denk hierbij aan producten, prijzen, leveranciers, contracten, inkooporganisaties, etc. Deze stamgegevens dienen in beginsel om het inkoopproces te versnellen doordat zij niet steeds opnieuw hoeven te worden ingevoerd tijdens een inkoop maar direct worden meegenomen bij het selecteren van bijvoorbeeld een leverancier of product. Door dit kenmerk kunnen onjuiste stamgegevens in SRM of inconsistente stamgegevens tussen SRM en ERP echter grote impact hebben op het inkoopproces zoals onjuiste besluitvorming, vertragingen door correcties en – als de fout niet wordt opgemerkt – bijvoorbeeld het inkopen tegen onjuiste prijzen.

De meeste stamgegevens in het inkoopproces bestaan in zowel SRM als ERP. Alhoewel deze in beide systemen onderhouden kunnen worden is het gangbaar deze in ERP te onderhouden en daarna te repliceren naar SRM en waar nodig aan te vullen. Het spreekt voor zich dat er rondom stamgegevens voldoende internecontrolemaatregelen dienen te zijn om de integriteit van de stamgegevens te waarborgen.

Catalogusbeheer

Een speciale categorie stamgegevens zijn de catalogi. In een catalogus worden voor een specifieke (interne of externe) leverancier de producten met bijbehorende prijzen opgenomen waaruit kan worden gekozen bij het aanmaken van een winkelwagen. Door gebruik van een catalogus kan het inkoopproces verder worden versneld aangezien alle informatie rondom leverancier en prijs al is ingevuld en hierdoor de winkelwagen vaak automatisch kan worden omgezet naar een bestelling.

Oorspronkelijk maakte SAP SRM gebruik van een third-partyoplossing voor catalogi, genaamd Requisite. Dit was een relatief eenvoudige techniek volledig gericht op het beschikbaar stellen van product- en prijsinformatie aan de inkoper. Organisaties kwamen er echter al snel achter dat het publiceren van catalogi niet slechts een kwestie was van het periodiek uploaden van een nieuwe prijslijst, maar dat er ook een gestructureerde vorm van kwaliteitscontrole nodig was inclusief harmonisatie van onderhoud met andere stamgegevens over verschillende systemen heen. Om hierop in te springen heeft SAP enige jaren geleden een eigen oplossing ontwikkeld, genaamd Catalog Content Management (CCM), waarvan inmiddels versie 2.0 beschikbaar is.

Inmiddels is SAP zover dat zij het catalogusbeheer in beginsel niet meer los ziet van het onderhoud van andere stamgegevens. Het onderhoud van catalogi wordt vanaf nu dan ook ondergebracht in de overkoepelende SAP Master Data Management (MDM)-oplossing via SAP MDM Catalog. CCM wordt hiermee op korte termijn uitgefaseerd.

SAP SRM-scenario’s

In de vorige paragrafen is beschreven hoe SAP SRM integreert met het PtP-proces door het verplaatsen van activiteiten van SAP MM naar SRM. Maar welke stappen worden nu in SRM uitgevoerd en welke nog steeds in het reguliere back-end ERP-systeem? Dit hangt af van het SRM-scenario dat door een organisatie wordt gekozen en de specifieke invulling van dat scenario. SRM kent drie scenario’s, en wel:

Classic

SRM wordt primair gebruikt om winkelwagens aan te maken die na te zijn goedgekeurd in SRM verder worden verwerkt in het back-end ERP-systeem tot een bestelling. Er is dan ook geen bestelling in SRM anders dan de achterliggende winkelwagen. Alle vervolgacties zoals de ontvangst van de goederen en de factuur worden primair in het back-end ERP-systeem uitgevoerd, alhoewel het wel mogelijk is om via zogeheten ‘confirmations’ de ontvangst van de goederen en de factuur door referentie aan de winkelwagen via SRM te laten verlopen.

Extended classic

SRM wordt gebruikt om winkelwagens aan te maken en goed te keuren maar eveneens om de bestellingen die hieruit voortvloeien vast te leggen. Er wordt wel een kopie van de bestelling naar het back-end ERP-systeem gestuurd, maar deze kan daar alleen worden weergegeven en niet worden onderhouden. Alle vervolgacties zoals de ontvangst van de goederen en de factuur worden primair in SRM uitgevoerd via zogeheten ‘confirmations’, alhoewel het wel mogelijk is om de ontvangst van de goederen en de factuur via het back-end ERP-systeem te laten verlopen. Vooral voor de factuur geldt dat deze in de praktijk veelal nog gewoon via ERP wordt afgehandeld.

Stand-alone

SRM wordt gebruikt voor het gehele inkoopproces en er is geen back-end ERP-inkoopmodule meer bij betrokken. Bij het ontvangen van de factuur in SRM wordt wel een boeking gemaakt in het achterliggende financiële systeem van de organisatie.

In de praktijk wordt vooral het classic scenario gebruikt. Dat is niet zo verwonderlijk want dit scenario leunt nog het meest tegen het back-end ERP-systeem aan (bijvoorbeeld SAP MM), waardoor de omslag naar SRM het minst groot is en veel gebruikers in inkoop, magazijnbeheer en de financiële administratie de werkzaamheden kunnen uitvoeren als voorheen. In veel gevallen is het de organisatie eerst te doen om het efficiënter afhandelen van de vele bestelaanvragen. Via het classic scenario kunnen de eindgebruikers deze aanvraag veelal zelf afhandelen terwijl de hoofddocumenten (bestelling, goederenontvangst, factuur) nog gewoon in het ERP-systeem worden verwerkt.

Steeds meer organisaties kiezen echter voor extended classic. Het voordeel van extended classic is dat het volledige inkoopproces in principe via SRM wordt uitgevoerd met de meeste mogelijkheden om de efficiëntie te verbeteren. Het gebruik van dit scenario betekent veelal wel dat grote groepen gebruikers moeten omschakelen naar het SRM-systeem.

Naast de verdere stroomlijning van inkoop biedt extended classic ook extra functionaliteit ten opzichte van classic. Behalve indirecte artikelen, zoals kantoorartikelen en reserveonderdelen, wil de organisatie vaak ook de goederen via SRM inkopen die als bron dienen voor het handelsproces of het productieproces, zoals grondstoffen en halffabricaten. Dit type inkopen wordt vaak ook gekoppeld aan een voorraadplanning (bijvoorbeeld via back-end ERP). Hiervoor gebruikt SRM het onderdeel plan-driven procurement, dat niet volledig wordt ondersteund door het classic scenario.

Stand-alone wordt in de praktijk het minst gebruikt en is vooral van belang voor organisaties die geen back-end inkoopsysteem hebben zoals SAP MM of dit niet meer willen gebruiken voor inkopen.

Kenmerkend voor alle SRM-scenario’s is het gebruik van workflow. Via workflow, wat niets anders is dan het afdwingen van een aantal activiteiten in een vooraf vastgestelde volgorde en door een vooraf vastgestelde groep personen, wordt niet alleen de tijdigheid van het inkoopproces gewaarborgd maar ook dat waar nodig alle inkopen worden goedgekeurd. Aangezien er doorgaans wordt gesteund op controlemaatregelen in de workflow (bijvoorbeeld goedkeuring) is het van belang dat wordt gewaarborgd dat niet buiten de workflow om kan worden gewerkt waardoor er bijvoorbeeld een goedkeuringsstap wordt omzeild.

SRM en interne controle

In de voorgaande paragrafen is getoond welke uitgebreide mogelijkheden SRM biedt om het inkoopproces verder te ondersteunen en daarmee efficiënter te maken. Of dit lukt hangt niet alleen af van de vraag of de functionaliteit van SRM juist wordt ingezet maar ook van de vraag of er rekening wordt gehouden met de nieuwe vraagstukken rondom interne controle.

Bij het ontwerpen van de controledoelstellingen en het vaststellen van de risico’s is het in eerste instantie niet wezenlijk van belang in welk systeem de processtap zich voordoet. Het inkoopproces is algemeen geldend en het risico van onjuiste prijzen of het inkopen bij niet toegestane leveranciers staat los van het systeem. Echter, om vervolgens te beoordelen of risico’s voldoende worden afgedekt dient wel degelijk rekening te worden gehouden met het systeem en het hierbij gekozen scenario. Er vinden verschuivingen plaats in de keuze van de controlemaatregelen maar ook in de plaats waar deze controlemaatregelen worden uitgevoerd.

Als voorbeeld kan de juistheid van inkoopprijzen worden genoemd. Het is een risico als de juistheid van prijzen via het ERP-systeem wordt afgedekt terwijl de bestelling mogelijk direct vanuit SRM wordt verzonden aan de leverancier. Andersom zijn alleen prijscontroles in SRM niet voldoende als de bestelling, na te zijn overgezet naar het back-end ERP-systeem, alsnog kan worden gewijzigd.

CARP in een SRM-omgeving

Om een afgewogen keuze te maken tussen het implementeren van internecontrolemaatregelen in SRM of ERP dient men te weten wat er mogelijk is in SRM en dan met name rondom de geprogrammeerde maatregelen. Aan de hand van het CARP-model, dat de internecontrolemaatregelen indeelt naar configuratie, autorisatie, rapportages en procedures, willen wij laten zien wat de invloed is van SRM op interne controle. Dit artikel heeft niet als doel een raamwerk van interne controle te geven voor gebruik in een SRM-omgeving. Doel is wel om de problematiek rondom interne controle in een SRM-ERP-omgeving te laten zien en de lezer bewust te maken van de keuzen die hierbij gemaakt moeten worden.

Configuratie in SRM

In tegenstelling tot het reguliere SAP R/3-systeem, waarin configuratiemaatregelen worden ingesteld via de zogeheten implementation guide (transactie SPRO), zijn er in SRM meerdere manieren om te configureren. Op hoofdlijnen zijn er binnen SRM drie verschillende manieren om configuratiemaatregelen te implementeren:

IMG/SPRO

Net als ERP kent SRM ook de klassieke IMG (bereikbaar via transactie SPRO) waarmee een aantal instellingen kan worden gemaakt om het systeem te sturen. De IMG van SRM is echter veel minder uitgebreid dan binnen ERP. Binnen SRM is de IMG vooral gericht op het maken van technische instellingen zoals interfaces (RFC destinations) en attributen en bijna niet op functionele instellingen zoals toleranties.

Business Add-In (BAdI)

Een BAdI is een stuk standaardprogrammacode dat aanwezig is in SRM maar alleen actief is als de organisatie dit als relevant beschouwt voor haar proces. Een voorbeeld van een BAdI is een documentcontrole op volledigheid van velden. Een BAdI is deels aan te passen door de organisatie waardoor maatwerk wordt gerealiseerd. Een voorbeeld van een dergelijke BAdI is dat er bij het goedkeuren van een aanvraag tot bestelling naar maatwerktabellen wordt verwezen waar de budgethouders in staan.

Webbrowser

Binnen SRM is het mogelijk via de webbrowser (dit is dus eigenlijk de voorkant van het systeem) systeeminstellingen te wijzigen en deze dient veelal als web-based IMG voor SRM. Bijvoorbeeld met transactie BBPCTOL is het mogelijk de toleranties in te stellen voor hoeveelheidsverschillen tussen leveringen en facturen.

Het instellen van configuratiemaatregelen op meerdere plaatsen maakt het geheel complexer dan in R/3. Alhoewel er weinig overlap zit in de diverse instellingen in elk van de drie categorieën, is niet altijd eenvoudig aan te geven waar specifieke controlemaatregelen ingesteld moeten zijn.

De aandachtspunten bij het inrichten of beoordelen van controlemaatregelen liggen (naast de benodigde kennis waar men wat kan instellen in SRM) vooral in de plaats in het proces waar een controlemaatregel wordt ingezet. Het moet worden voorkomen dat bepaalde controlemaatregelen kunnen worden omzeild (waarborg effectiviteit van maatregelen), maar aan de andere kant moeten ook niet te veel controlemaatregelen worden ingezet (waarborg efficiency van maatregelen). Enkele voorbeelden:

Prijzen kunnen worden ingevoerd in een catalogus die vervolgens wordt gebruikt in een winkelwagen. Het risico van onjuiste prijzen moet worden afgedekt in SRM (via beheer van catalogi, via vrijgave van winkelwagens) indien de winkelwagen na goedkeuring direct wordt omgezet in een bestelling en niet meer in R/3 verwerkt wordt. Voor winkelwagens die worden omgezet in een aanvraag tot bestelling in R/3 en daarna door inkoop verder worden afgehandeld, ligt de controle juist in R/3.
Vrijgavestrategieën (in verband met goedkeuring winkelwagens) kunnen worden ingesteld in SRM op de winkelwagen, maar ook in R/3 op een (aanvraag tot) bestelling. Wederom geldt dat afhankelijk van het gekozen scenario al dan niet in SRM en/of in R/3 wordt goedgekeurd.
Tolerantiecontrole voor het controleren van verschillen tussen de goederenontvangst en de bestelling kan zowel in SRM als in R/3 worden ingesteld. Afhankelijk van het scenario vindt de goederenontvangst in SRM of R/3 plaats.

Autorisaties / Logische toegangsbeveiliging

Autorisatiemaatregelen worden gebruikt om de toegang tot activiteiten en gegevens in SRM af te schermen. In tegenstelling tot SAP R/3 is de mogelijkheid om op basis van autorisaties af te schermen veel complexer doordat in SRM meerdere beveiligingsconcepten door elkaar worden gebruikt en deze op meerdere plaatsen in het systeem kunnen worden ingesteld.

Ten eerste gebruikt SRM bij het uitvoeren van activiteiten de gewone transactiecodecheck en ABAP-autorisatieobjecten zoals die ook in bijvoorbeeld SAP MM en SAP FI worden gebruikt. Naast de transacties, objecten en organisatorische waarden is het binnen SRM echter ook nodig te autoriseren via de organisatorische structuur. Dit is enigszins vergelijkbaar met SAP HR. Wanneer een gebruiker een winkelwagen wil vullen voor een bepaalde inkooporganisatie, dan dient deze gebruiker ook via de organisatiestructuur aan deze entiteit gekoppeld te zijn. Tot slot heeft een gebruiker zogeheten attributen nodig waarin waarden zijn opgenomen waarvoor hij activiteiten mag uitvoeren (bijvoorbeeld type winkelwagen, kostenplaats).

In figuur 2 is een totaaloverzicht gegeven. Elk van deze drie mogelijkheden wordt hieronder in meer detail beschreven.

C-2008-2-vdHeuvel-02

Figuur 2. Een totaaloverzicht van de autorisatiecheck in SRM.

Afschermen via klassieke ABAP-autorisaties

Binnen SAP SRM zijn er twee soorten transacties te onderscheiden:

Back-end transacties: deze kunnen alleen in de SAP GUI worden uitgevoerd. Deze transacties zijn met name gericht op customizing en systeemonderhoud.
Webbrowsertransacties: deze kunnen alleen in de SRM-webbrowser worden uitgevoerd. Deze transacties beginnen meestal met ‘BBP_’ en hebben hoofdzakelijk te maken met de daadwerkelijke inkoopfunctionaliteit en de configuratie van SRM op functioneel niveau, zoals toleranties en gebruikersbeheer.

Voor beide groepen van transacties geldt dat deze kunnen worden afgeschermd op transactiecodeniveau, maar ook op objectniveau. Voor webbrowsertransacties zijn er andere objecten beschikbaar (beginnend met ‘B_’) dan voor back-end transacties, wat logisch is omdat de back-end transacties meer gericht zijn op de systeeminstellingen en de customizing. Daarnaast is er voor de webbrowsertransacties slechts een beperkte set van organisatorische niveaus beschikbaar, waarvan de belangrijkste de inkoopgroep ($BBP_PURGRP) en inkooporganisatie ($BBP_PURORG) zijn.

Tot slot is er nog een groot verschil met SAP dat vooral van invloed is op het oplossen van autorisatieproblemen. In het geval er in SAP een autorisatieprobleem is, kan met transactie SU53 vrij snel achterhaald worden wat de oorzaak van dat probleem is. Voor webbrowsertransacties is dit niet mogelijk. Om een autorisatieprobleem op te lossen dient in het back-end door middel van transactie ST01 een system trace te worden aangezet om op die manier de oorzaak van het autorisatieprobleem te achterhalen.

Afschermen via organisatiestructuur

Binnen SRM is een organisatiestructuur (boom) aanwezig, vergelijkbaar met SAP HR, waarin een medewerker kan worden gepositioneerd. Door een medewerker aan een bepaalde positie in deze boom te koppelen ‘erft’ deze persoon een aantal toegangsrechten welke van toepassing zijn op die positie in de boom. Denk hierbij aan inkoopgroepen en inkooporganisaties. Daarnaast is een aantal attributen per gebruiker in te stellen, zoals beschikbare catalogi, die eveneens via de boom aan de gebruiker worden toegekend. De organisatiestructuur is binnen SAP SRM in te stellen met de transactie PPOMA_BBP.

Attributen

Het gebruik van attributen met betrekking tot autorisaties is relatief nieuw in vergelijking met SAP R/3. Attributen kunnen worden ingesteld in de organisatiestructuur waarbij in de configuratie kan worden aangegeven wie welke attributen via de webbrowser mag bekijken of wijzigen.

Een voorbeeld is een catalogus die pennen en potloden bevat. Deze catalogus kan wereldwijd als standaard worden gedefinieerd waardoor alle SRM-gebruikers waar ook ter wereld toegang hebben tot die catalogus. Catalogi kunnen ook op lokaal niveau worden gedefinieerd, namelijk voor gevallen waarin een lokale businessbehoefte het gebruik van een specifieke (bijvoorbeeld landspecifieke) catalogus noodzakelijk maakt.

Een tweede voorbeeld is dat er wereldwijd kan worden ingesteld dat de maximale bestedingslimiet € 500 is, waarbij dit – bijvoorbeeld afhankelijk van het land – op lokaal niveau kan worden aangepast op € 250.

Door attributen op een zo hoog mogelijk niveau in te stellen is de onderhoudbaarheid vanzelfsprekend het hoogst (slechts eenmalig instellen), maar de flexibiliteit het laagst (geldig voor iedereen in de organisatie). Figuur 3 toont een aantal veelgebruikte attributen.

C-2008-2-vdHeuvel-03

Figuur 3. Veelgebruikte SRM-attributen.

Door het gebruik van drie verschillende concepten wordt het instellen van bevoegdheden in SRM een stuk complexer dan in een klassieke SAP-omgeving. Eveneens betekent dit dat de huidige tools die gebruikt worden om de reguliere ABAP-autorisaties (transacties, objecten) te controleren niet altijd meer voldoen. Zie hierover meer in de paragraaf ‘Het auditen van SRM’.

De aandachtspunten bij het inrichten of beoordelen van bevoegdheden in SRM en R/3 zijn vooral de gekozen combinatie van de diverse beveiligingsmethoden en het ontstaan van systeemoverschrijdende autorisatievraagstukken (zoals functiescheiding).

De gekozen combinatie van methoden bepaalt of bevoegdheden in het inkoopproces volledig zijn afgedekt of dat er gaten in de beveiliging zitten. Denk aan de toegang tot bepaalde onderdelen van de organisatie, zoals de inkooporganisatie. Deze wordt toegekend via de organisatiestructuur maar ook via de ABAP-autorisatieobjecten.

De problematiek van systeemoverschrijdende bevoegdheidsvraagstukken zien we bijvoorbeeld terug in functiescheiding. Denk aan het aanleggen van een bestelling in SRM en het boeken van een goederenontvangst in R/3. Ook moet er in R/3 worden geautoriseerd op bepaalde aan SRM gerelateerde elementen, bijvoorbeeld een specifiek documenttype dat door R/3-gebruikers niet mag worden gewijzigd. Het spreekt voor zich dat het werken met deze systeemoverschrijdende bevoegdheidseisen het niet makkelijker maakt om bevoegdheden te beoordelen. De nieuwste generatie monitoring tools biedt dan ook veelal deze mogelijkheid al aan.

Rapportages

Rapportages als controlemaatregel worden in principe gebruikt om verstoringen in het procesverloop tijdig op te merken. In de klassieke SAP-omgeving zijn veel standaardrapportages aanwezig waarmee dit met wisselende diepgang kan worden gerealiseerd. In SRM is dit soort rapportages slechts beperkt aanwezig. Rapportages in SRM, die veelal via BW worden getoond, zijn voornamelijk gericht op uitgavenanalyse en analyse van de inkopen en niet zozeer op het vaststellen van uitzonderingen.

Het is lastig om als controlemaatregel beschikbare rapportages zodanig af te schermen dat daardoor wordt voorkomen dat één rapport door meerdere inkoopgroepen of inkooporganisaties kan worden gebruikt.

Een voorbeeld is transactie BBP_BW_SC3 (winkelwagens per product). Dit is een rapport dat meer duidelijkheid kan verschaffen in de status van een winkelwagen. Er kan zich voordoen dat organisatie A niet de winkelwagens van organisatie B mag zien omdat zij bijvoorbeeld concurrenten van elkaar zijn (ondanks dat ze bij dezelfde organisatie horen). In ERP kan door middel van het afschermen op bedrijfsnummer of vestiging in de rollen een scheiding worden aangebracht. In SRM is dit niet mogelijk voor dit rapport. Om een scheiding te bewerkstelligen kan er een user exit worden gemaakt en een organisatorisch niveau worden toegevoegd.

Nu we gezien hebben wat SRM is en hoe SRM functioneel kan worden ingezet (gebaseerd op de verschillende scenario’s), rijst de vraag hoe we SRM kunnen gebruiken als systeem waar de preventieve controles in worden vastgelegd.

In tabel 1 wordt ter illustratie een aantal risico’s van het inkoopproces beschreven en wordt gebaseerd op het SRM-scenario aangegeven waar de controles plaats dienen te vinden en hoe deze in het systeem gewaarborgd kunnen worden. Dit is vanzelfsprekend geen uitputtend overzicht.

C-2008-2-vdHeuvel-tab01

Tabel 1. Voorbeelden van risico’s en controlemaatregelen in diverse SRM-scenario’s.

Het auditen van SRM

In aanvulling op de functionaliteit van SRM en de impact daarvan op de interne controle willen wij ter afsluiting van dit artikel nog enkele aandachtspunten meegeven voor de audit in een SRM-omgeving. In de voorgaande paragrafen zijn we vooral ingegaan op de inhoudelijke aspecten van interne controle in SRM. Het spreekt voor zich dat deskundigheid in de materie van belang is bij het uitvoeren van een audit in een SRM-omgeving. Naast de inhoudelijke kant dient er ook rekening te worden gehouden met de meer organisatorische en procesaspecten van de (audit)opdracht.

Indien u als IT-auditor wordt gevraagd om een oordeel te geven over de betrouwbaarheid van een SRM-implementatie, dan is voor de scoping verstandig om eerst te bepalen voor welk scenario is gekozen. Indien het stand-alone scenario is gekozen, is er normaliter geen interface met een back-end ERP-inkoopmodule gerealiseerd en wordt het gehele inkoopproces via SRM afgehandeld. Hierdoor zal het beoordelen van de SRM-omgeving eenvoudiger zijn dan wanneer gekozen is voor het classic of extended classic scenario.
Bij het vaststellen van de scope wordt vaak het ‘beoordelen van SRM’ genomen, maar zoals aangetoond bevat SRM enorm veel functionaliteit en moet dus de vraag worden gesteld wat de reikwijdte van de audit is. Moet catalogusbeheer worden meegenomen bij het beoordelen van het inkoopproces of is het voldoende om de afhandeling van winkelwagens op te pakken? Tot hoever wordt het proces in het back-end ERP-systeem meegenomen?
Bij het opstellen van een normenkader dient men zich te realiseren dat bestaande producten zoals filtersets met functiescheidingsconflicten die voor bijvoorbeeld ERP worden gebruikt, moeten worden aangepast. SRM gebruikt immers nieuwe transacties met daarbij andere objecten en organisatorische waarden. Tevens wordt op attributen geautoriseerd. Daarnaast kunnen er transacties zijn die worden gestuurd op basis van workflowtabellen.
Bij het opstellen van een normenkader moet ook worden bedacht dat controleraamwerken niet een-op-een worden (her)gebruikt, aangezien rapportage en configuratie niet op dezelfde manier werken als in een ERP-omgeving. Voorbeelden van internecontrolemaatregelen zijn in de voorgaande paragraaf al uitgewerkt.
Bij de opdrachtuitvoering dient men zich te realiseren dat bestaande tooling nog niet altijd geschikt is om over meerdere systemen te auditen (denk aan functiescheidingen over twee systemen heen) of om geautomatiseerde maatregelen te controleren anders dan in ERP. Men dient te bepalen welke SRM-audittools beschikbaar zijn en of deze tools zijn geïntegreerd met de standaardtooling voor het ERP-systeem.
SRM is technisch gezien een volledig apart systeem met eigen infrastructuur, database, servers, etc. Dit betekent dat de algemene beheersingsmaatregelen hiervoor dienen te worden beoordeeld.
De beoordeling van de SRM-omgeving zal organisatorisch op centraal en decentraal niveau worden uitgevoerd. Op centraal niveau wordt bijvoorbeeld de goedkeuringsworkflow ingericht en onderhouden en op decentraal niveau wordt de goedkeuring van een winkelwagen door de budgethouders gegeven. Gebaseerd op de wijze waarop SRM wordt ingezet en de hoeveelheid geprogrammeerde maatregelen zal mogelijk meer werk door een centraal auditteam kunnen worden uitgevoerd.

Conclusie

De komst van SRM heeft een grote impact gehad op het reguliere inkoopproces zoals we dat kennen in de klassieke R/3-omgeving. Dit betekent eveneens nieuwe vraagstukken rondom interne controle. Denk aan het maken van keuzen rondom de plaats in het inkoopproces waar risico’s worden afgedekt en de komst van systeemoverschrijdende bevoegdheidseisen. Als we de algemene tendens volgen dat steeds meer gebruik wordt gemaakt van geprogrammeerde maatregelen in plaats van eindgebruikercontroles, dan is de conclusie dat juist kennis van de techniek en mogelijkheden van de systemen onontbeerlijk is. Laat hier nu net de complexiteit van SRM zitten door het kunnen instellen van configuratie en autorisaties op meerdere plaatsen en via meerdere methoden. Het inrichten of beoordelen van controlemaatregelen in een dergelijke nieuwe inkoopomgeving vergt van de auditor of adviseur dat deze zich bewust is van de invloed van SRM op het inkoopproces.

De schijnzekerheid van SAP-autorisatietools

Veel ondernemingen zijn zich aan het oriënteren op tooling om functiescheidingsconflicten in SAP te monitoren of hebben reeds een ondersteunende tool aangeschaft. Hierbij kan bijvoorbeeld gedacht worden aan GRC Access control van SAP (voorheen Virsa), Approva BizRights, SecurityWeaver, CSI-AA en SecurInfo. Succesvol gebruik van zo’n tool hangt sterk af van de wijze waarop de functiescheidingsregels zijn ingericht. Uit een aantal onderzoeken uitgevoerd door KPMG blijkt dat de ingerichte regels in de tooling vaak van beperkte kwaliteit zijn, waardoor er grote kans is dat de uitkomsten van de tool onnauwkeurig zijn. Het melden van ‘false positives’ en ‘false negatives’ is het gevolg. Dit heeft dramatische gevolgen voor het vertrouwen in de werking van de tool.

Om de gevolgen van ‘false positives’ en ‘false negatives’ te illustreren, maken we eerst even een zijsprongetje. Medio 2007 brak er brand uit in het Armando-museum in Amersfoort. Terwijl de vlammen uit het dak van de voormalige kerk sloegen, keken omstanders toe. Sommigen namen de moeite om de brand met hun mobiele telefoon te filmen. Pas na enige tijd dacht iemand eraan de brandweer te waarschuwen. Toen die ter plekke kwam, was het museum echter al reddeloos verloren. De brandmelders die in het museum waren aangebracht, hingen te hoog en hadden pas rook gesignaleerd toen het vuur al vernietigend om zich heen had gegrepen.

Tegenover dit geval van falende alarmmelding staat een berucht geval van alweer tientallen jaren geleden. Daarbij moest een brandweerkorps zeven, acht keer uitrukken om iedere keer ter plekke te ontdekken dat de brandmelding onterecht was geweest. Toen de brandweer voor de negende keer een brandmelding kreeg, was haar alertheid danig verminderd. Natuurlijk rukte zij wel uit, maar haar reactietijd was een stuk langer dan bij eerdere brandmeldingen. Wie gewend raakt aan onterecht alarm, wordt laconiek: het zal wel weer niets wezen!

Deze twee voorbeelden tonen aan dat er van alles mis kan gaan als een alarm niet goed ‘getuned’ is. Het alarm kan afgaan, terwijl er feitelijk niets aan de hand is. Daartegenover staan noodsituaties, waarbij juist geen alarm wordt afgegeven. In beide uiterste gevallen kan het eindresultaat dramatisch zijn.

Inleiding

Dit artikel gaat uiteraard niet over de brandweer of vergelijkbare hulpdiensten. Maar dit verhaal gaat wél over alarmmeldingen die al dan niet terecht zijn. En die in de context van een grote onderneming ook dramatische gevolgen kunnen hebben.

Sinds de boekhoudschandalen bij Enron en Worldcom is er in ondernemersland veel veranderd. Vooral door de omvang van de fraude en de dramatische gevolgen daarvan voor werknemers en particuliere investeerders, greep de Amerikaanse overheid na de fraude bij Enron en Worldcom stevig in. Dat leidde in 2002 tot de invoering van uitgebreide bedrijfsvoerings- en verslagleggingsregels voor beursgenoteerde ondernemingen. Ook Europese ondernemingen conformeren zich inmiddels aan deze Sarbanes-Oxley (SOx)-richtlijnen.

Eén van de rechtstreekse gevolgen daarvan is dat bij audits strenger wordt gecontroleerd op conflicterende bevoegdheden binnen een organisatie. In feite is er daarmee niets nieuws onder de zon. Starreveld, de grondlegger van de traditionele administratieve organisatie, hanteerde hieromtrent al duidelijk vuistregels. Zo was het volgens hem uit den boze dat één functionaris verantwoordelijk zou zijn voor twee of meer achtereenvolgende taken binnen een specifiek proces. Ter verduidelijking een voorbeeld: het is vragen om moeilijkheden als de functionaris die verantwoordelijk is voor inkoop ook de man is die leveringen in ontvangst neemt. Deze situatie maakt misbruik mogelijk. De taken Inkoop en Goederenontvangst zouden dus nooit op het bordje van één functionaris mogen liggen. Op vergelijkbare manier zijn er heel veel functierollen die in combinatie misbruik mogelijk maken. Om de kans op misbruik te beperken moet een organisatie dus voorkomen dat die combinaties van rollen door één medewerker uitgevoerd kunnen worden. Hoe belangrijk functiescheiding en interne controle is, werd overigens onlangs weer eens duidelijk door de gebeurtenissen bij de Franse bank Société Générale.

Inrichting van functiescheidingstools

De inrichting en implementatie van een functiescheidingstool is een project op zich met veel addertjes onder het gras, waarover later meer. Veel leveranciers van dergelijke tools hebben al enig voorwerk gedaan en leveren hun software met kant-en-klare tabellen. Daarin zijn min of meer algemeen geldende regels ten aanzien van functiescheiding als standaard opgenomen. Dit kan een nuttige basis vormen voor een organisatie die met deze software aan het werk wil. Echter, zowel met deze standaardtabellen als met tabellen die door een projectteam binnen een organisatie worden ingevuld, liggen nieuwe risico’s op de loer.

Die risico’s zijn onder te verdelen in twee typen, die enigszins vergelijkbaar zijn met de twee situaties rond brandalarmmeldingen aan het begin van dit verhaal. Ten eerste kunnen de tabellen zodanig zijn ingevuld dat risicovolle situaties wel degelijk aan de orde van de dag zijn, maar niet worden gesignaleerd. Anders gezegd: de vlammen slaan uit het dak, maar het alarmsysteem registreert niets, omdat dit niet juist is afgesteld.

Ten tweede kan, wederom door onjuist ingevulde tabellen, het aantal alarmmeldingen overstelpend groot zijn. Daarbij kunnen dan heel veel meldingen zijn van transacties die ten onrechte op die lijst staan, omdat ze helemaal niet risicovol zijn. Het gevolg van deze ‘ruis’ is dat werkelijk risicovolle transacties ondersneeuwen in de veelheid van onterechte meldingen en niet of nauwelijks meer opgemerkt worden. Dit is vergelijkbaar met het brandweerkorps dat zijn alertheid verliest als het diverse malen zonder reden is uitgerukt.

C-2008-2-Vreeke-01

Figuur 1. De invloed van foutieve functiescheidingsregels.

Let wel, dat deze twee foutsoorten veel voorkomen is geen diskwalificatie van een functiescheidingstool op zich. Die software werkt prima. De fouten zijn echter het gevolg van het onjuist inrichten van zo’n tool of het niet adequaat up-to-date houden van die inrichting.

Tijdens het implementeren van een functiescheidingstool kan een aantal verschillende fasen worden onderscheiden zoals in figuur 2 schematisch is weergegeven.

C-2008-2-Vreeke-02

Figuur 2. Fasen in een implementatietraject.

Risk Recognition

De Risk Recognition-fase is één van de belangrijkste fasen. In deze fase zal de onderneming door middel van bijvoorbeeld workshops moeten vaststellen welke functiescheidingen de onderneming door de tool wil laten monitoren. Deze fase is een niet te onderschatten fase. Immers, indien tijdens deze fase bepaalde risico’s niet worden geïdentificeerd, dan zullen deze risico’s ook niet in de tool worden opgenomen. Tijdens de workshops dienen de verschillende businessprocessen de functiescheidingsconflicten en het bijbehorende risico te definiëren. Daarnaast kunnen de procesexperts ook aangeven of er in de verschillende processen reeds risicomitigerende maatregelen zijn ingeregeld. Het is daarnaast aan te raden om de gedefinieerde conflicten voor te leggen aan bijvoorbeeld de externe auditor of advieskantoor om deze de gedefinieerde conflicten te laten valideren en eventueel te laten aanvullen.

Een mogelijkheid om functiescheidingsconflicten te definiëren is eerst de verschillende processtappen en vervolgens de verschillende conflicterende relaties in kaart te brengen. Een voorbeeld hiervan is voor het Purchase-to-Pay-proces in figuur 3 opgenomen.

C-2008-2-Vreeke-03

Figuur 3. Voorbeeld van het opstellen van functiescheidingsconflicten.

Daarnaast dient in deze fase reeds te worden vastgesteld hoe met conflicten zal moeten worden omgegaan. Hierbij zijn conflicten in drie categorieën in te delen:

Hoog risico-conflicten: conflicten die absoluut niet in het systeem mogen voorkomen. De organisatie accepteert geen mitigerende maatregelen. Nee is nee.
Medium risico-conflicten: conflicten die wel in het systeem mogen voorkomen maar die gemitigeerd moeten worden met compenserende maatregelen. De effectiviteit van de compenserende maatregelen moet periodiek worden getoetst.
Laag risico-conflicten: proceseigenaren/afdelingshoofden moeten weten dat deze conflicten voorkomen en periodiek controleren of de bewuste conflicten nog steeds als laag risico gelden. De proceseigenaren/afdelingshoofden tekenen uit hoofde van hun functie een ‘risk letter’ waarin zij onder andere aangeven het risico te hebben afgewogen.

Tip: In de meeste functiescheidingsregels die worden ontwikkeld, worden geen regels gedefinieerd voor afzonderlijke kritieke activiteiten in het systeem. Zo zouden er naast functiescheidingsregels apart regels moeten worden ontwikkeld voor het onderhouden van de verschillende soorten stamgegevens, of kritieke activiteiten zoals de betaalfunctie of periode sluiten. Door de monitorende rol van de tool zo uit te breiden, wordt de effectiviteit van de tool verhoogd.

In de Risk Recognition-fase is het van groot belang dat alle mogelijke functiescheidingen worden gedefinieerd. Immers, indien conflicten niet worden gedefinieerd dan zullen deze niet in de tool worden opgenomen. In deze fase is het aan te bevelen om naast de business process owners bijvoorbeeld de interne en externe auditors en de controllers te betrekken in het definiëren of beoordelen van de gedefinieerde risico’s om te voorkomen dat risico’s niet geïdentificeerd worden én om te voorkomen dat conflicten worden opgenomen in de functiescheidingslijst die geen risico voor de onderneming vormen. Indien in de Risk Recognition-fase niet voldoende aandacht wordt besteed aan het identificeren van de juiste risico’s, dan kan dit tijdens het in gebruik nemen van de conflicten veel invloed hebben op false negatives en false positives.

Technical Realization

In de tweede fase wordt gebouwd aan de Segregation of Duties (SoD). In deze fase worden de businessregels vertaald in SAP-transactiecodes en -autorisatieobjecten. SAP biedt veel verschillende mogelijkheden om een bepaalde activiteit uit te voeren. Zo zijn er bijvoorbeeld veel parametertransactiecodes gemaakt voor het boeken van financiële documenten, waardoor er, afhankelijk van de versie van SAP, meerdere transactiecodes zijn waarmee financiële documenten of facturen kunnen worden geboekt. Het is evident dat in een functiescheidingstool alle mogelijke opties voor het invoeren van data moeten worden meegenomen in de functiescheidingslijsten. Indien een transactiecode ontbreekt in de functiescheidingslijst, maar wel wordt gebruikt in het SAP-systeem, dan zullen er SoD-conflicten in het systeem voorkomen die wellicht niet bij het management bekend zijn. Het is van groot belang dat de impact van foutieve regels niet onderschat wordt. Indien de regels fouten bevatten dan worden de resultaten van de tool onbetrouwbaar. Dit kan grote gevolgen hebben voor de acceptatie van de tool door functionarissen die met de uitkomsten van de tool moeten werken. Het afstemmen van de resultaten en het komen tot oplossingen is dan een tijdrovend proces, omdat er veel overtuigingskracht aan vooraf dient te gaan.

In het tweede deel van het artikel gaan wij dieper in op de soorten fouten die wij tijdens verschillende reviews hebben aangetroffen. In de SoD-bouwfase is het van groot belang om personen te betrekken die zeer gedetailleerde kennis hebben van enerzijds de geïmplementeerde SAP-autorisaties, maar anderzijds van het SAP-autorisatieconcept op zich. Het team van deze personen kan immers gedetailleerd documenteren welke autorisatiecontroles worden uitgevoerd door de verschillende SAP-transactiecodes, welke controles door de onderneming zijn uitgezet en welke controles tijdens de implementatie zijn geactiveerd. Daarnaast is het aan te bevelen om de ingerichte functiescheidingsregels door een externe partij te laten beoordelen op juistheid en volledigheid.

Tip: Maak bij het definiëren van de functiescheidingslijsten gebruik van de best practices van bijvoorbeeld de toolleveranciers. Deze best-practicelijsten bieden over het algemeen een goed startpunt voor het technisch opstellen van een functiescheidingslijst. Let op: deze best practices zijn ook niet meer dan een goed startpunt. Daarnaast is het vaak ook nuttig om een autorisatiespecialist de blueprint van de functiescheidingsregels te laten beoordelen.

In de realisatiefase is het verder ook mogelijk om de kwaliteit van de ingerichte regels te testen, door bijvoorbeeld te kijken welke gebruikers toegang hebben tot bepaalde functionaliteit en deze te vergelijken met de statistieken. Indien er meer gebruikers voorkomen in de statistieken dan in de functiescheidingslijst, zit er waarschijnlijk een fout in de functiescheidingslijst. Deze kwaliteitsanalyse van de functiescheidingslijst kan tijdens het daadwerkelijk gebruik van de lijst veel discussie over de resultaten van de lijst voorkomen. Het testen kan ook door middel van een derde partij gebeuren. De derde partij runt dan met haar eigen tools een overeenkomstige lijst met regels. De resultaten zullen gelijk moeten zijn.

Risk Analysis

De derde fase in het implementatietraject is de Risk Analysis-fase. In deze fase wordt beoordeeld hoeveel conflicten en hoeveel werk er verwacht kunnen worden bij het oplossen van de functiescheidingsconflicten. Het aantal conflicten kan dan worden gecategoriseerd naar High, Medium of Low, of eventueel per proces Order-to-Cash, Purchase-to-Payment en Finance-to-Management.

Tip: Maak voor aanvang van het project een inschatting van het aantal conflicten door bijvoorbeeld een quick scan op de autorisaties te laten uitvoeren.

Daarnaast dient in deze fase een inschatting te worden gemaakt van conflicten die gemitigeerd kunnen worden of die opgelost kunnen worden door het ontkoppelen van autorisaties en het verplaatsen van bevoegdheid binnen de onderneming. Vooral bij het laatste is het van groot belang dat het autorisatieconcept zodanig is ingericht dat er eenvoudig wijzigingen in de koppeling van rollen aan gebruikers kunnen worden aangebracht. Indien het lastig is om bevoegdheden aan te passen doordat het autorisatieconcept niet eenvoudig is aan te passen, dan kan dit tot gevolg hebben dat er parallel aan het implementatietraject voor de functiescheidingstool ook een traject voor het opschonen of herinrichten van het autorisatieconcept gestart moet worden. Anders zult u continu dezelfde bevindingen moeten rapporteren, zonder dat deze opgelost kunnen worden. De impact van uw bevinding (denk aan het alarm) wordt dan steeds minder krachtig en leidt tot frustraties.

Het gebruik van gebruikersstatistieken kan in deze fase erg nuttig zijn. Het is mogelijk om uit SAP het daadwerkelijk gebruik van transactiecodes door eindgebruikers te downloaden. Met behulp van deze gebruiksstatistieken kan een aantal zaken in kaart worden gebracht:

Zijn er functiescheidingsconflicten in het systeem die niet gebruikt worden (technische conflicten)? Een gebruiker heeft de combinatie van conflicterende transactiecodes wel gekregen in zijn autorisatieprofielen, maar heeft een gedeelte van het conflict of beide gedeelten van het conflict niet nodig in zijn werkzaamheden.
Zijn er gebruikers die toegang hebben tot kritische functionaliteit (business of systeemactiviteiten) die deze bevoegdheid niet gebruiken? Door bijvoorbeeld ongebruikte masterdata-bevoegdheid te verwijderen is het mogelijk het aantal conflicten zeer snel te laten dalen.
Hoeveel transactiecodes gebruikt een eindgebruiker uit autorisatierollen? Hiermee is in kaart te brengen of een eindgebruiker een bepaalde autorisatierol in het systeem wel gebruikt. In de praktijk blijkt dat ongeveer twintig procent van de gekoppelde rollen aan eindgebruikers niet door de eindgebruiker wordt gebruikt.

In de praktijk blijkt dat ongeveer tachtig procent van de conflicten die in het systeem voorkomen door toegang tot een combinatie van systeemtransacties, niet door de gebruikers wordt gebruikt. Het verwijderen van de twintig procent ongebruikte rollen kan dan al snel een grote impact hebben op het aantal conflicten dat in het systeem voorkomt. Gebruikers hebben wel toegang tot de combinatie van transacties, maar hebben simpelweg gezegd geen gebruik gemaakt van die combinatie. Uit analyse blijkt verder dat het redelijk eenvoudig is om ongeveer dertig tot veertig procent van de rolallocatie dan te verwijderen daar de gebruikers geen gebruik maken van de transactiecodes in deze rollen. Deze opschoning vooraf draagt bij aan de effectiviteit van de monitoring.

Daarnaast is het mogelijk de functiescheidingslijst te runnen over de geïmplementeerde rollen. Indien blijkt dat er conflicten voorkomen binnen de rollen, dan is het niet eenvoudig om een gedeelte van een conflict van een gebruiker af te nemen, daar dit een aanpassing in een autorisatieconcept vergt. Voordat de resultaten van de functiescheidingsconflicten binnen gebruikers naar de business process owners kunnen worden gecommuniceerd, moet ervoor gezorgd zijn dat de gebruikte rollen op zichzelf conflictvrij zijn. Indien dit niet het geval is, kan het voorkomen dat tijdens de Risk Remediation-fase de opmerking gemaakt wordt dat de rollen moeten worden aangepast, wat tot een vertraging in het remediationproces zal leiden.

Ten slotte kan in de Risk Analysis-fase worden beoordeeld of de functiescheidingstool geen false positives of negatives bevat door de uitkomsten van de tool te vergelijken met de uitkomsten van een andere tool (bijvoorbeeld van de huisaccountant). Voorwaarde hierbij is natuurlijk wel dat in deze vergelijkende tool gelijksoortige functiescheidingsregels worden gebruikt.

Tip: Maak gebruik van statistieken om vast te stellen welke mogelijkheden er zijn om autorisaties van gebruikers af te nemen om zo ‘technische functiescheidingsconflicten ‘ te verminderen.

Risk Remediation

In deze fase dienen de functiescheidingsconflicten te worden opgelost door het conflict te verwijderen of door het risico te mitigeren. Daar uit ervaring blijkt dat er erg veel conflicten zullen voorkomen in het systeem, is het aan te bevelen om het remediationproces gefaseerd uit te voeren. Hierbij dient gestart te worden met de high risk-conflicten (conflicten die absoluut niet zijn toegestaan in het systeem) en daarna door te gaan met de medium risk-conflicten.

Starten met het remediaten van high risk-conflicten heeft als voordelen:

Over het algemeen zijn er niet bijzonder veel high risk-conflicten in het systeem (lijsten worden niet te lang).
High risks kunnen alleen worden opgelost door autorisaties af te nemen.
Door het beperkte aantal conflicten kunnen de business process owners worden getraind in het proces en in hun verantwoordelijkheden.
De grootste risico’s zijn als eerste opgelost.

Tevens zijn in deze fase de statistieken goed bruikbaar. Deze statistieken geven immers aan of gedeelten van conflicten snel van gebruikers kunnen worden afgenomen, doordat bepaalde functionaliteit in een bepaalde periode niet gebruikt is. Het afnemen van bevoegdheid heeft geen enkele impact op de bedrijfsvoering en de gebruikers merken niet dat er bevoegdheid is afgenomen.

Echter, indien u echt functiescheidingen wilt voorkomen, en zeker in kleine bedrijfsonderdelen, dan dient u het proces van change management te accepteren. Taken zullen echt van rol naar rol moeten worden verplaatst of taken kunnen centraal worden uitgevoerd.

Tip: Begin met het remediaten van de high risk-conflicten, waardoor stakeholders worden getraind in het remediationproces en het gebruik van de tool. Daarnaast is er de quick win dat de grootste risico’s het eerst worden opgelost.

In deze fase is het van groot belang dat de uitkomsten van de tool geen false positives of fase negatives bevatten. Indien er richting een gebruiker wordt gecommuniceerd dat bepaalde bevoegdheid zal worden afgenomen omdat hij een conflict heeft, dan moet te allen tijde worden voorkomen dat de gebruiker zal zeggen dat hij helemaal geen bevoegdheid heeft. Dit verstoort immers het communicatieproces met de verschillende gebruikers. Het gebruik van statistieken kan hier ook bij helpen doordat deze laten zien in hoeverre een gebruiker de bevoegdheid inderdaad niet heeft gebruikt.

Nadat alle high risks zijn opgelost, kan worden gestart met de medium risk voor bijvoorbeeld een workstream. Daar het aantal conflicten hierin naar verwachting redelijk beperkt zal zijn, blijft het remediationproces overzichtelijk.

Risk Mitigation

In de Risk Mitigation-fase worden voor de conflicten die niet opgelost kunnen worden door het afnemen van autorisaties, mitigerende maatregelen getroffen. Indien het niet mogelijk is om bevoegdheden te beperken dan kan gebruik worden gemaakt van mitigerende maatregelen. Hierbij dient een gedegen proces te worden ingericht voor het goedkeuren van conflicten, het koppelen/goedkeuren van de mitigerende controle en het zorg dragen/monitoren dat de mitigerende maatregel ook daadwerkelijk wordt uitgevoerd. Hierbij dient de vraag te worden gesteld tot hoever bepaalde verantwoordelijkheid gaat. Bij veel ondernemingen hebben wij gezien dat centraal een tool wordt ingericht voor het identificeren van functiescheidingsconflicten en dat er centraal een project wordt gestart om bevoegdheden af te nemen. Echter, zodra het over mitigerende maatregelen gaat dan wordt de bevoegdheid voor de controle heel snel decentraal neergelegd. De vraag blijft dan of decentraal de mitigerende controle daadwerkelijk wordt uitgevoerd. Op centraal niveau wordt een zeer goed werkend brandmeldingsalarm geactiveerd en de lokale brandweer geeft aan dat de brand meester is, terwijl het lokale kantoor geheel afbrandt.

C-2008-2-Vreeke-04

Figuur 4. Het mitigeren van conflicten.

Tip: Definieer standaard mitigerende maatregelen, inclusief testplan, voor een functiescheidingsconflict. Laat ook de mitigerende maatregelen door de business accepteren. Geef de verschillende businessunits geen (of beperkte) mogelijkheid om zelf mitigerende maatregelen te definiëren (behoudens lokale SoD-conflicten).

Tip: Vraag periodiek de resultaten op van de uitgevoerde mitigerende maatregelen.

Continuous Management & Monitoring

In de Continuous Management & Monitoring-fase zal periodiek de gehele set van functiescheidingsregels over de gebruikerspopulatie worden uitgevoerd. Hierbij dient onder andere te worden onderzocht:

Zijn er gebruikers met conflicten die niet zijn toegestaan in het systeem?
Zijn er gebruikers die conflicten hebben die niet zijn gemitigeerd?
Zijn de mitigerende maatregelen op effectiviteit beoordeeld, en hebben zij adequaat gewerkt over een periode?

Daarnaast moeten er procedures ontwikkeld zijn die waarborgen dat de geïmplementeerde functiescheidingsregels up-to-date zijn én moet periodiek worden onderzocht of de mitigerende maatregelen ook daadwerkelijk worden uitgevoerd en dat ze effectief zijn.

Ten aanzien van het testen van de mitigerende maatregelen zien wij de tendens dat de laatste paar jaar ook veel ondernemingen bezig zijn om tooling in te richten waarmee gemonitord kan worden of de key controls van een onderneming daadwerkelijk getest zijn. Daarbij worden met behulp van workflows mails naar de betreffende testers gestuurd om aan te geven dat ze een bepaalde control moeten testen en is een real-time status beschikbaar van de controls die niet effectief zijn of die overdue zijn.

Foutsoorten in detail

Het aantal foutieve meldingen dat het gevolg is van verkeerde toepassing van een functiescheidingstool is veel groter dan veel organisaties beseffen. In onze praktijk komen we een groot aantal fouten regelmatig tegen. Tabel 1 bevat de fouten die wij nogal eens tegenkomen in de verschillende functiescheidingstools. Deze fouten zullen hierna kort worden toegelicht.

C-2008-2-Vreeke-tab01

Tabel 1. Overzicht belangrijke fouten in functiescheidingsregels.

Het beoordelen van een functiescheidingslijst is erg complex. Indien op het autorisatieobject waardeniveau zal worden gekeken naar de conflicten dan zal de persoon die de conflicten zal beoordelen één of meer zeer grote Excellijsten krijgen met meer dan 20.000 entries. Daarnaast staan in deze lijsten vaak alleen de transactiecodes met autorisatieobjecten en de verschillende autorisatieobjectwaarden. Een typefout in zo’n lijst kan al tot gevolg hebben dat de resultaten van de lijst false positives of negatives bevatten.

1. Functiescheidingsconflicten

De volgende bevindingen komen wij tegen ten aanzien van gedefinieerde functiescheidingsconflicten:

Belangrijke functiescheidingsconflicten ontbreken in de functiescheidingslijst

Vaak wordt aan de hand van één of meer workshops een lijst gemaakt met functiescheidingsconflicten. Deze lijst dient vervolgens vertaald te worden naar de relevante transactiecodes en te worden ingericht in de functiescheidingstool. Indien de beheerder of de consultant deze activiteit niet uitvoert, kan het voorkomen dat het gedefinieerde conflict niet is opgenomen in de tool. Hierdoor zal niet over alle conflicten worden gerapporteerd. Daarnaast kan het voorkomen dat de accountant bepaalde conflicten belangrijk vindt die niet tijdens de verschillende workshops zijn gedefinieerd. Het is daarom belangrijk de accountant om input te vragen over de conflicten die opgenomen zullen gaan worden in de tool.

Functiescheidingsconflicten zijn opgenomen die in werkelijkheid geen conflict zijn

Bij een aantal organisaties hebben wij conflicten aangetroffen in de conflictenmatrix die geen conflict zijn. Als voorbeeld kan hierbij gedacht worden aan het onderhouden van stamgegevens binnen crediteuren en het goedkeuren van wijzigingen binnen crediteuren. Het goedkeuren van wijzigingen binnen crediteuren is een activiteit waarbij een gebruiker een wijziging op een kritiek veld kan accorderen. Deze kritieke velden die goedkeuring op wijziging vergen, worden vastgelegd in de customizing in SAP en worden gebruikt om een vierogenprincipe in te richten. Hierbij geldt dat degene die een kritisch veld (bijvoorbeeld het bankrekeningnummer) wijzigt in SAP, zijn eigen wijziging niet kan goedkeuren. Dit is een inherente controle in SAP. Het conflict onderhouden crediteuren en goedkeuren van wijzigen op crediteuren is dus niet relevant daar SAP dit reeds via de configuratie afdwingt.

2. Het toekennen van transactiecodes aan functiescheidingsregels

Het toekennen van transactiecodes aan de functiescheidingsregels is van groot belang. Indien gebruikte transactiecodes immers niet aan een functiescheidingsregel worden gekoppeld, zal de tool geen gebruiker vinden die gebruik kan maken van de transactiecode. Het is van groot belang dat alle relevante transactiecodes aan de regels worden gekoppeld, teneinde een zo nauwkeurig mogelijk resultaat te krijgen. Ten aanzien van het koppelen van transactiecodes aan regels hebben wij de volgende observaties:

Het toekennen van weergave-transactiecodes aan functiescheidingsregels

Bij veel ondernemingen zien wij dat bepaalde weergave-transactiecodes in de regels zijn opgenomen. Indien weergave-transactiecodes zijn opgenomen in functiescheidingsregels, dan zullen al snel veel gebruikers worden geïdentificeerd die toegang hebben tot een gedeelte van een conflict, daar weergavebevoegdheid over het algemeen breder is uitgegeven aan gebruikers dan aanmaak- of mutatiebevoegdheid. De kans op false positives is hierdoor relatief groot. Immers, veel gebruikers zullen toegang hebben om data weer te geven in het systeem. Veelvoorkomende weergave-transactiecodes zijn de transactiecodes waarmee wijzigingen kunnen worden weergegeven. Dit komt hoogstwaarschijnlijk door de slechte omschrijvingen die SAP bij deze transactiecodes heeft gegeven.

C-2008-2-Vreeke-05

Figuur 5. Voorbeelden van weergave-transactiecodes met misleidende omschrijving.

Het toekennen van customizing transactiecodes aan functiescheidingsregels

In een aantal gevallen hebben wij gezien dat customizing transactiecodes zijn toegekend aan de functiescheidingsregels. Over het algemeen kan worden gesteld dat customizing transactiecodes geen risico opleveren met betrekking tot het invoeren van transactionele gegevens. Tevens kan gesteld worden dat customizing transactiecodes binnen een productieomgeving weinig invloed hebben op de integriteit van het systeem, daar de productieomgeving dicht hoort te staan voor customizing. Indien het systeem open zou staan, heeft een gebruiker nog steeds bevoegdheid voor het aanleggen van een transport request nodig. De aanwezigheid van customizing transactiecodes heeft een negatieve invloed op het aantal false positives.

Het toekennen van transactiecodes die niets met de functiescheidingsregel te maken hebben

In een aantal gevallen hebben wij gezien dat transactiecodes erg ruim worden toegekend aan gedeelten van een functiescheidingsregel. Zo bevatten regels met de omschrijving verkooporders soms ook de transactiecodes voor contracten, offerteaanvragen en offertes of bevatten regels voor inkooporders ook de transactiecodes voor ATB’s en contracten. Dit maakt de discussie met de business er niet eenvoudiger op. Indien immers een conflict wordt gerapporteerd met inkooporders, zal men in het kader van remediation ook op zoek gaan naar de echte inkooptransactiecodes en niet naar de transactiecodes voor bijvoorbeeld ATB’s of contracten. De kans op false positives is dan erg groot. Dit heeft direct invloed op de acceptatie van de functiescheidingstool. De business process owners weten immers niet direct welke bevoegdheid er van een gebruiker moet worden ingenomen en zullen het conflict ook niet herkennen indien er ten onrechte transactiecodes in een conflict zijn opgenomen.

Het verschillend toekennen van transactiecodes aan functiescheidingsregels

Tijdens een aantal onderzoeken hebben wij gekeken naar de toekenning van transactiecodes aan gedeelten van conflictregels. Bijvoorbeeld in gevallen waarbij twee conflicten voorkomen waarbij bijvoorbeeld inkooporders worden gebalanceerd met leveranciers en goederenontvangsten. Het is dan op zijn minst opmerkelijk dat in de ene taak inkooporders meer transactiecodes zitten dan in de andere taak inkooporders. Het risico bestaat dan dat niet alle conflicten worden gerapporteerd (false negatives). Bij de SAP GRC Access controls tool is deze bevinding over het algemeen niet mogelijk daar in deze tool daadwerkelijk groepen van transactiecodes (functions) kunnen worden gecombineerd tot een risico. Hierdoor zullen de transactiecodes altijd hetzelfde zijn voor bijvoorbeeld de taak inkooporders (tenzij er meer gelijksoortige functies worden gemaakt).

Het ontbreken van transactiecodes in functiescheidingsregels

SAP bevat erg veel transactiecodes. Bij elke versie worden nieuwe transactiecodes geïntroduceerd. Het zal dus erg moeilijk zijn om volledig te zijn ten aanzien van het toekennen van transactiecodes aan gedeelten van een conflict. Het is evident dat het ontbreken van een transactiecode in een gedeelte van een conflict mogelijk kan leiden tot false negatives. Gebruikers zullen niet worden geïdentificeerd als gebruikers met een conflict. Vooral als transactiecodes ontbreken die wel in het autorisatieconcept gebruikt worden, is het risico op false negatives erg hoog. Het is aan te bevelen om in ieder geval te beoordelen welke transactiecodes daadwerkelijk in de autorisatierollen zijn opgenomen en kritisch te beoordelen of deze conflicten in een conflict thuishoren. Deze transactiecodes zijn immers bekend. Om te voorkomen dat ontbrekende transactiecodes tijdens het dagelijks onderhoud ongemerkt in SAP worden geautoriseerd, is het aan te bevelen om van een zo volledig mogelijke lijst van transactiecodes uit te gaan.

Voorbeelden van transactiecodes die vrijwel nooit in functiescheidingslijsten voorkomen, zijn de weergave-transactiecodes voor verkoopcondities (bijvoorbeeld VK13 en TK13). Met deze transactiecodes kunnen, mits er aanmaak-/wijzigbevoegdheid is, op autorisatieobjectniveau gewoon condities worden aangelegd.

Een ander voorbeeld zijn de parametertransactiecodes. Figuur 6 bevat de parametertransactiecodes uit een systeem voor de transactiecode FB01 (boeken van een financieel document). Deze parametertransactiecodes bieden over het algemeen dezelfde functionaliteit als de transactiecode waaraan gerefereerd wordt. In dit voorbeeld zijn de grootste verschillen het boekingsdocument en de posting key waarmee geboekt gaat worden. Echter, in het initiële scherm kunnen deze twee weer worden aangepast waardoor het mogelijk is een ander type boeking te maken. Zo kan standaard met de transactiecode F-02 een grootboekboeking worden gemaakt, maar indien het documentsoort en de posting key worden aangepast, zal er een factuur van een leverancier mee geboekt kunnen worden (net zoals met de FB01 kan). Het is dus van belang deze parametertransactiecodes mee te nemen in de functiescheidingslijst daar anders de kans op false negatives reëel is.

C-2008-2-Vreeke-06

Figuur 6. Voorbeelden van parametertransactiecodes.

Het ontbreken van maatwerktransactiecodes

In veel van de functiescheidingsregels die wij aantreffen in de systemen wordt uitgegaan van de standaard SAP-transactiecodes. De maatwerktransactiecodes (beginnend met een Z of een Y) worden vaak niet meegenomen in de functiescheidingsregels. Daarnaast zien wij dat indien de maatwerktransactiecodes wel zijn opgenomen in de set van regels, er geen autorisatieobjecten zijn gekoppeld. Belangrijke reden hiervoor is natuurlijk dat over het algemeen geen autorisatiecontroles in het maatwerk worden opgenomen.

3. Het toekennen van autorisatieobjecten aan transactiecodes

Indien een gebruiker toegang heeft gekregen tot een transactiecode in SAP, worden er binnen de transactiecode additionele controles uitgevoerd (bijvoorbeeld op toegang tot een vestiging of toegang tot een documentsoort). In SAP zijn er ongeveer 1400 autorisatieobjecten. Een autorisatieobject bevat verder minimaal één veld waarop geautoriseerd kan worden, maar meestal meer. Eén van de belangrijkste, veelvoorkomende, velden in een autorisatieobject is het veld ‘activiteit’, waarmee geregeld kan worden welke bevoegdheid een gebruiker krijgt (bijvoorbeeld aanmaken, wijzigen of weergeven).

Indien een gebruiker bijvoorbeeld de automatische betaalrun wil uitvoeren, heeft hij activiteitwaarde 21 nodig voor autorisatieobjecten F_REGU_BUK en F_REGU_KOA. Deze beide autorisatieobjecten bevatten meerdere activiteiten, echter het daadwerkelijk uitvoeren van de betaalrun kan alleen indien de gebruiker activiteit 21 heeft. Indien met behulp van de functiescheidingslijst wordt gekeken naar wie de betaalrun kan uitvoeren, dan moet in de lijst heel specifiek worden gekeken naar waarde 21. Wordt bijvoorbeeld gekeken naar F110 in combinatie met waarde 11 (uitvoeren proposal run) en 12 (wijzigen proposal), dan wordt gekeken naar wie een betaalvoorstel kan maken. Uit bovenstaand voorbeeld blijkt dat de toegekende waarde voor objecten van groot belang is voor de juistheid van de resultaten. Verkeerde waarden zullen grote invloed hebben op false positives en false negatives.

Bij het koppelen van autorisatieobjecten aan de transactiecodes wordt vaak uitgegaan van de door SAP uitgeleverde settings in tabel USOBT. Deze tabel dient echter te worden beschouwd als een goedbedoeld voorstel van SAP, maar dit voorstel is zeker niet volledig correct. Afhankelijk van de inrichting van het SAP-systeem zullen controles op autorisatieobjecten worden uitgevoerd. Daarnaast bevat het voorstel van SAP vaak te veel en soms ook te weinig autorisatieobjecten. Bovendien kan de beheerder of consultant autorisatiecontroles handmatig uitzetten in transactiecode SU24 of SU25.

Het gebruik van optionele autorisatieobjecten

Optionele autorisatieobjecten zijn objecten die alleen door SAP gecontroleerd zullen worden indien:

bepaalde settings in masterdata zijn gemaakt (autorisatiegroepen);
bepaalde settings in customizing zijn gemaakt (activeren van controles of het koppelen van autorisatiegroepen).

Indien deze settings niet zijn ingesteld tijdens de implementatie van SAP, zullen deze autorisatieobjecten niet door SAP worden gecontroleerd. Als we kijken naar transactiecode FB01, zien wij dat de in figuur 7 weergegeven voorstelwaarden vaak voorkomen in SAP.

C-2008-2-Vreeke-07

Figuur 7. Voorbeelden van de check indicator voor transactiecode FB01.

Uit dit overzicht blijkt dat de profielgenerator in SAP zal opkomen met de autorisatieobjecten die zijn aangevinkt bij de CM (check maintain)-indicator. Vaak wordt gedacht dat al deze controles worden uitgevoerd. Echter, de meeste van deze objecten hebben settings nodig in customizing of in masterdata:

F_BKPF_BED. Dit autorisatieobject zal alleen worden gecontroleerd indien de autorisatiegroepen binnen de stamgegevens van klanten zijn onderhouden. Indien deze velden niet zijn onderhouden, zal SAP geen controle uitvoeren op dit autorisatieobject.
F_BKPF_BEK. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien de autorisatiegroepen binnen de stamgegevens van leveranciers zijn onderhouden. Indien deze velden niet zijn onderhouden, zal SAP geen controle uitvoeren op dit autorisatieobject.
F_BKPF_BES. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien de autorisatiegroepen binnen de stamgegevens van grootboekrekeningen zijn onderhouden. Indien deze velden niet zijn onderhouden, zal SAP geen controle uitvoeren op dit autorisatieobject.
F_BKPF_BLA. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien autorisatiegroepen binnen de financiële documentsoorten zijn aangemaakt. Zijn deze velden niet onderhouden in customizing, dan zal SAP geen controle op dit autorisatieobject uitvoeren.
F_BKPF_BUP. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien autorisatiegroepen zijn gekoppeld aan de boekingsperiode. Zijn deze velden niet onderhouden binnen de boekingsperiode, dan zal SAP geen controle op dit autorisatieobject uitvoeren.
F_BKPF_GSB. Dit autorisatieobject zal alleen worden gecontroleerd door SAP indien er gebruik wordt gemaakt van business areas. Indien er geen business areas zijn aangemaakt, zal de gebruiker het veld business area niet invullen tijdens het maken van financiële boekingen en zal SAP op dat veld geen controle uitvoeren.

Hieruit blijkt dat (in veel gevallen) SAP voor transactiecode FB01 alleen een controle zal uitvoeren op de autorisatieobjecten F_BKPF_KOA en F_BKPF_BUK. Zelfs indien al deze optionele settings wel zijn gemaakt, dan nog dient erg kritisch te worden gekeken naar de toekenning van de autorisatieobjecten. Wat is immers de kans dat indien transactiecode FB01 wordt gebruikt om een crediteurenfactuur te boeken, dat SAP zal controleren op het object F_BKPF_BED dat de afscherming van debiteuren bevat?

Indien optionele objecten in de regels worden meegenomen, is de kans op false negatives aanwezig.

Het koppelen van te veel autorisatieobjecten aan transactiecodes

Indien te veel autorisatieobjecten binnen de functiescheidingslijst aan transactiecodes worden gekoppeld, dan bestaat het risico van false negatives. Immers, een eindgebruiker heeft minder autorisatie nodig dan daadwerkelijk door SAP wordt gecontroleerd. Buiten de optionele objecten wordt nog te veel uitgegaan van de default settings in transactiecode SU24. De objecten waar SAP mee opkomt voor een transactiecode zijn niet allemaal noodzakelijk om een transactiecode uit te voeren.

Het koppelen van te weinig autorisatieobjecten aan transactiecodes

In sommige gevallen worden ook te weinig autorisatieobjecten gekoppeld aan transactiecodes. Ook dit is weer afhankelijk van het gebruik van de settings in transactiecode SU24. Indien het niet duidelijk is welke autorisatieobjecten gecontroleerd zullen worden door een bepaalde transactiecode, dan zijn er drie mogelijkheden:

Kijk naar de autorisatieobjecten die soortgelijke transactiecode gebruiken. Deze soortgelijke transactiecodes maken over het algemeen gebruik van dezelfde autorisatieobjecten. (Transactiecode V-01 controleert dezelfde autorisatieobjecten als transactiecode VA01.)
Maak een autorisatierol met de transactiecode en koppel deze aan een testgebruiker. Test vervolgens de rol met de testgebruiker. Met behulp van de output van transactiecode SU53 kan worden weergegeven welk autorisatieobject wordt gecontroleerd.
Zet een autorisatietracé op de transactiecode (transactiecode ST01). Dit tracé zal gedetailleerd laten zien welke autorisatieobjecten en waarden worden gecontroleerd bij het uitvoeren van de transactiecode.

De inrichting van regels voor stamgegevens van crediteuren en debiteuren

Het opstellen van functiescheidingsregels voor de stamgegevens van crediteuren en debiteuren is erg moeilijk daar er verschillende smaken mogelijk zijn. Zoals bekend zijn er binnen de crediteurenstamgegevens drie verschillende views aan te maken:

de centrale view, die onder andere de bankaccount van de leverancier bevat;
de financiële view, waarin de crediteur aan een companycode wordt gehangen;
de inkoopview, waarin de leverancier aan een inkooporganisatie wordt gehangen.

Bij het opstellen van de functiescheidingsregels zullen afspraken gemaakt moeten worden over de views die moeten worden beoordeeld. In tabel 2 is een aantal voorbeeldconflicten weergegeven die crediteurenstamgegevens bevatten.

C-2008-2-Vreeke-tab02

Tabel 2. Voorbeelden van conflicten voor crediteurenstamgegevens.

In tabel 3 is een aantal voorbeeldconflicten weergegeven die debiteurenstamgegevens bevatten.

C-2008-2-Vreeke-tab03

Tabel 3. Voorbeelden van conflicten voor debiteurenstamgegevens.

Voor beide voorbeelden is de toekenning van views aan de objecten van groot belang. Immers, te veel objecten controleren brengt het risico van false negatives met zich mee. Voor de regels van zowel debiteuren als crediteuren kan als uitgangspunt worden gebruikt dat een functiescheidingsregel maximaal drie objecten mag controleren voor crediteuren- en debiteurenbeheer. Voor bijvoorbeeld de GRC Access controls tool heeft dit tot gevolg dat er meerdere functies moeten worden gemaakt voor de verschillende views in de masterdata. Voor zowel Approva als SecurInfo zal gelden dat afhankelijk van het conflict dat is gedefinieerd objecten voor masterdata verschillend moeten worden toegekend.

De inrichting van regels voor goederenontvangsten

Veel voorkomende conflicten hebben betrekking op Goederenontvangsten. Eén van de bekendste is het conflict Inkooporders vs Goederenontvangsten. Een belangrijke transactiecode om een goederenontvangst op een inkooporder te boeken is de transactiecode MIGO. In figuur 8 staan de belangrijkste autorisatieobjecten voor MIGO weergegeven.

C-2008-2-Vreeke-08

Figuur 8. Voorbeeld check indicators voor transactiecode MIGO.

Uit dit overzicht blijkt dat binnen MIGO een aantal autorisatiecontroles mogelijk is, afhankelijk van wat er met transactiecode MIGO gebeurt. Indien een gebruiker een inkooporder wil inboeken, dan is het duidelijk dat een controle op de autorisatieobjecten M_MSEG_BWE en M_MSEG_WWE zal plaatsvinden. Dit zijn immers de autorisatieobjecten voor het inboeken van een goederenontvangst op een inkooporder. De andere objecten zijn voor het inboeken van een goederenontvangst op een inkooporder niet relevant. We zijn immers niet geïnteresseerd in gebruikers die een reservering, een goederenbeweging of een goederenontvangst op een inkooporder kunnen laten plaatsvinden. De functiescheidingsregels voor goederenontvangst op een inkooporder dienen dus maximaal twee objecten te controleren. Maakt een gebruiker van transactiecode MB01 voor goederenontvangsten gebruik, dan is het natuurlijk duidelijk dat dezelfde objecten zullen moeten worden gecontroleerd.

4. Het toekennen van autorisatieobjectwaarden aan autorisatieobjecten voor transactiecodes

Het belang van de logica van de tool voor het lezen van objectwaarden

De logica waarmee de tool de functiescheidingsregels leest is van groot belang. Hierbij dient het doel van de tool niet uit het oog te worden verloren. Het doel van de tool is immers het vaststellen of een gebruiker een functiescheidingsconflict heeft. Dit zal de tool over het algemeen doen door te controleren of de gebruiker een transactiecode heeft aan de ene kant van het conflict (LHS) en een van de transactiecodes (RHS) aan de andere kant van het conflict. Daarnaast zal de tool kijken of de gebruiker alle autorisatieobjecten heeft en de daaraan gekoppelde autorisatieobjectwaarden.

Figuur 9 toont een gedeelte van een functiescheidingsregel zoals gebouwd in de Approva-tool. In dit voorbeeld vallen twee zaken op. Allereerst controleert de Approva-tool in dit geval maar één autorisatieobject voor transactiecode F-04. Een financiële boeking in SAP controleert over het algemeen twee autorisatieobjecten, te weten F_BKPF_BUK en F_BKPF_KOA. Het feit dat het object F_BKPF_KOA ontbreekt in deze regel kan tot gevolg hebben dat er door deze regel personen worden geïdentificeerd die eigenlijk geen conflict hebben (false positives). Indien we naar de waarden in het autorisatieobject kijken, dan zien we dat de ANY-logica relevant is. Indien een gebruiker waarde 01 (aanleggen) of waarde 02 (wijzigen) heeft, dan zal de Approva-tool de gebruiker identificeren als een gebruiker die toegang heeft. Indien we gedetailleerd naar de transactiecode kijken, dan wordt duidelijk dat het met deze transactiecode mogelijk is een financiële boeking te maken. Wordt iets in SAP aangemaakt, dan zal de gebruiker ten minste de bevoegdheid moeten hebben tot aanmaken (waarde 01). Indien de gebruiker iets wil wijzigen, heeft hij waarde 02 nodig. Bij deze transactiecode zal een gebruiker eerst moeten aangeven voor welk SAP-bedrijfsnummer hij iets wil posten. Op dat moment wordt direct gecontroleerd of de gebruiker ook daadwerkelijk bevoegdheid heeft tot aanmaken (01). Indien de gebruiker deze bevoegdheid niet heeft, zal hij ook niet verder kunnen in de transactiecode. Dit heeft dus tot gevolg dat de in figuur 9 weergegeven regel op objectniveau niet goed staat gedefinieerd. Waarde 02 is niet nodig voor het uitvoeren van deze transactiecode en het risico is dus aanwezig dat de tool mensen met de transactiecodewaarde 02 zal rapporteren.

C-2008-2-Vreeke-09

Figuur 9. Voorbeeld functiescheidingsregel zoals ingericht in Approva.

De ANY-logica voor objectwaarden heeft tot gevolg dat tijdens de inrichting van de functiescheidingsregels heel kritisch dient te worden gekeken naar de objectwaarden die worden toegekend aan transactiecodes. Hierbij zijn de volgende categorieën te onderscheiden:

het toekennen van weergavewaarden aan autorisatieobjecten (weergave is van minder belang);
het toekennen van te veel waarden aan objecten (01 vs. 02).

Het invoeren van beperkingen in velden

Een fout die soms wordt gemaakt is dat autorisatievelden al worden ingevuld in de tool. Indien de tool wordt gebruikt voor het identificeren van gebruikers die inkooporders kunnen aanmaken, dan wordt in sommige gevallen het belangrijkste documentsoort reeds in de regel in de tool gezet (bijvoorbeeld documentsoort NB). Echter, veel klanten hebben ook een maatwerk-documentsoort gemaakt. Indien beperkingen op bijvoorbeeld documentsoort worden ingevuld, dan bestaat de kans dat andere relevante documentsoorten niet worden bekeken, waardoor niet alle gebruikers die toegang hebben tot de andere documentsoorten zullen worden gerapporteerd (false negatives).

Juiste inrichting biedt vertrouwen

Functiescheidingstools zijn in principe zeer waardevolle hulpmiddelen. Als zo’n tool optimaal is ingericht en geïmplementeerd, werkt die software als een adequate brandmelder. Pas als er echt conflicterende transacties aan een gebruiker worden gekoppeld, gaat het alarm af. Zolang dat niet het geval is, is het gevoel van veiligheid terecht. Mits de tool goed is ingericht!

Dat gevoel van veiligheid heeft positieve gevolgen voor de audits door een accountancyorganisatie. Als deze volledig kan vertrouwen op de juiste implementatie van een functiescheidingstool, kan de auditor erop vertrouwen dat er geen (niet-gemitigeerde) functiescheidingsconflicten voorkomen in de SAP-applicatie. Zoals hierboven uitgebreid betoogd, hebben we in de praktijk meer dan eens ervaren dat organisaties ten onrechte blind varen op hun implementatie. De uitgebreide lijst van mogelijke fouten die we hierboven noemden, is niet fictief maar gebaseerd op onze ervaringen.

Functiescheidingstools kunnen waardevolle hulpmiddelen zijn. Daar zijn ook de auteurs van overtuigd. Bedrijven die gebruik willen maken van functiescheidingstools doen er goed aan de inrichting en/of de controle daarvan over te laten aan specialisten. Het aantal beschikbare specialisten op dat gebied is nog niet bepaald groot. Organisaties (én hun accountants!) die willen blindvaren op die tools, ontkomen er niet aan om de inrichting daarvan aan specialisten voor te leggen. Alleen dan is volledig vertrouwen in de meldingen van die tools terecht!

Beide auteurs hebben veel ervaring met SAP Security. De laatste jaren zijn zij meerdere malen uitgedaagd door organisaties, die met vol vertrouwen onderzoeken op de functiescheidingsregels lieten uitvoeren, aangezien zij zich door erkende firma’s hebben laten begeleiden bij de implementatie. Echter, geen enkele heeft de test goed doorstaan.

Risicomanagement voor commodities – een inleiding

Commoditymarkten zijn volatiel en adequaat risicomanagement is onontbeerlijk. Dit artikel is een inleiding in de wereld van commodities en commodity-risicomanagement. Ook het belang van IT voor commodity-risicomanagement wordt belicht.[De auteurs publiceerden onlangs een boek over commodities: Solid reporting, sustainable results. Risk management and financial reporting for commodities.]

Commoditymarkten

Wat zijn commodities?

Commodities zijn natuurlijke grondstoffen van uiteenlopende aard. Vandaag de dag zijn de energiemarkten in ruwe olie, gas en elektriciteit de grootste commoditymarkten. De handel in commodities vindt echter zijn oorsprong in landbouwproducten zoals graan, rijst, katoen, soja en koffie. Daarnaast zijn ook metalen zoals zilver, goud, aluminium en nikkel commodities. Ten slotte kan ook de handel in emissierechten als een commoditymarkt worden beschouwd.

De aard van commodities loopt dus sterk uiteen. Niettemin is er een aantal wezenlijke overeenkomsten tussen de diverse grondstoffen. Commodities zijn in beginsel onderling uitwisselbaar en van een uniforme kwaliteit. Het zijn bulkproducten die in grote hoeveelheden worden geteeld of gedolven en door grote industriële ondernemingen als grondstoffen worden verwerkt. Daarnaast worden commodities op termijn verhandeld. Met andere woorden, toekomstige aan- en verkooptransacties vinden tegen vooraf overeengekomen prijzen plaats.

De geschiedenis van commoditymarkten

Commoditymarkten vinden hun oorsprong in landbouwproducten en zijn ontstaan om prijsrisico’s af te dekken. Al in Sumerië (vierde millennium voor Christus) werden oogsten tegen een vooraf overeengekomen prijs op termijn verhandeld. Hierdoor wisten boeren zich verzekerd van een inkomen dat hoog genoeg was om het planten en telen van gewassen winstgevend te maken. Bakkers en andere gebruikers wisten eveneens vooraf tegen welke prijs zij hun producten aan de man moesten brengen.

De huidige commoditymarkten zijn ontstaan in de negentiende eeuw in de Verenigde Staten. In plaatsen als New York en Buffalo, maar vooral in Chicago werd in de veertiger jaren van de negentiende eeuw gestart met de georganiseerde handel in granen, bloem en hooi. Door de aanleg van spoorwegen werd Chicago een centraal opslag- en distributiepunt tussen de agrarische productie in het Midden-Westen en de dichtbevolkte Oostkust van de Verenigde Staten. In 1848 werd de CBOT (Chicago Board of Trade) opgericht. Op deze beurs konden boeren en handelaars op termijn tegen vooraf overeengekomen prijzen oogsten verhandelen. Aanvankelijk betrof het bilaterale contracten, waarvan de voorwaarden tussen de aan- en verkoper werden uitonderhandeld. Na verloop van tijd introduceerde de CBOT gestandaardiseerde contracten. Partijen hoefden nu uitsluitend de prijs per contract overeen te komen – de hoeveelheid, kwaliteit, moment van levering en overige voorwaarden waren geüniformeerd. Dit maakte deze futurescontracten eenvoudig verhandelbaar – ook voor speculanten – en droeg bij aan een liquide en transparante prijsvorming.

Het belang van commodities

De wereld van commodities lijkt op het eerste gezicht een nichemarkt. Maar commodities worden overal om ons heen gebruikt. Koper voor kabels en mobiele telefoons, olie als grondstof voor benzine en plastics. Denk ook aan cacao als basisingrediënt voor chocolade. Ook gas en elektriciteit zijn commodities en de prijsontwikkeling ervan heeft gevolgen voor grote delen van het bedrijfsleven en de consument.

Commodities zijn natuurproducten en de prijsvorming ervan is onderhevig aan een reeks van onvoorspelbare factoren zoals het klimaat en de politieke stabiliteit. Daarnaast worden commoditymarkten beïnvloed door macro-economische indices en demografische factoren. Mede als gevolg van de stormachtig groeiende economieën van China en India is de wereldwijde vraag naar commodities gegroeid en zijn de commodityprijzen sterk gestegen. Naast de gestegen marktniveaus is er de laatste jaren ook sprake van een substantieel toegenomen volatiliteit op de commoditymarkten. Speculanten (institutionele beleggers en fondsmanagers) zijn hier mede debet aan.

Commodity-risicomanagement

Commodityposities en -risico’s

Commodityposities zijn forwardposities: ze bevatten toekomstige aan- en verkopen tegen een vastgelegde prijs. Wanneer een onderneming commodities op termijn heeft verkocht en de commoditymarkt gaat omhoog, dan resulteert dit in een (ongerealiseerd) verlies. Immers, de onderneming moet de verkochte goederen tegen een hogere prijs inkopen. Indien een onderneming commodities op termijn heeft ingekocht en de marktprijzen dalen, heeft dit eveneens een ongerealiseerd verlies tot gevolg. Dit doordat de onderneming de goederen voor een lagere prijs kan verkopen dan waarvoor ze werden aangekocht.

De meeste commodityhandelaren of -producenten zullen dergelijke ongedekte posities zoveel mogelijk proberen te vermijden: een sterke fluctuatie in de commodityprijzen kan het einde van de onderneming betekenen. Ondernemingen die op termijn goederen hebben aan- of verkocht, nemen daarom doorgaans een tegengestelde positie op de commoditymarkt in. Ongerealiseerde resultaten op toekomstige aan- en verkopen worden zodoende gecompenseerd door tegenovergestelde resultaten op de termijnmarkt.

Commodityposities kunnen echter meer risico’s bevatten dan alleen ongedekte posities. Deze risico’s zijn niet of hooguit ten dele af te dekken. Dergelijke risico’s worden ook wel impliciete risico’s genoemd. De belangrijkste zijn:

Counterpartyrisico. Het kan gebeuren dat een afnemer of een leverancier zijn toekomstige verplichtingen niet nakomt. Bij een opgaande markt ligt het counterpartyrisico voornamelijk aan de leverancierszijde van een onderneming. In geval van een neergaande markt verschuift dit risico naar de afnemerskant.
Variëteitenrisico (ook wel basisrisico). Op commoditymarkten wordt in een standaardvariëteit gehandeld. Sommige commodities – zoals koffie, cacao en steenkool – kennen specifieke variëteiten met een (deels) autonoom prijsverloop.
Eindproducten- of omzettingsrisico. De prijsontwikkeling van eindproducten, halffabrikaten of bijproducten is niet of ten dele gecorreleerd aan de prijsontwikkeling van de basisgrondstof. Op sommige commoditymarkten kan worden gehandeld in synthetische derivaten, waarmee het omzettingsrisico kan worden afgedekt. Met bijvoorbeeld ‘nafta crack futures’ kan het prijsverschil tussen nafta en ruwe olie worden vastgelegd.
Spread- (of switch-) risico. Commoditymarkten bestaan uit een reeks toekomstige prijzen. Spreadrisico kan zich manifesteren wanneer deze prijzen ten opzichte van elkaar appreciëren of depreciëren.
Arbitragerisico. Bepaalde commodities zijn op meerdere markten verhandelbaar en hebben meerdere beursnoteringen. Tussen de verschillende markten en noteringen is in sommige gevallen arbitrage mogelijk. Dit wanneer de verschillende noteringen ten opzichte van elkaar appreciëren of depreciëren.
Vreemde-valutarisico. Veel commoditytransacties vinden in Amerikaanse dollars of – in mindere mate – in Britse ponden plaats. Contracten in onder meer ruwe olie, goud en koffie luiden vrijwel altijd in dollars.

Risicomanagement en interne controle

De hoge volatiliteit van commoditymarkten enerzijds en het samenstel aan uiteenlopende risicofactoren anderzijds maakt adequaat risicomanagement onontbeerlijk. Faillissementen en schandalen komen regelmatig voor – hoofdzakelijk door tekortkomingen rondom het beheersen van risico’s. Adequaat risicomanagement begint bij de betrokkenheid en het bewustzijn van het management. Het management van een onderneming dient een bewuste keuze te maken welke risico’s de onderneming mag lopen en op welke wijze hiermee omgegaan wordt. Deze ‘risk appetite’ vormt de basis voor alle handelsstrategieën en het positiemanagement van de onderneming.

De belangrijkste procedures omvatten eenduidige rapportagelijnen en positielimieten per risicofactor. Limieten voor prijs- en kredietrisico’s zijn één van de meest fundamentele beheersingsmaatregelen voor de handelsactiviteiten van een organisatie. Zonder expliciete limieten is er geen objectieve maatstaf voor de mate waarin de organisatie aan risico’s is blootgesteld. Handelaren kunnen hierdoor het gevoel krijgen dat corrigerende maatregelen arbitrair of onredelijk zijn.

Het belang van adequate functiescheidingen is in de praktijk helaas al voldoende gedemonstreerd. De ineenstortingen van respectievelijk Barings in 1995 en Sumitomo in 1996 waren hieraan toe te schrijven. Het faillissement van Barings kwam volledig onverwacht en werd door de actie van één enkele werknemer van een klein kantoor in Singapore veroorzaakt: Nick Leeson. Leeson was feitelijk geen handelaar maar een algemeen manager met te veel bevoegdheden. Niemand controleerde hem en hierdoor kon hij ongestoord zijn gang gaan. Het hoofd koper trading van Sumitomo zorgde ervoor dat confirmaties van gedane transacties rechtstreeks naar hem werden gezonden. Hierdoor onttrok hij grote aantallen transacties aan het zicht van de backoffice-afdeling.

Het juist, tijdig en volledig vastleggen van commoditytransacties is een inherent zwak onderdeel van de administratieve organisatie. Met behulp van preventieve maatregelen voorkomen dat een commodityhandelaar de telefoon ophangt en vergeet de deal in het systeem vast te leggen is vrijwel onmogelijk. Een samenstel van repressieve maatregelen kan echter veel fouten en omissies voorkomen. Deze maatregelen omvatten onder meer:

Er dient sprake te zijn van oogtoezicht. Mede daarom zitten handelaren ook doorgaans in een open ruimte. Daarnaast dienen klanten zoveel mogelijk door meer dan één accountmanager te worden bediend.
Er dient procedureel afgedwongen te worden dat alleen via vaste telefoonlijnen transacties worden afgesloten. De telefoongesprekken op deze vaste lijnen worden opgenomen en de tapes worden geruime tijd bewaard.
Het invoeren van nieuwe transacties in het geautomatiseerde systeem moet zoveel mogelijk omgeven zijn met geprogrammeerde controles die invoerfouten voorkomen.
Alle in het handelssysteem ingevoerde transacties komen op een (bij voorkeur geautomatiseerd) overzicht van de gedane transacties. Dit overzicht dient dagelijks door het afdelingshoofd te worden beoordeeld en afgetekend. Van alle gedane transacties worden bevestigingen aan de tegenpartij verzonden.
Medewerkers van de backoffice analyseren de nieuwe transacties op anomalieën en ongebruikelijkheden en communiceren deze met het hoofd van de handelsdesk.
Periodiek wordt alle tegenpartijen om het bevestigen van hun contractposities verzocht.

Mark-to-market

Een onderneming met commodityposities zal de actuele stand van haar openstaande risico’s continu moeten meten en volgen. Eén van de meest geëigende methodieken hiervoor is het op marktwaarde waarderen van de gehele positie (‘mark-to-market’). De belangrijkste voorwaarde hiervoor is dat de onderneming beschikt over betrouwbare en actuele gegevens van de contractposities en de marktwaarde ervan. Zonder betrouwbare marktwaarderingen of benaderingen daarvan is het erg moeilijk om de risicopositie te kwantificeren.

Veel commodities zijn marktgenoteerd. Actuele marktinformatie is uit de krant of van het internet te halen. Niet alle commodities zijn echter aan een beurs genoteerd. Maar ook in beursgenoteerde commodities – zoals elektriciteit – wordt veelvuldig gehandeld door middel van ‘over-the-counter’ (OTC)-contracten. OTC-contracten zijn veelal geprijsd door financiële instellingen of speculanten op basis van een waarderingsmodel. Daarnaast zijn OTC-contracten bilaterale overeenkomsten en afgestemd op de tegenpartij. Hierdoor is dit type contracten in beginsel minder makkelijk verhandelbaar en de marktwaarde derhalve minder liquide.

Niettemin heeft het waarderen van de totale risicopositie op marktwaarde grote voordelen. Fluctuaties van marktprijzen, vreemde valuta’s, en waarderingen van specifieke variëteiten resulteren direct in een aanpassing van de waarde van de risicopositie. Het management houdt zo inzicht in alle ongerealiseerde resultaten die aan de economische risicopositie verbonden zijn. Door middel van Value at Risk (VaR) kunnen de gevolgen van marktfluctuaties voor de waardering van de risicopositie binnen een statistisch betrouwbaarheidsinterval worden berekend. Gezien de hoge volatiliteit op de commoditymarkten moet voorzichtig met historische marktinformatie worden omgegaan. Naast het gebruik van VaR is het daarom raadzaam om scenarioanalyses uit te voeren om de gevoeligheid voor extreme prijsfluctuaties (die buiten de historische koersontwikkeling liggen) te berekenen.

Management accounting

Mark-to-market waardering van de positie geeft een actueel inzicht in het waardeverloop van de economische risicopositie. Waardefluctuaties van toekomstige aan- en verkopen worden dan direct in de resultatenrekening verwerkt. De resultatenrekening geeft zodoende een actueel beeld van de meest recente marktontwikkelingen en handelsactiviteiten. Indien resultaten worden uitgesteld tot het moment van leveren kan het management wel eens zand in de ogen worden gestrooid, omdat het uitsluitend het effect ziet van het fysiek afwikkelen van contracten die maanden (of soms wel jaren) geleden zijn afgesloten.

Indien de gehele economische risicopositie op marktwaarde wordt gewaardeerd, is het wel van belang dat de samenstelling van de brutomarge naar verschillende risicofactoren wordt ontleed. De belangrijkste elementen die de brutomarge van een commodityonderneming bepalen zijn:

Handelsmarge: het prijsverschil tussen in- en verkoopcontracten. Deze marge is niet gevoelig voor veranderingen in de marktprijs van de commodity doordat de prijsveranderingen op de in- en verkoopcontracten elkaar compenseren.
Resultaten op speculatieve (niet-afgedekte) posities: niet-afgedekte ongerealiseerde resultaten die aan schommelingen van de marktwaarde onderhevig zijn.
Resultaten als gevolg van impliciete risico’s: manifestaties van het counterpartyrisico, het variëteitenrisico, het omzettingsrisico, het spreadrisico, het arbitragerisico en het vreemde-valutarisico.

Elk van de genoemde risicofactoren kan de behaalde resultaten van ondernemingen met commodityposities beïnvloeden. Het is daarom niet alleen belangrijk om de verschillende risico’s te beheersen, maar ook om het effect dat ze op de gerapporteerde resultaten hebben gehad te analyseren. Op basis van bovenstaande onderverdeling kan het management de kwaliteit en bestendigheid van de behaalde resultaten in kaart brengen. Ook wordt duidelijk welke handelsstrategieën succesvol zijn gebleken en welke niet.

Externe verslaggeving

Mark-to-market waardering van economische voorraadposities is binnen de meest vooraanstaande regelgevingen voor externe verslaggeving niet altijd mogelijk. Zowel de International Financial Reporting Standards (IFRS) als de Amerikaanse verslaggevingsregels (US GAAP) kennen bepalingen die het mogelijk maken dat contractposities die voor het eigen gebruik van de onderneming zijn bedoeld, niet behoeven te worden gewaardeerd. De binnen de Nederlandse wetgeving recentelijk definitief geworden Richtlijn voor de Jaarverslaggeving 290 inzake financiële instrumenten geeft voor de meeste commodityposities een keuzemogelijkheid tussen waardering tegen marktwaarde of kostprijs. Marktwaardering is uitsluitend verplicht voor ten behoeve van handelsdoeleinden aangehouden contractposities en beursgenoteerde derivaten.

Dit heeft als gevolg dat de resultaten volgens de jaarrekening niet altijd aansluiten op de intern op basis van marktwaarde opgestelde cijfers. Commodityondernemingen die in hun jaarrekening resultaten op contractposities uitstellen tot het moment van fysieke levering, zullen echter intern doorgaans wel degelijk cijfers op marktwaarde opstellen. Deze laatste vormen een meer actuele afspiegeling van de marktsituatie en de behaalde resultaten. Zeker ten aanzien van liquide handelsactiviteiten verdient mark-to-market waardering dan ook de voorkeur. Echter, dat mark-to-market waardering ook door kan slaan was te zien in de jaarrekening van Enron. In veel gevallen werden transacties op illiquide markten tegen marktwaarde in de jaarrekening verantwoord. Dit terwijl er eigenlijk geen liquide marktprijsinformatie beschikbaar was. Even ontransparante als flatteuze marktwaarderingen konden de gerapporteerde resultaten aanzienlijk opfleuren.

Het belang van IT

IT speelt een belangrijke rol bij het effectief uitvoeren van risicomanagement. Door beheersingsmaatregelen zoveel mogelijk te automatiseren is het mogelijk risicomanagement in de dagelijkse processen te verweven. IT is met name van belang voor:

Het tijdig, juist en volledig vastleggen van transacties. De typologie van een handelsdesk kent een inherent zwakke interne controle. Handelaren komen telefonisch transacties overeen, waarbij voorafgaande goedkeuring in de regel niet mogelijk is. Door een samenstel van geprogrammeerde invoercontroles is het mogelijk dat in ieder geval invoerfouten zoveel mogelijk worden beperkt. Dit niet alleen door verplichte velden, maar ook door met menukeuzen te laten werken in plaats van vrije data-invoer. Daarnaast is het mogelijk het handelssysteem te voorzien van ‘sanity checks’ die onlogische of ongebruikelijke invoergegevens afvangen.
Geprogrammeerde limieten. Een geprogrammeerde controle zorgt voor een waarschuwing indien de handelslimieten dreigen te worden overschreden.
Interfaces met marktinformatie. Interfaces die actuele marktnoteringen invoeren in het geautomatiseerde systeem en die de waardering van de risicopositie hiermee aanpassen.
Geautomatiseerde rapportages. Het is van essentieel belang dat het management actueel inzicht heeft in de risicopositie. Dit betekent dat de belangrijkste rapportages, zoals de positierapportage of een overzicht van de openstaande positie per tegenpartij, actueel beschikbaar dienen te zijn. Een ander voorbeeld van een geautomatiseerde rapportage is een dagelijkse lijst met alle in het systeem ingevoerde transacties. Deze is niet alleen van belang voor de backoffice, maar ook voor het hoofd van de handelsafdeling als indicatie of alle transacties wel in het systeem zijn ingevoerd.
Resultaatanalyse. De waarde van de risicopositie wordt door een aantal factoren beïnvloed. Geavanceerde handelssystemen kennen een zodanige granulariteit dat de waardeschommelingen naar oorzaak worden bijgehouden. Hierdoor is het mogelijk gedetailleerd inzicht te krijgen in de samenstelling van de brutomarge.
Statistische en scenarioanalyses. IT kan ondersteuning bieden bij het uitvoeren van VaR-calculaties of scenarioanalyses, waarbij fictieve marktprijzen kunnen worden ingevoerd teneinde het effect van onvoorspelbare marktfluctuaties op de risicopositie in kaart te brengen.

Veel commodityondernemingen maken nog gebruik van verouderde maatwerksystemen die bovenstaande functionele vereisten hooguit ten dele kunnen invullen. Daarnaast is er nauwelijks standaardsoftware beschikbaar die voor de gehele commoditybranche te gebruiken is. Dit is ook logisch omdat elke soort commodities zijn eigen specifieke kenmerken heeft die niet eenvoudig in een standaardoplossing in te bouwen zijn. Op het gebied van IT is dus nog veel winst mogelijk.

Conclusie

Commodities maken deel uit van ons dagelijks leven. Elektriciteit, ruwe olie, koffie en koper: allemaal voorbeelden van commodities waar consumenten en bedrijfsleven direct of indirect mee te maken hebben.

Commoditymarkten zijn volatiel en het is dus van groot belang dat commodityposities adequaat worden beheerst. Bovendien staan commodityposities bloot aan een samenstel van risicofactoren die elkaar kunnen compenseren of versterken. Het volgen, meten en analyseren van de waarde van de economische risicopositie waarborgt niet alleen dat management inzicht behoudt in de openstaande risico’s, maar ook in de samenstelling van het behaalde resultaat.

Effectief risicomanagement vereist dat maatregelen, procedures en functiescheidingen zijn ingebed in de dagelijkse operationele processen. Het betekent ook dat rapportages zoveel mogelijk geautomatiseerd kunnen worden opgesteld. Het volgen van ontwikkelingen in de risicopositie heeft alleen toegevoegde waarde als dit op basis van actuele gegevens gebeurt en eventueel ingrijpen en bijsturen nog mogelijk is. Hierbij kan een geavanceerd geautomatiseerd systeem van grote toegevoegde waarde zijn.

ICT due diligence in de financiële sector

De kranten staan al enkele jaren vol met nieuws omtrent fusies en overnames. Ook in de financiële sector beleeft men spannende tijden rondom overnames. Naast de juridische en financiële kant dient ook de ICT belicht te worden tijdens een fusie of overname. Ten tijde van het schrijven van dit artikel speelde onder meer de overname van ABN AMRO en waren er berichten in het nieuws over de overname van Binck Bank door Alex. Financiële instellingen[In de Wft wordt er gesproken over ‘clearinginstelling, kredietinstelling, verzekeraar of bijkantoor’.] kennen over het algemeen een hoge graad van automatisering, waardoor het belang van ICT due diligence binnen deze sector groot is. Op basis van het due diligence-onderzoek wordt de waarde van de onderneming bepaald. Hierbij is het van belang om ook de waarde van de ICT-omgeving te bepalen. In dit artikel wordt ingegaan op de belangrijkste aandachtspunten voor een ICT due diligence binnen de financiële sector.

Inleiding

Financiële instellingen moeten zich steeds sneller kunnen aanpassen aan de veranderingen in de markt, veranderingen in wet- en regelgeving en veranderingen in technologie. Zo is bijvoorbeeld te zien dat binnen de financiële sector geïnvesteerd wordt in de vervanging en ondersteuning van mainframe-omgevingen voor bijvoorbeeld een .NET-omgeving. SEPA, MiFID, IFRS en Basel II zijn enkele voorbeelden van nieuwe wet- en regelgeving die direct invloed hebben op de ICT-omgeving van financiële instellingen. Meegaan in technologische ontwikkelingen zoals System Oriented Architectures en .NET zijn van belang om de concurrentie voor te kunnen blijven en klanten van nieuwe producten en diensten te kunnen voorzien. Maar meegaan in technologische ontwikkelingen bepaalt ook de waarde van ICT voor de onderneming, de flexibiliteit en robuustheid van de ICT-omgeving.

In dit artikel worden de ICT-aandachtspunten van het due diligence-onderzoek en de rol die de IT-auditor hierin kan spelen, toegelicht.

Belang ICT in due diligence

Financiële instellingen moeten zich er constant op blijven richten, dat (primaire en ondersteunende) processen zo efficiënt mogelijk ingericht zijn en blijven, om zo snel en efficiënt mogelijk transacties te kunnen afhandelen. Naast kosten en opbrengst per transactie is bijvoorbeeld ook het percentage ‘straight through processing’ een maatstaf voor de mate van efficiency in routinematige transactieverwerking. Goede ondersteuning door ICT is dan ook van groot belang voor de continuïteit en efficiency van de bedrijfsprocessen.

De algemene verwachting van de stakeholders bij een fusie of overname is dat synergievoordelen worden gerealiseerd. De verwachte voordelen worden vaak al meegenomen in het bepalen van de (ver)koopprijs, evenals de termijn waarop deze voordelen verzilverd kunnen worden. Op basis van de ICT-aspecten die in het due diligence-rapport naar voren zijn gekomen, kan aan aandeelhouders een realistisch beeld worden geschetst over de te maken kosten en de te behalen synergievoordelen. Derhalve dient al tijdens het due diligence-onderzoek te worden nagedacht over de situatie die na de overname gewenst is. Men kan bijvoorbeeld door het samenvoegen van product- of klantbestanden een completere dekking verkrijgen van de markt. Daar waar systemen komen te vervallen zal dit tot lagere beheerkosten kunnen leiden.

Bij fusie of overname is sprake van verticale of horizontale integratie. Bij een horizontale samenvoeging van bedrijfsprocessen behouden beide organisaties hun primaire processen en dient er naar de koppeling tussen de twee organisaties gekeken te worden. In dit geval kunnen met name ondersteunende activiteiten worden samengevoegd, zoals de helpdesk en het netwerkbeheer. Wanneer verticaal wordt geïntegreerd, kan voordeel worden behaald door delen van de procesketen op elkaar aan te laten sluiten en de onderliggende infrastructuur samen te voegen.

De risico’s van het samenvoegen zijn echter niet altijd op voorhand duidelijk. Het is onduidelijk of beide organisaties de gewenste samenvoeging technisch kunnen realiseren en of ze tot integratie kunnen komen om zo de beoogde kostenvoordelen te behalen. Als het zover komt dat beide organisaties integreren, moet worden vastgesteld welke investeringen dan benodigd zijn.

ICT vormt bij fusies en overnames in de financiële sector dan ook een belangrijk aspect binnen het due diligence-onderzoek. De IT-auditor kan hierbij een belangrijke onafhankelijke rol spelen omdat hij vanuit zijn achtergrond zicht heeft op en kennis heeft van de geautomatiseerde gegevensverwerking. Tevens kan de IT-auditor de aangetroffen systemen, medewerkers en geïmplementeerde (beheer)processen op waarde schatten.

Onderzoeksaanpak

Een due diligence-onderzoek gericht op ICT is binnen banken en verzekeringen belangrijk gezien de cruciale rol van ICT in deze hoog geautomatiseerde omgevingen. Om de rol die de IT-auditor kan spelen in het due diligence-onderzoek toe te lichten, beschrijven wij de onderwerpen die de IT-auditor onderzoekt in een dergelijk onderzoek. Afhankelijk van de omgeving waarin het onderzoek plaatsvindt zal de IT-auditor andere accenten leggen tijdens zijn onderzoek. Bij (pensioen)verzekeraars zal bijvoorbeeld veel aandacht worden besteed aan de robuustheid en actualiteit van de gehanteerde systemen, terwijl bij banken meer aandacht wordt besteed aan integreerbaarheid van systemen en omgevingen.

Aanpak en onderzoeksactiviteiten

Binnen een ICT due diligence-onderzoek verdient een veelheid aan onderwerpen de aandacht (zie figuur 1). Zo dient niet alleen naar de ‘harde’ kant van ICT (informatiesystemen, applicatieportfolio, infrastructuur en tools) gekeken te worden, maar juist ook naar de organisatie daaromheen (beheer, budgetten, beleid en contracten). Met deze onderwerpen tezamen is het mogelijk zich een goed beeld te vormen van de ICT binnen een bedrijf. Om de kopende organisatie van een goed advies te kunnen dienen moet de IT-auditor niet alleen de huidige ICT beoordelen, maar ook een beoordeling van de toekomstvastheid en mogelijkheden van integratie- c.q. ontvlechtingsmogelijkheden in de rapportage meenemen.

C-2008-1-Koets-01

Figuur 1. ICT due diligence-aandachtspunten.

Onderstaand beschrijven wij per onderwerp de belangrijkste aandachtspunten van de IT-auditor.

Organisatie

De opzet van de ICT-organisatie bestaat onder andere uit interne medewerkers, externe medewerkers, functies, handboeken en uitbestede onderdelen. Dit is voor de IT-auditor van belang binnen het due diligence-onderzoek om zich een beeld te vormen van de toegekende taken en toebedeelde verantwoordelijkheden (zowel intern als extern) binnen de ICT-organisatie.

Een overzicht van de aanwezige ICT-locaties (rekencentra, systeemontwikkeling, eventuele stafafdelingen) in alle landen geeft inzicht in de mogelijke complexiteit van het netwerk en communicatiemiddelen. Ook kan met deze informatie worden gekeken of bijvoorbeeld het uitwijkplan hierop juist is aangepast. In de financiële sector is het beschikken over een uitwijkplan en het periodiek uitvoeren van uitwijktests vereist door DNB.

Met behulp van organisatieschema’s van de ICT-afdelingen kan de IT-auditor beoordelen of afdelingen behouden dienen te worden na de overname. Afdelingen die overbodig zijn, kunnen worden afgestoten of kunnen worden samengevoegd met vergelijkbare afdelingen binnen de kopende organisatie. Daarnaast wordt op basis van benchmarkonderzoeken gekeken naar een normale bezetting en verdeling van de personeelsleden in verhouding tot het aantal klanten, het aantal transacties dat de financiële instelling verwerkt en het aantal gebruikers binnen de financiële instelling.

In een bericht over de overname van Binck Bank wordt vermeld dat synergievoordelen al snel een besparing van € 19 miljoen per jaar kunnen opleveren. In dat bericht worden voordelen ‘op het punt van kosten voor het beheer van de systemen en […] van de zelf […] te maken kosten per transactie’ genoemd. Ook wordt de nettoprovisieopbrengst per transactie berekend: € 18,20 bij Alex en € 15,93 bij Binck Bank. Hierbij speelt informatie over het aantal klanten, transacties en winst dus een belangrijke rol.

De IT-auditor brengt in kaart wat het ervarings- en opleidingsniveau van de medewerkers automatisering is. Daarbij speelt de kennis van systemen een belangrijke rol, evenals de mate waarin de systemen worden ingezet. Wanneer de medewerkers slechts van één systeem/platform kennis hebben, zal het moeilijk zijn deze voor andere systemen in de nieuwe organisatie in te zetten. Dit is met name het geval bij banken waar veel legacy-automatisering wordt gebruikt. Bij een overgang naar bijvoorbeeld een .NET-omgeving zal een deel van de medewerkers deze ontwikkeling niet kunnen of willen doormaken. De onderverdeling naar productie, onderhoud en ontwikkeling kan hierbij helpen. De ervaring en het opleidingsniveau van de medewerkers geven verder inzicht in de te verwachten salariskosten. Gecombineerd met organogrammen kan inzicht worden verkregen in overlap met of aanvulling op de medewerkers binnen de kopende organisatie.

Bij extern ingehuurde medewerkers bestaat de kans dat die met de overname niet meegaan, door bijvoorbeeld ontbindende voorwaarden in het contract. Ook is het mogelijk dat zij (gezien hun flexibele arbeidsrelatie) er zelf voor kiezen om niet naar de kopende organisatie te gaan. Deze informatie is van belang om te kunnen inschatten hoeveel medewerkers met welke kennis en ervaring in de organisatie aanwezig zijn na de overname.

De IT-auditor kan zich aan de hand van handboeken, richtlijnen, gebruikte standaarden en ontwikkelmethodieken een goed beeld vormen van de volwassenheid van de ICT-organisatie bij de over te nemen organisatie. (Zie ook ‘Volwassenheid van de ICT-organisatie’ verderop.) Gebrek aan standaarden en documentatie geeft niet alleen aan dat veel ad hoc bedacht wordt, maar heeft ook invloed op beheerprocessen en ontwikkelde applicaties. In de financiële sector is bijvoorbeeld het percentage straight through processing een belangrijk kengetal. Aan de hand van de professionaliteit van de documentatie en richtlijnen kan de IT-auditor zich hier een beeld bij vormen.

Budgetten

Om een beeld te krijgen van de financiële situatie op het moment van onderzoek en de komende jaren, moeten budgetten en werkelijk behaalde financiële resultaten worden bestudeerd. Het is voor de kopende organisatie van belang om te weten welke kosten met de ICT-organisatie gemoeid zijn.

‘De reden dat ABN AMRO overgenomen wilde worden, moet gezocht worden in schaalvoordelen, 65% van de omzet bestaat uit kosten, bij andere banken is dat 55%. ABN AMRO hoopt dat door de overname kosten gereduceerd kunnen worden, de vraag is of de ICT makkelijk kan worden samengevoegd.’

(Bron: zie Literatuur, laatste item.)

Een overzicht met de feitelijke en gebudgetteerde kosten van de afgelopen jaren is hierbij van belang. Verder dient gekeken te worden naar de gebudgetteerde kosten voor de komende jaren en de planning van investeringen en projecten.

Over het algemeen komen kosten en budgetten in de financiële due diligence aan de orde. Echter, niet alleen zijn de geplande kosten van een investering of project van belang, de IT-auditor moet ook een inschatting maken van de achterliggende reden van de investering dan wel het project. Investeringen en projecten kunnen te maken hebben met niet (meer) goed functionerende of verouderde ICT-omgevingen.

Beleid

Informatie over projecten bij de over te nemen organisatie geeft inzicht in enerzijds de mate waarin zij volwassen met haar ICT-organisatie omgaat en anderzijds welke risico’s er zijn en in welke mate deze worden beheerst. Door informatie op te vragen over het informatiebeleid, waarin de stand van zaken en de plannen voor de toekomst worden beschreven, krijgt de IT-auditor een goed beeld van de actuele ontwikkelingen binnen de ICT-organisatie. Een overzicht met een beschrijving van de projecten maakt deel uit van deze ontwikkelingen. Recent uitgevoerde projecten uit de afgelopen jaren geven aan waar zwakke onderdelen in de ICT-organisatie zaten en welke onderdelen nu mogelijk vooroplopen ten opzichte van de marktontwikkelingen. Overzichten van de huidige en komende projecten geven inzicht in de huidige problemen die binnen de ICT-organisatie spelen. Hierbij hoort informatie over aanleiding, doel, omvang, budget, planning, tijdspad, geïdentificeerde risico’s, issue log, aangegane verplichtingen, huidige status, periodieke rapportages, et cetera.

Binnen de financiële sector is het van belang zicht te hebben op de ICT-gerelateerde plannen met betrekking tot grote wijzigingen in wet- en regelgeving die de organisatie treffen. Met name SEPA, Basel II en MiFID hebben de afgelopen jaren druk gelegd op de ICT-organisatie binnen financiële instellingen.

Informatiesystemen en applicatieportfolio

Informatie over informatiesystemen en de applicatieportfolio geeft de IT-auditor inzicht in de wijze waarop primaire en secundaire bedrijfsprocessen worden ondersteund door systemen en medewerkers.

Het is voor de IT-auditor van belang te weten welke bedrijfsprocessen door welke systemen en mensen worden ondersteund. Hierdoor kan worden beoordeeld wat het effect is wanneer enkele bedrijfsprocessen weg zouden vallen in geval van overlap en welke efficiency (kostenbesparing) behaald kan worden. Aanvullend hierop moet de IT-auditor een overzicht ontvangen met de aanwezige systemen. Hierbij is onder meer van belang te beschikken over informatie omtrent de volgende onderwerpen:

globale beschrijving van de opzet (functionaliteiten) van de systemen;
relaties met andere systemen en eventuele interfaces;
de omvang, bijvoorbeeld uitgedrukt in functiepunten of aantal te verwerken transacties;
de ouderdom;
plannen tot vervanging;
het eigenaarschap (eventueel voorzien van een escrow-overeenkomst);
standaardpakket of maatwerk;
‘open source’;
aantal gebruikers;
afhankelijkheid van andere systemen;
onderliggende programmeertaal en databasemanagementsysteem;
eigenaarschap en gerelateerde (onderhouds)contracten;
overzicht beschikbare documentatie;
koppelingen met externe systemen zoals dealingroom, SWIFT, Equens, clearing house en externe dataproviders (bijvoorbeeld Reuters en Bloomberg).

Bovengenoemde punten lijken in sommige gevallen wellicht overbodig. Echter, om een compleet beeld van de kwaliteit van de informatie- en transactieverwerkende systemen te krijgen, is het wel noodzakelijk om hiervan kennis te nemen. Diverse banken hebben bijvoorbeeld (technische) problemen met de applicaties die het bankieren door klanten door middel van het internet faciliteren. Een grote Nederlandse bank heeft onlangs € 40 miljoen uitgetrokken om verstoringen in deze techniek te verhelpen. Dit is een investering die bij een due diligence een belangrijke invloed op de prijs heeft.

De IT-auditor heeft bij zijn werkzaamheden eveneens informatie nodig over de systemen van derden. Dit is van belang bij het splitsen van de over te nemen financiële instelling en het samenvoegen met de kopende organisatie. Indien diensten worden overgenomen, waarbij cliënten toegang tot systemen verschaft wordt, moet de IT-auditor weten welke systemen dat zijn en welke verplichtingen daaruit voortvloeien.

Infrastructuur en tools

Door de technische infrastructuur te beoordelen wordt inzicht verkregen in de mogelijke synergie, wanneer onderdelen van beide organisaties elkaar overlappen. Andersom zou het mogelijk kunnen zijn dat het nodig is extra kosten te maken voor investeringen, wanneer veel vervangingen noodzakelijk zijn.

Essentieel in een due diligence-onderzoek bij een financiële instelling is de technische infrastructuur. Er moet worden gekeken naar mogelijke zwakheden, onder andere met het oog op beveiliging en overlap met de aanwezige infrastructuur bij de kopende organisatie. In geval van oude componenten in de infrastructuur moet de kopende organisatie rekening houden met forse investeringen om deze weer actueel te krijgen. Overlap met de aanwezige infrastructuur kan op termijn financiële voordelen opleveren. Financiële instellingen zijn een belangrijke prooi voor hackers. Derhalve zijn de investeringen die gemoeid zijn met het up-to-date brengen en houden van de beveiliging van de technische infrastructuur aanzienlijk. Binnen dit overzicht moet ook rekening worden gehouden met datacommunicatie met andere vestigingen, die zich mogelijk in het buitenland bevinden. Over de componenten in de infrastructuur moet bijvoorbeeld de volgende informatie beschikbaar zijn:

ouderdom;
eigenaarschap (in eigendom of gehuurd);
geplande vervangingen;
schaalbaarheid bij toenemend gebruik.

Denkbare componenten zijn servers, werkstations, besturingssystemen, databasemanagementsystemen, firewalls, netwerksoftware, protocollen, switches, modems en bekabeling.

Om de IT-auditor een beeld te geven van de volwassenheid van de beheerorganisatie, wordt gekeken naar de tools die worden ingezet voor:

projectmanagement;
beheer van de ontwikkel-, test-, acceptatie- en productieomgeving;
versiebeheer en change management.

Operations

Incidenten en performanceproblemen geven inzicht in de kwaliteit van de systemen binnen de organisatie en in welke mate deze systemen voldoen aan de verwachtingen en eisen van gebruikers. Op het niveau van de operationele uitvoering dient de IT-auditor inzicht te krijgen in de bezetting en de maximale capaciteit van het rekencentrum per platform. De twee organisaties zullen worden samengevoegd, waardoor het volume van de transacties toe zal nemen. De nieuwe ICT-omgeving zal deze hogere volumes volledig en juist moeten kunnen verwerken. Hiervoor is het van belang inzicht te krijgen in het aantal van de transacties van beide organisaties, aangevuld met de planning van de beschikbare capaciteit van netwerk, rekenkracht en opslag. Zodoende kan worden beoordeeld in welke mate de kritische grenzen zijn bereikt. De wijze waarop incident en performance management wordt ingevuld binnen de organisatie, geeft informatie over de volwassenheid van de beheerorganisatie. De service level rapportages hierover geven inzage in de feitelijke incidenten, problemen en prestaties van de systemen en de organisatie.

Beveiliging

Beveiliging is van groot belang bij financiële instellingen. Dit onderdeel speelt dan ook een belangrijke rol in het due diligence-onderzoek. De IT-auditor moet het algemene beveiligingsbeleid van de organisatie en in het bijzonder dat van de ICT-afdeling opvragen.

Per systeem wordt beoordeeld of de systemen die de financiële processen ondersteunen voldoende beveiligd zijn. Ten aanzien van de gesignaleerde risico’s moet een overzicht van de getroffen maatregelen aanwezig zijn, om in te schatten in welke mate de onderliggende bedrijfsprocessen risico lopen. Hierbij kan worden gedacht aan uitwijkprocedures, back-up en recovery.

Aanvullend hierop geven rapportages van (interne en externe) auditors of toezichthouders een goed beeld van mogelijke onvolkomenheden op het gebied van beveiliging.

Contracten

Lopende contractuele verplichtingen verschaffen inzicht in de te verwachten kosten gedurende de komende jaren en op welke termijn deze mogelijk afgekocht zouden kunnen worden.

Contracten geven de IT-auditor inzage in alle diensten en producten die de organisatie afneemt bij derden en de financiële verplichtingen die daarbij horen. Gezien de kennis die een IT-auditor heeft van ICT is het beoordelen van ICT-gerelateerde contracten een waardevolle aanvulling op de juridische due diligence. Diensten die worden afgenomen, hebben veelal betrekking op de volgende onderwerpen:

de inzet van externen;
projecten;
hardware (onder meer onderhoud);
datacommunicatie;
software (onder meer onderhoud en licenties);
toegang/gebruik van systemen door derden;
uitwijkfaciliteiten;
escrow (ten behoeve van programmatuur);
uitbesteding;
mogelijkheden om contracten aan te passen aan de overnemende organisatie.

Het is van belang te kijken welke financiële verplichtingen uit deze contracten voortvloeien en hoelang een contract nog van toepassing is onder geldende voorwaarden (bijvoorbeeld ontvangen korting). De IT-auditor let hierbij op het eigenaarschap van de geleverde diensten, bijvoorbeeld servers, software en externen. Dit is onder andere van belang wanneer de kopende organisatie van plan is de contracten te beëindigen na het samenvoegen van de organisaties. Ook dient er aandacht besteed te worden aan de betrouwbaarheid en de levensvatbaarheid van de leverancier. Mogelijk wordt deze leverancier binnenkort overgenomen, stopt hij met enkele diensten of voldoet hij niet aan de hoge(re) eisen die de kopende organisatie stelt aan zijn diensten.

Wet- en regelgeving

Op diverse plaatsen in wet- en regelgeving wordt over data, gegevensverwerking, bewaren van data en privacy gesproken. Onder andere de Wbp[Wet bescherming persoonsgegevens.], Wft[Besluit van 12 oktober 2006, houdende prudentiële regels voor financiële ondernemingen die werkzaam zijn op de financiële markten (Besluit prudentiële regels Wft).] en MiFID[Markets in Financial Instruments Directive.] stellen eisen op deze terreinen. Voor en na de overname is het al van groot belang hier rekening mee te houden.

Op het gebied van privacy dient bij het samenvoegen van klantgegevens rekening te worden gehouden met de Wbp. ‘Deze wet is van toepassing op de geheel of gedeeltelijk geautomatiseerde verwerking van persoonsgegevens’. Wanneer klantgegevens van eigenaar wisselen (zoals bij een overname het geval is), moet de klant hierover worden geïnformeerd. Vanuit technisch oogpunt is het mogelijk en vaak ook wenselijk gegevens binnen de gehele organisatie samen te voegen en aan elkaar te koppelen. Soms moeten klantgegevens echter gescheiden worden bewaard van andere organisatieonderdelen. Ook dient de overnemende organisatie rekening te houden met het doel waarvoor de persoonsgegevens aanvankelijk zijn verzameld door de overgenomen organisatie. De Wbp schrijft voor dat de verwerking van de gegevens ‘niet onverenigbaar’ mag zijn met het doel waarvoor de persoonsgegevens zijn verzameld. Cliënten moeten tevens worden geïnformeerd over de nieuwe ontwikkelingen bij de kopende organisatie betreffende de gegevensverwerking en hebben het recht bezwaar (‘recht van verzet’) hiertegen te maken. Daarnaast worden er een bewaarplicht en -termijn van de gegevens voorgeschreven in de Wbp.
De Wft stelt met name eisen aan de maatregelen die de organisatie dient te nemen om informatiesystemen goed te kunnen beheren. Zo dient de organisatie te beschikken over een ‘informatiesysteem dat een effectieve beheersing van de bedrijfsprocessen en de risico’s mogelijk maakt’. Daarnaast moet de organisatie maatregelen treffen ten aanzien van de integriteit, beschikbaarheid, functiescheiding en beveiliging van geautomatiseerde gegevensverwerking. Een financiële instelling is verplicht te beschikken over ‘een onafhankelijke compliancefunctie voor het toezicht op de naleving van wettelijke regels en van interne regels’ die door de organisatie zelf zijn opgesteld.
In de MiFID is vastgelegd hoe organisaties dienen om te gaan met de afhandeling van aandelenorders door beleggingsorganisaties, waarbij de transparantie een belangrijk aandachtspunt is. De MiFID heeft als doel ‘de bevordering van een eerlijke, transparante, efficiënte en geïntegreerde financiële markt met behoud van optimale beleggersbescherming’. Er worden expliciete regels gesteld aan bijvoorbeeld de organisatiestructuur, informatiesystemen, rapportages, persoonlijke transacties en uitbesteding.

Volwassenheid van de ICT-organisatie

Een volledig uitgevoerde ICT due diligence biedt voldoende inzicht in de ICT-organisatie om zich een oordeel over de volwassenheid van (delen van) de ICT-organisatie te kunnen vormen. Een veelgebruikt model hiervoor is het Stages of growth-model van Richard L. Nolan. Dit model onderkent de volgende fasen in volwassenheid van een ICT-organisatie:

Het stadium ‘initiation’ wordt gekenmerkt door lage uitgaven aan dataprocessing en beperkte betrokkenheid van gebruikers en management.
Voor het stadium ‘contagion’ is het kenmerkend dat budgetten hoger worden en tegelijkertijd het gebruik van systemen erg snel toeneemt, wat voor een ongecontroleerde omgeving met incidenten zorgt.
Vervolgens wordt bij ‘control’ dataprocessing serieus genomen door het management en er worden controls geformuleerd om systemen te beheersen. Desondanks is communicatie tussen systemen nog foutgevoelig.
In het stadium ‘integration’ krijgt dataprocessing een groter budget toegekend en worden online diensten verlangd door gebruikers. Het management past meer formele werkwijzen toe, zoals projectmanagement, standaardprocedures en controls.
De applicatieportfolio is bij ‘data administration’ geïntegreerd in de organisatie. Dataprocessing wordt nu als dienst aangeboden.
Als laatste kenmerkt het stadium ‘maturity’ zich door de strategische plek die dataprocessing in de organisatie krijgt. De CIO en de CFO hebben een even belangrijke rol toebedeeld gekregen.

Op te vragen informatie

In het voorgaande zijn documenten en informatie genoemd die de IT-auditor nodig heeft bij het opstellen van zijn rapportage. Deze documenten worden tegenwoordig steeds vaker digitaal aangeleverd in een virtual dataroom. De over te nemen organisatie levert eenmalig alle data op die op een centrale, virtuele plek benaderd kunnen worden door financiële, ICT- en juridische experts. Mede omdat de documenten vaak voor diverse experts van interessant zijn (bijvoorbeeld ICT-contracten) werkt dit efficiënter. Deze datarooms en de opgeslagen documenten zijn uitgebreid beveiligd. Uitgifte van gebruikersrechten is over het algemeen in handen van het begeleidend advocatenkantoor.

Uiteraard is het van belang met enkele belangrijke functionarissen, zoals de CIO en de CTO, een gesprek te hebben om zo meer inzicht te krijgen over de ontvangen informatie. Verder kan de IT-auditor tijdens het interview ingaan op nog openstaande vragen.

Op te leveren eindproduct (rapport)

In het rapport worden de feitelijke observaties gescheiden van de bevindingen. Zodoende wordt duidelijk wat enerzijds is geconstateerd en anderzijds welk (mogelijk) effect dat in de ogen van de IT-auditor op de ICT-organisatie heeft.

In figuur 2 is een voorbeeld gegeven van een uitgevoerde analyse van de ontwikkeling van de ICT-kosten ten opzichte van het aantal te verwerken transacties binnen een financiële instelling. Aanvullend hierop kunnen berekeningen worden gemaakt om de kosten per transactie of het percentage ICT-kosten als deel van de totale kosten te verkrijgen.

C-2008-1-Koets-02

Figuur 2. ICT-kosten versus de totale kosten en het aantal transacties.

Onderstaand zijn ter illustratie enkele bevindingen uit IT due diligence-rapportages opgenomen:

Het ICT-personeel op de sleutelposities heeft veel kennis van de ICT-omgeving en werkt gemiddeld 20 à 25 jaar bij bedrijf X. Hierdoor is bedrijf X erg afhankelijk van deze medewerkers, wat mede wordt veroorzaakt door de complexiteit van de ICT-infrastructuur en het gebrek aan documentatie.
Het project voor het vervangen van de infrastructuur kost € 4,8 miljoen. Dit is de komende vier jaar het belangrijkste project. Een groot deel van deze investering, à € 1,26 miljoen, is nodig omdat netwerkcomponenten de komende jaren aan het einde van hun life cycle zijn.
Systeem A is een erg complexe applicatie, die niet volledig gedocumenteerd is. In de nabije toekomst zal een migratie naar een .NET-omgeving overwogen moeten worden.

Aanpak tijdens en belang van de fase na afronding van de fusie

Om tijdig inzicht te krijgen in de mogelijke knelpunten bij integratie dient gedurende het due diligence-onderzoek aandacht te worden besteed aan de mate van integratie die wordt nagestreefd. Indien de organisatie een hoge mate van integratie nastreeft, is een onderzoek naar de mogelijkheden om de ICT-organisatie, -systemen en -projecten te integreren, relevanter dan bij een lagere mate van integratie. Derhalve dient het management van de overnemende organisatie in een vroeg stadium te beslissen over de gewenste en verwachte mate van integratie na de fusie, onder andere in verband met de te behalen mate van efficiency.

Zelfs bij overname van een financiële instelling met vergelijkbare processen kan de integratie een uitdaging worden. Indien verschillende applicaties en infrastructuur worden gebruikt, kan integratie een ingewikkeld traject worden. Op basis van zijn kennis en ervaring kan de IT-auditor ook na de fusie een belangrijke rol in de integratie spelen. Dit kan een beoordelende (quality assurance) rol tijdens het project zijn, maar ook een actieve rol in het projectmanagement of bij uitvoerende werkzaamheden tijdens de integratie. Verder kan met data-analyse de conversie gecontroleerd worden op juistheid en volledigheid.

Samenvatting

In dit artikel hebben wij het belang van een ICT-onderzoek toegelicht en de rol die de IT-auditor binnen een due diligence-onderzoek kan spelen. Tevens is aangegeven welke aandachtspunten de IT-auditor daarbij hanteert.

De ICT due diligence heeft inzicht gegeven in de status (volwassenheid) van de ICT en de ICT-organisatie en in mogelijke knelpunten. Afhankelijk van de integratiedoelstellingen van de organisatie is het van belang al voor de fusie een integratieplan op te stellen zodat na de fusie voortvarend kan worden begonnen met de integratie. In deze fase kan de IT-auditor vanuit zijn ervaring met ICT-organisaties en complexe veranderingstrajecten een belangrijke adviserende of controlerende rol spelen tijdens het integratieproces.

Literatuur

www.dft.nl/goeroes/joopnederstigt/2821313/Slimme_fusie_Binck_Bank_en_Alex.html

wetten.overheid.nl/cgi-bin/sessioned/browsercheck/continuation=19860-002/session=051182725609744/action=javascript-result/javascript=yes

www.dnb.nl/dnb/home/file/fm06-1260c_tcm46-145514.pdf

www.minfin.nl/nl/onderwerpen,financiele_markten/consultaties/mifid#top

Specialist in maart 2007: www.google.com/notebook/public/13528031618643256697/BDQs4SwoQtJ74xNgh

De inwerkingtreding van de Wft: wat verandert voor de IT-auditor?

Met de komst van de Wft is de wetgeving voor de financiële markten doelgerichter, marktgerichter en transparanter geworden. Dit is bereikt door van acht verschillende wetten één wet te maken, voor zoveel mogelijk onderwerpen één algemene regel te maken en in de wet de taken van DNB en AFM te omschrijven en de samenwerking tussen beide toezichthouders te regelen.

Inleiding

De Wet op het financieel toezicht (Wft) is op 1 januari 2007 in werking getreden. Deze wet regelt het toezicht op de financiële sector (met uitzondering van pensioenfondsen) in Nederland. Toezichtwet- en regelgeving heeft een lange geschiedenis. Oorspronkelijk was het toezicht op financiële ondernemingen per sector georganiseerd. Elke sector kende zijn eigen toezichtwet: een wet voor banken, een wet voor verzekeraars, een wet voor beleggingsinstellingen, enzovoort. De bepalingen van de verschillende wetten regelden veelal dezelfde onderwerpen. Voorbeelden zijn een vergunningplicht voor het aanbieden van bepaalde financiële diensten, regels ten aanzien van de bedrijfsvoering en betrouwbaarheidstoetsing van bestuurders. Op de financiële markten vond in toenemende mate een vervlechting plaats van ondernemingen en producten. Binnen de verschillende ondernemingen was steeds meer sprake van sectoroverstijgende activiteiten. Daarom werd in 2002 besloten tot een herziening van het toezicht op de financiële markten van het sectorale model naar een functioneel model. De Wft is het sluitstuk van deze herziening ([AFM06]).

In dit artikel staan de Wft en de impact hiervan op de werkzaamheden van de IT-auditor centraal. In de eerste paragraaf wordt beschreven wat er is veranderd met de komst van de Wft. In de volgende paragraaf wordt dieper ingegaan op raakvlakken van de Wft met de door een IT-auditor gehanteerde toetsingskaders. In de derde paragraaf wordt beschreven wat de gevolgen zijn voor de werkzaamheden van een IT-auditor. Het artikel sluit af met een conclusie.

Wat zijn de gevolgen van de invoering van de Wft?

De Wft vervangt acht toezichtwetten ([DNB08]), waaronder de Wet toezicht kredietwezen 1992 (Wtk), de Wet toezicht beleggingsinstellingen en de Wet financiële dienstverlening. Waar bancaire ondernemingen eerder moesten voldoen aan de Wet toezicht kredietwezen (Wtk) en de richtlijnen voor de uitvoering van toezicht, zoals de Regeling Organisatie en Beheersing (ROB), moeten banken vanaf 1 januari 2007 voldoen aan de wetgeving in de Wft en de daaraan gekoppelde regelgeving.

C-2008-1-Jagt-01

Figuur 1. De weg naar de Wet op het financieel toezicht.

Het doel van de Wft is de regelgeving voor financiële markten doelgerichter en inzichtelijker te maken. Ook zijn de regels waaraan financiële instellingen moeten voldoen eenvoudiger gemaakt ([AFM06]). De Wft bestaat uit zes delen ([AFM06]):

Algemeen;
Markttoegang financiële ondernemingen;
Prudentieel toezicht financiële ondernemingen;
Gedragstoezicht financiële ondernemingen;
Gedragstoezicht financiële markten; en
Toezicht afwikkelsystemen.

Het deel Toezicht afwikkelsystemen zal later aan de wet worden toegevoegd.

De Wft regelt een aantal specifieke vormen van samenwerking tussen de AFM als gedragstoezichthouder en DNB als prudentieel toezichthouder. Hierdoor sluit de Wft – beter dan de oude wetgeving – aan bij de manier waarop er in Nederland toezicht wordt gehouden op financiële markten:

De Nederlandsche Bank (DNB) voert het prudentieel toezicht, dat wil zeggen dat DNB de financiële stabiliteit (solvabiliteit en liquiditeit) en de betrouwbaarheid van financiële ondernemingen controleert.
De Autoriteit Financiële Markten (AFM) voert het gedragstoezicht, wat inhoudt dat de AFM de marktwerking, de toetreding en het vertrouwen daarin controleert en bevordert.

De taakafbakening tussen DNB en AFM voorkomt niet dat beide toezichthouders actief zijn binnen dezelfde financiële sector. Mede om overlap in de uitoefening van de toezichttaken te voorkómen, is in de Wft zoveel mogelijk geregeld dat steeds één toezichthouder de bevoegdheid heeft om een besluit te nemen ([AFM06]).

Voor het gedragstoezicht zijn vooral de delen Algemeen, Markttoegang financiële ondernemingen, Gedragstoezicht financiële ondernemingen en Gedragstoezicht financiële markten relevant. Het deel Algemeen vormt de basis van het wettelijk kader. Hierin zijn de taken en bevoegdheden van de toezichthouders vastgelegd. In het deel Markttoegang financiële ondernemingen worden toegang tot de financiële markten en de vergunningplichtige activiteiten beschreven. Daarnaast zijn de voorwaarden vastgelegd waaronder een buitenlandse financiële onderneming toegang tot de Nederlandse financiële markten kan krijgen. Het deel Gedragstoezicht financiële ondernemingen bevat de regels waaraan financiële ondernemingen moeten voldoen bij het verlenen van hun diensten, zoals de regels voor het informeren van consumenten. Het deel Gedragstoezicht financiële markten bevat de regels waaraan spelers op de financiële markten zich te houden hebben, zoals de regels inzake marktmisbruik, emissies, openbare biedingen, melding van zeggenschap en kapitaalbelang in uitgevende instellingen ([AFM06]). De toezichthouder voor deze onderdelen is de AFM.

Voor prudentieel toezicht is het deel Prudentieel toezicht financiële ondernemingen relevant. Dit deel bevat de regels voor partijen op de financiële markten om aan hun financiële verplichtingen te voldoen. De toezichthouder voor dit deel is DNB.

De bepalingen zoals neergelegd in de Wft worden uitgewerkt in de onderliggende regelgeving. Deze bestaat uit twaalf besluiten of zogenaamde Algemene Maatregelen van Bestuur (AMvB’s) ([MiFi07]). In figuur 2 is de wet- en regelgeving weergegeven en is te zien hoe de lagere regelgeving zich verhoudt tot de diverse delen van de wet.

C-2008-1-Jagt-02

Figuur 2. Indeling Wet op het financieel toezicht.

Waarop en op wie is de Wft van toepassing?

De Wft geldt voor financiële ondernemingen en voor andere partijen die actief zijn op de financiële markten ([AFM06]). Een integrale wetgeving impliceert een integrale controle voor alle financiële instellingen. Toch wil het samenvoegen van alle regels nog niet zeggen dat de hele wet steeds van toepassing is op een specifieke financiële onderneming. Er wordt bijvoorbeeld in de wettekst onderscheid gemaakt tussen de wetgeving voor beleggingen en de wetgeving voor verzekeringen. Het is dus belangrijk om een goed overzicht te krijgen en te houden van de delen van de wetgeving die van toepassing zijn op de onderneming in kwestie. In de wet wordt aangegeven op welke product- en dienstcombinaties de Wft van toepassing is. Per productsoort gelden bovendien specifieke eisen. Een onderneming die verschillende producten aanbiedt moet dus aan verschillende eisen voldoen. De producten waarop de Wft van toepassing is, zijn ([SCFB06]):

verzekeringen leven;
verzekeringen schade;
consumptief krediet;
hypotheken;
sparen en betalen (betaalrekeningen, spaarrekeningen);
elektronisch geld;
beleggen[De Wft is beperkt van toepassing op beleggingen omdat er al een effectenwet is die veel regelt. Onder de Wft valt alleen het uitsluitend adviseren over beleggingen in effecten en het aanbieden van, adviseren over en bemiddelen in beleggingsobjecten.].

De nieuwe wet geldt onder meer voor:

aanbieders van financiële producten:
- verzekeraars,
- banken;
aanbieders van consumentenkrediet;
aanbieders van beleggingsobjecten;
adviseurs met betrekking tot financiële producten;
bemiddelaars inzake financiële producten, inclusief bedrijven die het bemiddelen als nevenactiviteit hebben;
herverzekeringsbemiddelaars;
(onder)gevolmachtigde agenten.

Wat zijn de raakvlakken van de Wft met het controleraamwerk van een IT-auditor?

In deze paragraaf wordt beschreven welke onderdelen uit de Wft raakvlakken hebben met het vakgebied van een IT-auditor. Alvorens de attentiepunten uit de Wft voor de IT-auditor te behandelen, is het eerst van belang het controleraamwerk van de IT-auditor te beschrijven. Figuur 3 geeft een globaal overzicht van de onderwerpen die onderdeel uit kunnen maken van een IT-audit in het kader van de jaarrekeningcontrole waarbij de nadruk ligt op de betrouwbaarheid van de geautomatiseerde gegevensverwerking.

C-2008-1-Jagt-03_kl

Figuur 3. IT-controleraamwerk.

De Wft heeft invloed op verschillende niveaus van het bovenstaande IT-controleraamwerk. In dit artikel komen per niveau, zoals weergegeven in figuur 3, attentiepunten aan de orde. Deze attentiepunten zijn gerelateerd aan de relevante artikelen uit de Wft en de begeleidende Algemene Maatregelen van Bestuur (AMvB).

De Wft vormt in feite de raamwet waarbij AMvB’s voor concrete invulling zorgen. In dit artikel wordt volstaan met een bondige en adequate beschrijving van hetgeen op hoofdlijnen in de wet of AMvB is vastgelegd. Wel wordt een verwijzing gemaakt naar artikelen en hoofdstukken waaruit het attentiepunt afkomstig is.

De Wft schrijft vooral op het niveau van IT-governance een aantal belangrijke regels voor. In tabel 1 is een overzicht gegeven van de artikelen uit de Wft die raakvlakken hebben met het IT-controleraamwerk van de IT-auditor op het hoogste niveau (IT-governance).

C-2008-1-Jagt-tab01_kl

Tabel 1. Richtlijnen Wft voor IT-governance.

Op de onderliggende niveaus (ITGC, application controls en IT dependent manual controls) schrijft de wet minder specifieke regels voor. In de tabellen 2 en 3 is weergegeven welke artikelen uit de Wft raakvlakken hebben met de overige niveaus uit het IT-controleraamwerk.

C-2008-1-Jagt-tab02_kl

Tabel 2. Richtlijnen Wft voor IT General Controls.

C-2008-1-Jagt-tab03_kl

Tabel 3. Richtlijn Wft voor application controls.

Centraal in de Wft staat een beheerste en integere bedrijfsvoering. Deze vormt tevens het vertrekpunt voor de externe toezichthouder om de naleving op de Wft te toetsen. Om dit te kunnen realiseren is risicomanagement belangrijk. Risicomanagement is dan ook verplicht gesteld in de Wft en is het vertrekpunt voor het te voeren beleid van een organisatie. Instellingen bepalen zelf op welke manier zij hun doelstellingen willen halen, zolang de keuzen maar zijn onderbouwd door middel van een risicoanalyse. Informatietechnologie is in dit keuzeproces een belangrijke ondersteunende factor, maar geen doel op zich. De Wft stimuleert zelfregulering.

DNB heeft ten behoeve van het uitoefenen van toezicht een methodologie opgesteld voor het uitvoeren van een risicoanalyse (FIRM). Deze methodologie wordt door DNB gehanteerd bij het uitvoeren van toezicht op de onder toezicht staande financiële instellingen, onder meer voor het opsporen van hoge inherente risico’s en zwakke mitigerende beheersingsmaatregelen. Daarnaast wordt de methodologie door DNB gebruikt om de nadruk te leggen op die ondernemingen, of activiteiten binnen de organisatie, met een hoog risicoprofiel ([DNB]). De risicoanalyse en de daaruit voortvloeiende beoordelingscriteria kunnen ook door de instellingen gebruikt worden ter ondersteuning bij het uitvoeren van de risicoanalyse. Ook de IT-auditor kan gebruikmaken van deze risicoanalyse.

Uitbesteding is tevens een belangrijk onderwerp voor de IT-auditor. Voorheen was voor financiële instellingen de ROB van toepassing, waarin een tweetal paragrafen is opgenomen waaraan de uitbestedende partij moest voldoen. In het verleden is aan de IT-auditor gevraagd om in het kader van de jaarrekeningcontrole een uitspraak te doen in welke mate de instelling de ROB had nageleefd. De onderdelen van de ROB welke van toepassing zijn voor de IT-auditor betreffen ([Beug01]):

paragraaf 2.5 Informatietechnologie (IT);
paragraaf 2.6 Uitbesteding van (delen van) bedrijfsprocessen.

Doordat met de komst van de Wft de ROB is komen te vervallen, hebben veel IT-auditors moeite om de artikelen terug te vinden in de Wft. Tabel 4 geeft een overzicht van de artikelen uit de ROB met de verwijzing naar het corresponderende artikel in de Wft.

C-2008-1-Jagt-tab04_kl

Tabel 4. Referentieoverzicht ROB naar Wft.

Een aantal verschillen tussen de ROB en Wft is opmerkelijk. Door het verdwijnen van het verplichte karakter van de ROB lijkt het alsof een aantal specifieke eisen die door DNB aan uitbesteding werden gesteld, is komen te vervallen. De toezichthouder maakte in de ROB bijvoorbeeld geen verschil tussen interne en externe uitbesteding. De serviceorganisatie hoeft volgens DNB geen derde te zijn. In de definitie van DNB zit besloten dat het uitbesteden van een activiteit waarbij vertrouwelijke (kwetsbare) informatie de entiteit verlaat, door DNB wordt gezien als uitbesteding. Het gaat bij uitbesteding van (deel)processen steeds om risico’s die een materiële invloed kunnen hebben op de financiële prestaties, de financiële positie, continuïteit of reputatie van de instelling. Voor deze beoordeling is een onderscheid tussen bancaire en ondersteunende processen als zodanig niet relevant. Tijdens het consultatieproces van de Wft is echter bewerkstelligd dat de Wft alleen van toepassing is op ‘wezenlijke’ (d.w.z. externe) uitbesteding. Dit zou een ‘verlichting’ ten opzichte van de huidige regelgeving zijn, aangezien de ROB externe en interne uitbesteding gelijkstelt qua eisen ([Bakk06]).

Een tweede belangrijk verschil ten opzichte van de ROB is dat minder nadruk wordt gelegd op een door de instelling op te stellen risicoanalyse bij een uitbesteding. In de Wft is geen specifieke eis opgenomen met betrekking tot het uitvoeren van een risicoanalyse in het kader van uitbesteding. Echter, zoals eerder genoemd, zijn in AMvB 5 wel algemene eisen gesteld aan het risicomanagementproces van de organisatie. Tevens zijn in AMvB 5 (Besluit prudentiële regels financiële ondernemingen; Bpr) en AMvB 8 (Besluit gedragstoezicht financiële ondernemingen; Bgfo) specifieke voorschriften over uitbesteding opgenomen. Als de uitvoering van operationele taken door een derde partij wordt overgenomen, moeten maatregelen worden getroffen die tot doel hebben het operationele risico te beperken. Omdat uitbesteding geen afbreuk mag doen aan de kwaliteit van de interne controle en geen belemmering mag vormen voor de werkzaamheden van toezichthouders (zowel AFM als DNB) blijft de onderneming verantwoordelijk voor alle diensten die worden uitbesteed aan derden. De eisen zullen derhalve moeten worden overgenomen in het uitbestedingscontract (service level agreement), bijvoorbeeld tijdige rapportage aan toezichthouders. De financiële instelling zal de uitvoering van de werkzaamheden moeten monitoren en controleren. Om aan deze eisen uit de Wft te voldoen kan uiteraard nog steeds goed gebruik worden gemaakt van de artikelen uit de ROB. De verwachting hiermee is dus dat er geen grote veranderingen zullen optreden. Indien een onderneming besluit over te gaan op uitbesteding van een activiteit zal dit op een beheerste wijze moeten worden uitgevoerd. Om dit proces te toetsen zal ook de (IT-)auditor nog steeds goed gebruik kunnen maken van de artikelen uit de ROB.

De impact van ‘rule based’-toezicht naar ‘principle based’-toezicht voor de IT-auditor

Huidige financiële ondernemingen en markten zijn te complex om ‘alles’ in detailregels te kunnen vastleggen. De invoering van de Wft brengt hier verandering in, doordat het toezicht in toenemende mate verandert van ‘rule based’-toezicht naar ‘principle based’-sturing. Terwijl ‘rule based’-toezicht tot achter de komma voorschrijft welke maatregelen door een organisatie moeten worden getroffen, laat ‘principle based’-toezicht meer vrijheid aan de organisatie zelf (zelfregulering). Inhoudelijk leidt de invoering van de Wft dus niet tot grote wijzigingen. Centraal staat een integere en beheerste bedrijfsvoering. Een organisatie krijgt hiermee meer vrijheid voor de inrichting van haar administratieve organisatie. Dit heeft tot gevolg dat ‘principle based’-toezicht een minder normatief karakter kent. Echter, vanuit het externe toezicht zal wel worden gekeken wat het meest gangbaar is.

De rol van de IT-auditor bevindt zich dus ook in de overgangsfase van ‘rule based’-audit naar ‘principle based’-audit. Van het signaleren van fouten op basis van strakke toetsingskaders naar het signaleren van risico’s ter voorkoming van fouten. Daarbij doet zich een dilemma voor. Het blijkt lastig om risico’s te inventariseren. Toezicht werkt alleen ‘principle based’ als de inbreng van de auditor als een signaal om van te leren wordt opgevat. Van ‘rule based’ overstappen naar ‘principle based’ houdt ook in, dat je verder kijkt dan alleen de regels. De IT-auditor zal uitdrukkelijk de kwaliteit van de IT-processen en de prestaties waar een organisatie voor staat, in de audit moeten betrekken. Omdat de IT-auditor geen vast toetsingskader meer heeft, zal deze zich dus meer richten op het risicomanagementproces. Op welke manier heeft de organisatie het risicomanagementproces ingericht? Hoe kan de organisatie aantoonbaar maken dat de onderneming haar risico’s beheerst?

De gevolgen van deze veranderingen brengen met zich mee dat IT-auditors niet meer wegkomen met standaardvragenlijsten/normenkaders, maar steeds meer beleidsmatig en procedureel naar vraagstukken zullen kijken. De vraagstukken zijn hiermee steeds complexer geworden, omdat het beoordelen van beleid en procedures (vaak) onvoldoende zekerheid geeft. Het uitvoeren van een ‘principle based’-audit zal ertoe moeten leiden dat op basis van een risicoanalyse de IT-auditor in de diepte onderzoek moet uitvoeren naar (de beheersing van) de IT-processen met een ‘hoog risico’-classificatie en conclusies moet trekken op basis van detailbevindingen over wezenlijke problemen en oplossingen.

Conclusie

De conclusie is dat – hoewel een vrij uitgebreide lijst met voorwaarden is opgesteld – de Wft ten opzichte van de huidige regelgeving geen significante ‘verzwaringen’ en veranderingen met zich meebrengt voor de IT-auditor. Dit is natuurlijk ook niet vreemd gezien het feit dat de financiële instellingen altijd al aan het toezicht van DNB en AFM waren onderworpen door regels die in verschillende wetgevingen waren verankerd. Daarom kan in de praktijk nog steeds goed gebruik worden gemaakt van bijvoorbeeld sound practices van het British Standards Institute (BIS), de Regeling Organisatie en Beheersing en het toetsingskader business continuity planning (BCP).

De Wft is ‘principle based’ en dus niet ‘rule based’. Er staan wel regels in maar het gaat bij instellingen om de handhaving van de principes. Principes als integer handelen, de principes die de instelling verwoord heeft in haar corporate values en de principes die ten grondslag liggen aan een solide bedrijfsvoering. Een dergelijke benadering vraagt zowel van de instelling als van de toezichthouder andersoortige inspanningen. Er zijn immers geen gedetailleerde regels waar het allemaal in staat. Het auditkader wordt gevormd door de wetgeving (Wet op het financieel toezicht) en reeds bewezen sound practices.

Literatuur

[AFM06] Autoriteit Financiële Markten, Belangrijkste wijzigingen gedragstoezicht bij invoering Wft, oktober 2006.

[Bakk06] Drs. R.W.A. Bakkers, De rol van de compliancefunctie in het uitbestedingproces, Tijdschrift voor compliance 2006-5.

[Beug01] B. Beugelaar en M. Ooms-Pieper, Checklist IT aspecten Regeling Organisatie en Beheersing (ROB), Versie 1.0, 28 november 2001.

[DNB01] De Nederlandsche Bank, Richtlijnen Organisatie en Beheersing, www.dnb.nl.

[DNB05] De Nederlandsche Bank, Handboek Financiële Instellingen Risicoanalyse Methode, www.dnb.nl.

[DNB08] De Nederlandsche Bank, Wet op het financieel toezicht, www.dnb.nl/dnb/home/toezicht/nieuwe_toezichtwetgeving/wet_op_het_financieel_toezicht.

[MiFi07] Ministerie van Financiën, Wet op het Financieel Toezicht, AMvB’s en ministeriële regelingen, november 2007.

Besluit bekostiging financieel toezicht (AMvB 1)
Besluit definitiebepalingen (AMvB 2)
Besluit boetes Wft (AMvB 3)
Besluit markttoegang financiële ondernemingen (AMvB 4)
Besluit reikwijdte bepalingen (AMvB 4a)
Besluit prudentiële regels Wft (AMvB 5)
Besluit bijzondere prudentiële maatregelen, beleggerscompensatie en depositogarantie (AMvB 6)
Besluit prudentieel toezicht financiële groepen (AMvB 7)
Besluit Gedragstoezicht financiële ondernemingen (AMvB 8)
Besluit melding zeggenschap en kapitaalbelang in uitgevende instellingen (AMvB 9)
Besluit marktmisbruik Wft (AMvB 10).

[SCFB06] StudieCentrum Financiële Branche, Invoering Wft: grote gevolgen voor financieel adviseurs, 2006 (http://www.scfb.nl/artikel/110.htm).

SOx en ORM: twee verschillende werelden?

In veel banken zijn SOx en Basel II vanuit een eigen raamwerk geïmplementeerd, terwijl beide, elk vanuit een eigen invalshoek, het management verantwoordelijk stellen voor procesbeheersing. Dit artikel geeft aan in hoeverre de activiteiten die benodigd zijn voor SOx en operationeel risicomanagement (ORM) (voortkomend uit de ‘sound practices’ voor ORM van de Bank for International Settlements [BIS03]) elkaar overlappen en reikt mogelijkheden aan om deze activiteiten te integreren.

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.

C-2008-1-Degens-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).

C-2008-1-Degens-t1

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.

C-2008-1-Degens-t2

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.

C-2008-1-Degens-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.

C-2008-1-Degens-t3

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).

C-2008-1-Degens-3

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.

C-2008-1-Degens-4

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.

C-2008-1-Degens-t4

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.

C-2008-1-Degens-t5

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.

C-2008-1-Degens-t6

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).

Literatuur

[BIS03] Bank of International Settlements, Sound practices for the management and supervision of operational risk, February 2003.

[BIS06] Bank of International Settlements, International Convergence of Capital Measurement and Capital Standards, A Revised Framework Comprehensive Version, June 2006.

[Brou03] P.P.M.G.G. Brouwers RE RA en A.M. Meuldijk, SOx404-implementatie in de praktijk: het proces van ‘trust me’ naar ‘prove me’, Compact 2003/3.

[COSO05] COSO, Enterprise Risk Management Framework, 2005, www.erm.coso.org.

[ITGI06] IT Governance Institute, IT Control Objectives for Sarbanes Oxley, September 2006.

[KPMG07] KPMG, SOx Trends and Results of KPMG SOx Survey, 2007.

[PCAO07] PCAOB, Auditing Standard No. 5, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements and related independence rule and conforming amendments, 2007.

[SOx07] Sarbanes-Oxley. Available from URL: http://www.sarbanes-oxley.com.

Verbetermogelijkheden bij de totstandkoming van een SAS 70-rapport

Bij uitbesteding van processen wordt in veel gevallen een SAS 70-rapport vereist van de serviceorganisatie. Het opstellen van het SAS 70-rapport door het management en de certificering door een auditor vergt veelal een forse investering. In dit artikel geven de auteurs op basis van hun praktijkervaring inzicht in de mogelijkheden om deze investering te beperken en de toegevoegde waarde van het SAS 70-rapport te vergroten.

Introductie

Organisaties vragen tegenwoordig bij uitbesteding van hun processen steeds vaker een SAS 70-rapport aan hun serviceorganisatie(s). Het SAS 70-rapport biedt op een gestructureerde wijze inzicht in de mate waarin het uitbestede proces wordt beheerst. De vraag naar SAS 70-rapporten is sterk toegenomen doordat Sarbanes Oxley (SOx)-plichtige organisaties voor al hun materiële uitbestede processen dienen te beschikken over een SAS 70-rapport. Wij zien ook in de praktijk dat organisaties van hun serviceorganisaties een SAS 70-rapport krijgen opgestuurd, zonder dat ze daarom hebben gevraagd. De serviceorganisatie wil naar haar huidige en potentiële klanten, maar vooral naar de markt toe haar professionaliteit uitstralen. En dat terwijl SAS 70 ooit bedoeld was als een ‘in control statement’ voor de auditor.

Inmiddels zijn vele organisaties gewend geraakt aan SAS 70. Voor bijvoorbeeld de pensioenbranche geldt dat in enkele jaren tijd SAS 70 is uitgegroeid van een ‘nice to have’- tot een ‘must have’-instrument. Verwonderlijk is dat niet, aangezien de belangen bij uitbesteding groot zijn en in deze branche de verantwoordelijkheid richting pensioengerechtigden zwaar weegt. Deze ontwikkeling geldt voor meer sectoren en zal in de toekomst steeds breder gaan gelden.

Het uitbrengen van een SAS 70-rapport vergt echter veelal een forse investering. Voor het proces om te komen tot een SAS 70-rapport kan een aantal mogelijkheden worden geïdentificeerd voor het verlagen van deze investering. Dit proces kan worden aangeduid met het rationaliseren van het SAS 70-rapport. Van Dale omschrijft rationalisatie als: ‘(econ.) een zo gunstig mogelijke organisatie van de productie met het doel de prestatie te verhogen en kracht, tijd en geld te besparen’. Met andere woorden: kan er een effectievere set van controls worden vastgesteld, zijn er manieren om beter met resources om te springen, het SAS 70-rapport leesbaarder te maken en de kosten van ‘assurance’ te verlagen?

Ontstaan en achtergrond van SAS 70

Het SAS 70-rapport is ontstaan om een rapportagevorm aan te reiken die organisaties kunnen hanteren om de kwaliteit van de beheersing van hun processen aantoonbaar te maken voor de gebruikersorganisaties. De kracht van het SAS 70-rapport is dat deze wordt getoetst door een auditor en de resultaten daarvan worden opgenomen in het rapport. Hierdoor krijgt het rapport een hoog betrouwbaarheidshalte. Een groot voordeel van een serviceorganisatie om over te gaan tot een SAS 70-rapport is dat zij op die manier de (vele) audits van de auditors van de gebruikersorganisaties kan voorkomen. Weliswaar vergt het verkrijgen van een SAS 70-rapport een veel grotere inspanning dan een audit door een auditor van de gebruikersorganisatie, maar wanneer een dergelijke audit meerdere keren wordt uitgevoerd op initiatief van verschillende gebruikersorganisaties, is het redelijk eenvoudig om het voordeel van een SAS 70-rapport aan te tonen.

In de meeste gevallen komt vaak nog een behoorlijk aantal verbeterpunten aan het licht. Om te voorkomen dat deze verbeterpunten aan de gebruikersorganisatie worden gecommuniceerd en om de kosten van de SAS 70 te beperken voert de serviceorganisatie veelal eerst een kwaliteitsverhogend traject uit. Daarmee is SAS 70 ook een middel geworden om de AO/IC te verbeteren.

Nadat de eerste SAS 70-rapporten het daglicht hadden gezien, ontstonden ook nieuwe vragen bij de uitbestedingstrajecten. Kan een SAS 70-rapport door de serviceorganisatie worden overgelegd en zo nee, per wanneer zou dat wel kunnen? Als een SAS 70-rapport kan worden overgelegd, wat zijn dan de negatieve bevindingen van de auditor? Daarmee kreeg het SAS 70-rapport niet alleen toegevoegde waarde voor de huidige gebruikersorganisaties, maar werd het ook een steeds belangrijker vereiste in uitbestedingstrajecten.

Zoals eerder gesteld vergt een SAS 70-rapport veelal een forse investering. In de navolgende paragraaf zijn verbetermogelijkheden opgenomen om deze investering te verlagen.

Vijftal verbetermogelijkheden

In deze paragraaf komen vijf aspecten aan de orde waarop verbetermogelijkheden zijn te realiseren binnen het SAS 70-proces (zie figuur 1).

C-2008-1-Basten-1

Figuur 1. Vijf gebieden met verbetermogelijkheden.

Voor deze gebieden bestaat een volgordelijkheid. Allereerst het samenstellen van het SAS 70-rapport. Welke processen worden opgenomen (eerste aspect) en welke beheersingsmaatregelen worden geïdentificeerd vanuit deze processen (tweede en derde aspect)? Daarna verschuift de aandacht naar het optimaliseren van het proces door het verbeteren van de wijze waarop het management de beheersingsmaatregelen documenteert en test, en het integreren van het SAS 70-framework met de overige control frameworks (vierde en vijfde aspect).

Betere scoping, beter rapport

Een belangrijke ‘quick win’ is te behalen bij het vaststellen van de reikwijdte (scoping) van het SAS 70-rapport. Deze dient optimaal aan te sluiten op de behoefte van de gebruikersorganisatie(s). Onze ervaring is dat onvoldoende overleg plaatsvindt met de ontvangers van het SAS 70-rapport, waardoor de scope van de SAS 70 doorgaans vrij breed wordt en ook (deel)processen worden meegenomen die minder relevant zijn voor de gebruikersorganisatie. Is de scope te breed, dan ontstaan er hogere interne en externe controlekosten of kan de organisatie worden verweten niet de essentie van haar eigen dienstverlening te onderkennen. Wanneer men besluit om bepaalde processen niet mee te nemen in het SAS 70-onderzoek scheelt dat al veel werk. Een duidelijker afbakening van het SAS 70-onderzoek bevordert ook de leesbaarheid van het SAS 70-rapport. Een deel van het bos is immers weggekapt en de belangrijkste bomen staan nog overeind. Ook dat is winst. Meer overleg met de gebruikersorganisatie over de scoping kan dus een grote kostenbesparing opleveren. Te allen tijde moet natuurlijk worden voorkomen dat essentiële onderdelen van de dienstverlening niet worden afgedekt, want dan bereikt het rapport zijn doel niet. Indien de SAS 70 wordt gevraagd als gevolg van SOx-vereisten dient de scoping direct te worden overgenomen en is er geen ruimte voor onderhandeling. Is dit niet het geval, dan moeten beide partijen om de tafel om de scoping te bespreken.

Uit de ‘SAS 70 Rondetafel voor de financiële sector’, die KPMG heeft georganiseerd in juni 2007, bleek dat de communicatie tussen de serviceorganisaties en de gebruikersorganisaties beperkt is. Dit wordt onderstreept door de uitkomsten van een NIPO-onderzoek in het kader van het KPMG Pensioenenboekje 2007, waaruit bleek dat twintig procent van de ondervraagde pensioenfondsen niet eens weet of de serviceorganisatie beschikt over een SAS 70-rapport. Uit het voornoemde rondetafelgesprek bleek ook dat de gebruikersorganisaties best wat mondiger zouden mogen zijn. Een betere communicatie tussen de gebruikersorganisatie en de serviceorganisatie zal leiden tot verbetermogelijkheden en wederzijds tot een beter begrip van elkaars situatie. Ook zal een gezamenlijk framework de communicatie tussen beide partijen verbeteren en de ontvangende partij meer toegevoegde waarde geven.

Zijn de ‘key controls’ voldoende ‘key’?

De huidige SAS 70-rapporten worden gekenmerkt door een omvangrijke set met controls (beheersingsmaatregelen) per proces. Bij twijfel wordt liever een control extra meegenomen. De SAS 70-praktijk, maar tevens ook de laatste SOx-ontwikkelingen laten zien dat er mogelijkheden zijn om de SAS 70-werkzaamheden efficiënter aan te pakken met dien verstande dat de behaalde assurance uit het ‘control framework’ intact blijft en soms zelfs verbetert. Daartoe is het nodig om de controls te heroverwegen: zijn de gekozen ‘key controls’ wel noodzakelijk voor het verkrijgen van zekerheid omtrent de beheersingsdoelstelling?

Het voordeel van een meer uitgebreide verzameling van controls is de compenserende werking hiervan. Wanneer een control niet effectief blijkt te zijn, kan de controledoelstelling toch worden gehaald omdat de compenserende zekerheid beschikbaar is in de vorm van een aantal ogenschijnlijk ‘overtollige’ controls. De meeste serviceorganisaties die gebruikmaken van een SAS 70-rapport doen dit nu al voor enkele jaren. De in die jaren opgebouwde ervaring biedt dan afdoende zekerheid om afscheid te nemen van de compenserende, overtollige controls die bij de introductie van de SAS 70 wellicht goed van pas zijn gekomen.

Uiteindelijk zullen door het verlagen van het aantal controls de test- en reviewwerkzaamheden afnemen waardoor de investering zal dalen. Kostenreductie wordt dus mogelijk door het doelgerichter opstellen en onderhouden van het control framework. Het verlagen van het aantal controls kan worden bereikt door een gerichte selectie van de controls, maar ook door het verleggen van de aandacht van signaleren (detectieve controls) naar voorkomen (preventieve controls).

Van detectief manueel naar preventief geautomatiseerd

In de meeste SAS 70-frameworks zijn voornamelijk nog zogenaamde detectieve manuele controls benoemd. Onder detectief wordt verstaan dat de fout pas na optreden wordt gedetecteerd, waarna de fout wordt gecorrigeerd. Met manueel wordt bedoeld dat de control een menselijke controlehandeling is. Een voorbeeld hiervan is de controle op het vierogenprincipe aan de hand van de parafen. Beter zou het zijn om ‘preventieve geautomatiseerde’ controls te selecteren. Met preventief wordt bedoeld dat de fout wordt voorkomen. Geautomatiseerd is, voornamelijk bij routinematige processen, beter omdat de controlehandeling altijd, en ook altijd goed (volgens de specificaties) wordt uitgevoerd. Daarbij zijn, op de investering in het ontwikkelen van de geautomatiseerde controls na, geen arbeidskosten meer noodzakelijk. Hierbij kan worden gedacht aan een geprogrammeerd vierogenprincipe waarbij de betrokkenheid van een andere gebruiker (conform de competentietabel) wordt afgedwongen.

Een positief gevolg is dat door het overgaan van detectieve manuele naar preventieve geautomatiseerde controls de foutgevoeligheid van het proces afneemt. In plaats van achteraf vaststellen dat de uitkering geautoriseerd is door de juiste persoon met de juiste paraaf, kan dit proces zodanig worden geautomatiseerd dat alleen de juiste persoon de uitkering kan goedkeuren. Voorkomen is nu eenmaal beter dan genezen. Kortom, hier liggen belangrijke rationalisatiekansen: lagere foutkans en risico en er zijn dus minder controls en testwerkzaamheden nodig. Daarbij hoeft het vaststellen van het bestaan en de werking van geautomatiseerde controls binnen het SAS 70-onderzoek door de auditor maar eenmalig te geschieden. Een belangrijke randvoorwaarde hiervan is wel dat de IT General Controls de continue en betrouwbare werking van de geautomatiseerde controls moeten kunnen waarborgen. Het SAS 70-rapport dient deze General IT Controls ook te beschrijven. Van deze controls dient onverkort het bestaan te worden vastgesteld en de werking te worden getest net als van de andere controls.

Uit het NIPO-onderzoek dat is uitgevoerd in het kader van het KPMG Pensioenenboekje 2007 blijkt dat 47 procent van de ondervraagde serviceorganisaties het SAS 70-traject als een (zeer) belangrijk middel ziet om haar interne beheersing te verbeteren. Hoe lopen de processen exact en wat vindt de auditor er eigenlijk van die over de processen moet oordelen? SAS 70 ‘nieuwe stijl’ maakt zaken expliciet en geeft helder aan waar het proces voor verbetering vatbaar is en kan zelfs leiden tot een mentaliteitsverandering wat betreft de wijze waarop men intern omgaat met risico’s. Dit verbeteringstraject wordt door veel organisaties gezien als een belangrijk bijproduct naast het bieden van zekerheid aan gebruikersorganisaties over de door hen uitbestede processen.

Een andere verbeterslag is het meer gebruikmaken van entity level controls. Binnen een proces zijn vaak talrijke operationele controls en maar enkele of geen entity level controls dan wel procesoverstijgende controls geïdentificeerd. Afhankelijk van de controledoelstelling kunnen enkele procesoverstijgende controls een deel van de zekerheid aanreiken voor het realiseren van een controledoelstelling. Het testen van enkele procesoverstijgende controls is beduidend minder werk dan meerdere operationele controls. Hierbij kan worden gedacht aan een gedetailleerde cijferanalyse naar de resultaten van verschillende bedrijfsonderdelen, producten of processen, waaraan veel zekerheid kan worden ontleend. Natuurlijk gaat dit niet altijd op. Wanneer bijvoorbeeld de operationele controls bestaan uit preventieve geautomatiseerde controls, zou het efficiënter kunnen zijn om deze te testen in plaats van de procesoverstijgende handmatige controls. Kortom, je moet blijven nadenken om deze voordelen te behalen.

Samengevat zijn de voordelen dat het aantal controls wordt verminderd en dat er meer gebruik zal worden gemaakt van geautomatiseerde en procesoverstijgende controls. Figuur 2 illustreert deze verandering van het control framework. Het resultaat is een verbetering van de effectiviteit van de controls als gevolg van het identificeren van de key controls en een sterke verlaging van de kosten als gevolg van het reduceren van de handmatige controls.

C-2008-1-Basten-2

Figuur 2. Verandering van het control framework van huidige naar gewenste situatie.

Embedded testing

Momenteel verricht de auditor veelal de testwerkzaamheden om vast te stellen dat de beschreven controls bestaan en werken. Sommige van deze testwerkzaamheden omvatten hoogstwaarschijnlijk dezelfde procedures die al in de lijn door het management worden uitgevoerd. Wanneer deze managementwerkzaamheden goed worden uitgevoerd en gedocumenteerd, kan de auditor hier goed gebruik van maken. Door gebruik te maken van management testing kunnen bijvoorbeeld wekelijkse monitoring controls van het management worden getest in plaats van dagelijkse operationele controls. Het testen van een wekelijkse control vergt minder inspanning dan een dagelijkse control, waardoor een directe besparing wordt gerealiseerd.

Het testen door het lijnmanagement heeft meer voordelen. De controles worden uitgevoerd door mensen met vakinhoudelijke kennis. Tevens verbetert de betrokkenheid van de lijn en voorkomt men daarmee in een vroeg stadium mogelijke (dure) ‘deficiencies’ (tekortkomingen). ‘Deficiencies’ vergen veel tijd van de organisatie en de auditor, wanneer deze pas tijdens de controle worden geconstateerd.

Het kan ook nog beter, en wel door de controle door het lijnmanagement niet als een control te identificeren en te testen, maar als testwerk van de control waarop door de auditor kan worden gesteund. Als de auditor wil steunen op de werkzaamheden uitgevoerd door anderen moeten er twee vragen worden beantwoord: is de uitvoerende voldoende deskundig en is hij onafhankelijk. Deskundigheid bestaat enerzijds uit vakinhoudelijke auditkennis en anderzijds uit kennis van de regelgeving (bijvoorbeeld de noodzakelijke wijze van testen en documenteren). De onafhankelijkheid van het testwerk lijkt niet te zijn gewaarborgd wanneer dat is uitgevoerd door het directe lijnmanagement. Zij kan worden verhoogd door het introduceren van een onafhankelijke quality-assurancerol van de Interne Accountants Dienst of de afdeling Kwaliteitscontrole. Als de deskundigheid en onafhankelijkheid zijn gewaarborgd, kan de auditor maximaal gebruikmaken van de uitgevoerde testwerkzaamheden.

SAS 70 als onderdeel van een integraal framework

Een SAS 70-traject moet niet als een op zichzelf staand project worden beschouwd binnen een organisatie. Het is van groot belang dat andere control frameworks worden verenigd met het SAS 70-framework. Indien dit niet gebeurt, zullen dezelfde controls meermalen worden getoetst, omdat ze deel uitmaken van meerdere control frameworks. Door het integreren van frameworks worden de te testen beheersingsmaatregelen als het ware ontdubbeld. Andere control frameworks zijn bijvoorbeeld die voor SOx, Tabaksblat of de verzameling controls van belang voor de jaarrekeningcontrole. Het verenigen van de frameworks is zeker geen gemakkelijke opgave, doordat deze control frameworks niet een-op-een aan elkaar te relateren zijn door een verschil van reikwijdte en diepgang. Figuur 3 geeft op hoofdlijnen aan hoe de overlap tussen de diverse control frameworks inzichtelijk kan worden gemaakt en moet vervolgens nader worden uitgewerkt. Deze uitwerking is naar onze ervaring veelal een tijdsintensieve actie, maar wel noodzakelijk om ten volle de voordelen van het rationaliseren van het control framework te benutten.

C-2008-1-Basten-3

Figuur 3. Grid ter bepaling van de overlap tussen de diverse control frameworks.

Conclusie

Er zijn goede besparingsmogelijkheden binnen het relatief dure project voor het opstellen en het realiseren van een SAS 70-rapport. Het beperken van het aantal controls, door een betere scoping van de processen en de selectie van de juiste controls binnen de processen, reduceert de kosten voor het opstellen, maar vooral de kosten voor de interne en externe toetsing. Focus op key controls, ofwel: méér controls wil niet zeggen meer ‘in control’. Verder kan door de verschuiving van de inspanning van de auditor naar het management of een onafhankelijke quality-assurancerol een grote besparing worden gerealiseerd (door het vervangen van de dure externe door goedkopere interne uren), en dat geldt ook voor het ontdubbelen van dezelfde controls binnen de verschillende control frameworks. Buiten het doel van het verlagen van de kosten van het SAS 70-rapport kan deze aanpak ten slotte ook worden gebruikt als middel om de gehele beheersing van de organisatie te verbeteren.

Vragen die een serviceorganisatie zich moet stellen zijn: is de scope van het rapport in lijn met de wensen van de klant? Steunt de organisatie intern wel op de juiste controls en kan dit niet beter of efficiënter door focus op key controls? Kan er niet meer gebruik worden gemaakt van preventieve geautomatiseerde controles en testwerkzaamheden van het management zelf? In deze aspecten ligt de uitdaging voor organisaties. Een duidelijke visie op scope, controls en testen van controls kan de procesinrichting verbeteren, het aantal te testen controls verminderen en tegelijkertijd de kwaliteit van het SAS 70-rapport verhogen.

Literatuur

J.C. Boer RE RA en drs. H.P. van der Horst, De Praktijkgids SAS 70, KPMG Uitgave, 2007.

Drs. S.R. van Bellen RA, drs. J.P. Hoogstra RE en drs. M.A. Francken RE RA CISA, Nut en noodzaak van SAS 70, Compact 2007/3.

Drs. J.H.L. Groosman RE, Verschillen en overeenkomsten tussen SOx en SAS 70, Compact 2007/3.

Revenue assurance voor digitale content

Opbrengsten uit online digitale content laten zich moeilijk meten door het ontbreken van een fysiek product. De hoeveelheid verkochte goederen wordt geregistreerd door partijen aan het eind van de keten. Op basis van deze registratie en de contractafspraken worden alle stakeholders betaald. Hier wringt de schoen, want hoe kan je achterhalen dat je niet wordt benadeeld als je afhankelijk bent van een registratie van derden en een product dat zich niet eenvoudig laat tellen?

Van toonbank tot webadres

De platenzaak van vroeger heeft een digitaal broertje. De plank achter de toonbank met alle singles uit de top-40 en de toonbank met de koptelefoons voor het beluisteren van muziek maken langzaam plaats voor een webadres waarop met een dubbelklik een muziekfragment kan worden beluisterd alvorens tot de aanschaf over te gaan. Dit allemaal vanuit de luie stoel. Het fysieke geld is vervangen door creditcardgegevens. Het fysieke product, dat al een verandering heeft doorgemaakt van vinyl naar tape en uiteindelijk cd’s, wordt nu gerepresenteerd door een verzameling enen en nullen die via datatransmissie naar de klant wordt verzonden.

De artiest doet nog steeds zijn werk en maakt muziek. De platenmaatschappij zorgt voor het gereedmaken van het product van de artiest voor de verschillende verkoopkanalen. Via het opnemen in de studio, productie van de cd en distributie naar de winkels komt de cd uiteindelijk terecht bij de consument. Doordat de content in het verleden altijd aan een fysiek product was gekoppeld, was de platenmaatschappij in staat precies na te gaan hoeveel was verkocht. Daardoor wist deze direct zijn winst en ook wat afgedragen moest worden aan de artiest.

Vanaf het moment dat platenzaken (ook) webwinkels werden die het product als nullen en enen verkochten en ze voor de distributie afhankelijk werden van het internet in plaats van het wegennet, is het moeilijker geworden voor de platenmaatschappij om dezelfde controle te houden over hoe vaak bepaalde producten zijn verkocht. De afhankelijkheid van een derdepartijenregistratie is toegenomen en hiermee ook de toenemende behoefte aan meer zekerheid over deze registratie.

Dit artikel beschrijft de nieuwe keten van online digitale content en manieren om zonder een fysieke goederenstroom toch zekerheid te krijgen over de volledigheid van opbrengsten. Daarnaast wordt in de kadertekst van dit artikel een alternatieve aanpak geïntroduceerd voor revenue assurance die is gebaseerd op een economische benadering.

Wat is online digitale content?

Onder online digitale content wordt verstaan: het aanbieden van digitale informatie via het internet, mobiele netwerken of andersoortige netwerken, zonder dat hierbij een link is te leggen met een fysieke goederenstroom. Een online-internetwinkel waar de fysieke producten worden geleverd, valt dan ook buiten de reikwijdte van dit artikel ([Wott06]).

Kenmerken van de digitale goederenstroom

Door het ontbreken van het fysieke product is controle op volledigheid van de verantwoorde omzet niet meer op de traditionele wijze uit te voeren. Digitale content raakt nooit uitverkocht. Waar het voorheen mogelijk was door de voorraad te tellen na te gaan wat de verkoop was, moet nu worden vertrouwd op de rapportages van derden. En hoe betrouwbaar zijn die rapportages? Hoe complexer het proces, hoe lastiger het is om daar zekerheid over te krijgen. Het proces ís complex doordat de verkoop van online digitale content een relatief nieuwe business is met veel kleine partijen die ieder een deel van het proces verzorgen. Daarnaast ontbreekt het nog aan standaarden. Bij online digitale content moet je kunnen steunen op een teller die ergens in een applicatie is ingebouwd en getrouw rapporteert over de verkopen.

Daarnaast is de onduidelijkheid toegenomen over het succesvol afleveren van een product. Terwijl hier voorheen geen twijfel over bestond, blijkt dit nu toch een punt van discussie te zijn bij de klant maar ook bij de verschillende ketenpartijen.

Zoals uit voorgaande tekst blijkt zijn traditionele methoden om de volledigheid van de omzet te beheersen niet toepasbaar in de wereld van de digitale content. Uit eerder onderzoek van KPMG ([KPMG06]) is naar voren gekomen dat dit resulteert in een verwachting dat bedrijven omzet mislopen vanwege een onbetrouwbare registratie bij ketenpartners. Uit ditzelfde onderzoek, waarbij een enquête is gehouden in de markt, komen de volgende vier oorzaken naar voren voor het mislopen van omzet:

De technologie en/of de systemen functioneren niet adequaat. Dit leidt er bijvoorbeeld toe dat de transactie (de levering van content) niet tot stand komt, terwijl er wel een aanvraag is gedaan door de consument.
De technische systemen die de aanvraag, levering en betaling regelen sluiten onvoldoende aan op de backoffice en/of de administratieve systemen.
De administratieve systemen bieden onvoldoende functionaliteit. Ze zijn niet in staat de contractueel overeengekomen informatie – de basis voor de afdracht van inkomsten – op te leveren. Daardoor is veel arbeidsintensief en foutgevoelig handwerk nodig.
De contractuele bepalingen sluiten niet aan op de praktijk. Dit leidt onder meer tot interpretatieverschillen.

Aanpak voor aanvullende zekerheid

Als traditionele methoden om de volledigheid van de omzet te beheersen niet toepasbaar zijn in de wereld van de digitale content, maar er toch veel redenen zijn om meer zekerheid te willen krijgen, dan zien wij de revenue assurance-aanpak als mogelijkheid om de volledigheid van de omzet vast te stellen.

Onder revenue assurance wordt het ontwerpen, implementeren en onderhouden van een systeem van beheersingsmaatregelen verstaan om de organisatie voldoende vertrouwen in de betrouwbaarheid van de order-to-cashprocessen te geven teneinde meer winst te genereren ([Wott06]).

Revenue assurance voor online digitale content bestaat uit een drietal analyses:

contractanalyse;
procesanalyse;
gegevensanalyse.

Contractanalyse

De verschillende ketenpartners hebben met elkaar contracten afgesloten. In deze contracten ligt formeel vastgelegd op welke wijze met de content wordt omgegaan. Dit gaat bijvoorbeeld over het plaatsen en het bewerken van de content. Maar ook over verantwoordelijkheden over de content en de betaling per verkochte content. In een dergelijk contract dient ook een auditclausule te zijn opgenomen. Dit geeft een ketenpartner de mogelijkheid om voor een bepaalde periode na te gaan of de gerapporteerde verkoop overeenkomt met de werkelijk verkochte content. Zoals uit KPMG-onderzoek ([KPMG06]) blijkt zijn niet alle contracten voorzien van een dergelijke clausule. In de gevallen dat de clausule wel is opgenomen, is deze lang niet altijd toereikend om een degelijk onderzoek uit te voeren om eventuele misstanden te kunnen identificeren. Mocht een clausule zijn opgenomen en toereikend zijn, dan blijkt uit het onderzoek van KPMG ([KPMG06]) dat slechts enkele partijen gebruikmaken van het verworven recht om de ketenpartner te bezoeken en een audit uit te (laten) voeren.

In de contractanalyse wordt nagegaan welke bepalingen zijn opgenomen en tot welke audits de ketenpartner gerechtigd is. Tevens wordt beoordeeld aan welke bepalingen het ontbreekt en dit zal leiden tot een advies voor aanpassingen in het contract waarbij de ketenpartner juridisch de mogelijkheid krijgt onderzoek te doen naar de registratie bij de ketenpartner.

Procesanalyse

Zoals eerder in dit artikel al werd vermeld, is de wereld van de online digitale content complex. Er zijn doorgaans veel (kleine) partijen betrokken en deze partijen zijn niet altijd in een volwassen stadium. Dit wordt mede veroorzaakt door het ontbreken van standaarden. De vraag naar online digitale content neemt snel toe waardoor hoge eisen worden gesteld aan de ‘time to market’, en dat heeft tot gevolg dat de interne beheersing van de processen achterblijft. Met een procesanalyse wordt inzichtelijk gemaakt hoe het proces precies loopt, welke partijen zijn betrokken met welke verantwoordelijkheden. Ook de onderliggende IT-infrastructuur wordt hier in kaart gebracht. Zodra het proces en de onderliggende systemen zijn vastgelegd (over de ketenpartners heen), volgt de risicoanalyse. In deze fase wordt per processtap nagegaan welke risico’s kunnen optreden. Voor ieder geïdentificeerd risico worden de kans en de impact bepaald, alsmede de verwachte beheersingsmaatregelen. Om na te gaan hoe reëel het geïdentificeerde risico is, wordt beoordeeld in hoeverre de verwachte beheersingsmaatregelen aanwezig zijn. Hoewel de procesanalyse niet direct leidt tot het inventariseren en kwantificeren van gemiste omzet, draagt zij wel bij aan een beter begrip van de kwetsbaarheden binnen de processen en is zij daarom onontbeerlijk voor het definiëren van de gegevensanalyse. Figuur 1 geeft een (zeer vereenvoudigd) voorbeeld van een procesanalyse van een ‘full track’ download. Zowel het proces als mogelijke risico’s worden hierin weergegeven.

C-2007-4-Onland-1

Figuur 1. Voorbeeld van een procesanalyse van een full track download. [Klik hier voor grotere afbeelding]

Gegevensanalyse

In een gegevensanalyse worden bestanden met elkaar vergeleken. In het geval van online digitale content worden doorgaans de verschillende registraties van ketenpartners met elkaar vergeleken op juistheid en volledigheid. Hiermee is omzetverlies te kwantificeren. Hiervoor is het noodzakelijk dat de uit te voeren audit en de periode waarover de audit plaatsvindt, vastgelegd is in het contract om überhaupt toegang te krijgen tot de registraties van de ketenpartners. Daarnaast is de procesanalyse noodzakelijk om zeker te zijn dat de juiste registraties met elkaar worden vergeleken en om vast te stellen welke registratie wordt gezien als de SOLL-registratie. Doordat binnen de procesanalyse ook de risicogebieden worden geanalyseerd, is het goed mogelijk eventuele verschillen te verklaren. Voor de gegevensanalyse worden speciale tools ingezet zoals IDEA, omdat de bestanden zo groot kunnen zijn dat de capaciteit van bijvoorbeeld Excel niet meer toereikend is. Uit onze ervaring is gebleken dat uitgaan van de registratie van de telecomoperator die ook wordt gebruikt voor het factureren van de consument, een goede SOLL-registratie is. Figuur 2 laat zien welke gegevensanalyse wenselijk is op basis van het proces en de risico’s die zijn weergegeven in figuur 1.

C-2007-4-Onland-2

Figuur 2. Voorbeeld van een gegevensanalysevoorstel voor het vergelijken van twee registraties.

Samenvatting

De aanpak zoals die hiervoor is beschreven, zal leiden tot duidelijkheid over de mogelijkheden van het bestaande contract maar zal ook inzichtelijk maken welke zaken onvoldoende formeel zijn vastgelegd.

De procesanalyse geeft duidelijkheid over de veelal complexe processen binnen de keten en aan welke risico’s de ketenpartners worden blootgesteld. Dit geeft de mogelijkheid tot proces- en controloptimalisatie. Tot slot maakt de gegevensanalyse inzichtelijk welke verschillen in de registraties zijn ontstaan en kunnen deze worden gekwantificeerd naar misgelopen omzet.

Risicobeheersing vanuit een economisch perspectief

In dit kader wordt een alternatief gepresenteerd waarbij risicobeheersing wordt benaderd vanuit een economische invalshoek. Yasser Alaoui Mdaghri beschrijft in zijn scriptie een e3-value methodologie van Gordijn en Akkermans om risico’s binnen complexe ketens in industrieën zoals de contentindustrie beter te beheersen ([Gord03]). Deze invalshoek kenmerkt zich door de expliciete representatie over wie zaken doet met wie, wat wordt aangeboden, wat in ruil daarvoor wordt teruggevraagd en wat de kernbusinessactiviteiten zijn van een partij. De distributie van digitale muziek tussen de contentaggregator en het record label resulteert in een waardemodel dat hieronder grafisch wordt weergegeven.

C-2007-4-Onland-k1

Dit voorbeeld laat zien dat een contentaggregator hosting van content als een belangrijke businessactiviteit heeft en de contenteigenaar productie van content als kernbusinessactiviteit heeft. De contentaggregator krijgt het recht om content van de platenmaatschappij commercieel te exploiteren. In ruil voor het verworven recht zou de contentaggregator een bepaald bedrag moeten betalen aan de content owner voor elk verkocht item.

In de situatie die hier in kaart is gebracht, is er altijd sprake van economische reciprociteit. In werkelijkheid is er ruimte voor een partij in een keten om fraude te plegen, fouten te maken of opportunistisch gedrag te vertonen door een gebrek aan of beperkte controlemechanismen bij de businesspartner aan wie de kernbusinessactiviteit is uitbesteed.

De controlemechanismen die onder andere verder uitgewerkt zijn in dit artikel, kunnen worden toegepast om een controleprobleem met betrekking tot waarde-uitwisselingen tussen twee partijen in een constellatie te identificeren, te kwantificeren en te voorkomen.

In de beschreven economische uitwisseling is de platenmaatschappij kwetsbaar voor het niet ontvangen van het geld voor gedistribueerde digitale content waar zij recht op heeft. Na de identificatie van de risiconemer en het risico dat deze loopt, worden de bronnen van de geïdentificeerde risico’s in kaart gebracht. Hieronder volgt een lijst van mogelijke risicobronnen voor de content owner:

C-2007-4-Onland-k2

De tabel hieronder geeft aan welke controlemechanismen toegepast kunnen worden om de bron van het risico te verminderen of helemaal te elimineren. Deze controlemechanismen zijn afkomstig van de e3-control methodologie van Vera Kartseva ([Kart07]).

C-2007-4-Onland-k3

Het model hieronder laat zien hoe het oorspronkelijke waardemodel verandert na het implementeren van de bovengenoemde controlmechanismen.

C-2007-4-Onland-k4

Klik hier voor grotere afbeelding

De belangrijkste verandering is dat de content owner de garantie kan claimen wanneer de contentaggregator zijn financiële verplichtingen niet nakomt. Ook wordt gebruikgemaakt van een derde partij die gespecialiseerd is in het uitvoeren van IT-audits. Deze audits kunnen de vorm van zowel een gegevensanalyse als een SAS 70-verklaring aannemen. In de vorm van een SAS 70 dienen de resultaten van de audit als een verklaring dat de informatie met betrekking tot verkoop van de content juist en volledig is en er ten aanzien van de ondersteunende IT-systemen en -processen in gebruik bij de contentaggregator de juiste beheersingsmaatregelen zijn genomen.

Deze aanpak is gebruikt in de gehele contentconstellatie om de huidige controlemechanismen te toetsen op effectiviteit. De gehanteerde aanpak biedt de volgende voordelen:

De aanpak geeft een duidelijk beeld van de economische structuur van een complexe keten.
De aanpak helpt om risico’s en de bronnen daarvan op een snelle en efficiënte manier te identificeren.

De besproken controlemaatregelen hebben als doel de kwetsbaarheid van bedrijven te verminderen vanuit een economisch perspectief. Deze controlemaatregelen zijn verder beschreven in dit artikel en kunnen worden ingezet als methoden om de juistheid en volledigheid van omzet te garanderen.

Conclusie

In een keten waarin een fysiek product ontbreekt en waarin in hoge mate moet worden gesteund op de registratie van derden, is de volledigheid van de omzet te bepalen door een analyse uit te voeren op de verschillende registraties die binnen het proces, maar over de ketenpartner heen, worden bijgehouden. Om een goede gegevensanalyse uit te voeren die ook kan leiden tot naheffing van gederfde omzet, is het noodzakelijk dat enerzijds de contractbeperkingen bekend zijn en anderzijds het proces en de risico’s duidelijk zijn. Nevenproducten hierbij zijn aanbevelingen voor het optimaliseren van het contract en een vastlegging van het proces, de spelers en de onderliggende systemen.

Literatuur

[Gord03] J. Gordijn en J.M. Akkermans, Value based requirements engineering: Exploring innovative e-commerce idea, Requirements Engineering Journal, Vol. 8(2):114-134, 2003.

[Kart07] V. Kartseva, J. Gordijn en Y.H. Tan, Value-based design of Networked Enterprises using e3-control Patterns, 2007.

[KPMG06] Revenue Assurance for Online digital content, adequate controls for optimal performance, 2006.

[Wott06] Mw. mr. J. Wotte, drs. ir. H.J. van Bon RE RA en prof. dr. E.E.O. Roos Lindgreen RE, Revenue assurance voor online-informatie.

Older posts

Newer posts