During 2004 and 2005 a large number of companies began the process of documenting and testing significant Internal Controls over Financial Reporting to satisfy the requirements of the Sarbanes Oxley (SOX) act.

The initial SOX attestations showed that there was a real risk of companies documenting their business process and testing in unnecessary detail. This created a paper trail that employed a lot of people but delivered little or no value to compliance. It was at this time that the onerous costs of SOX compliance became a subject of some notoriety and lessened focus on the benefits of SOX compliance.

Changes in legislation, further guidance from the SEC and the PCAOB and new interpretations particularly from the 'Big Four' accounting firms have enabled companies who need compliance to SOX requirements to move the determination of scope to a risk based approach from the initial 'bottom up' one and decrease the resources required by SOX compliance.

Also, the emergence of experienced practitioners in the art of achieving a SOX compliant documentation set has lead to project management that further lessens the implementation payload.

This paper will define the risk based approach to SOX compliance and document some of the 'lessons learnt' and the techniques used to scope the IT part of a SOX project efficiently.

Using a risk based approach for SOX enables management to focus on high risk areas, which could result in a significant misstatement in their financial reporting. High risk areas are defined as accounts, disclosures and related processes where, if internal controls were not present or failed to operate, then there is the potential of a large numerical misstatement due to error, omission or fraud, (if management is unsure whether a misstatement could occur in an account balance or component of account, or disclosure it should treat the area as high risk rather than low risk). The size of the numerical statement is usually agreed with the company's external auditors.

To optimise the set of controls to be tested a de-minimis limit can be set that can be applied to a unique process. A value is established to indicate that the balance or flow-through of the account is such that the risk of a significant misstatement may be regarded as inconsequential. This value, known as the 'de-minimis limit' can again, be set in consultation with the external auditors.

It is not necessary to document these processes and controls for SOX 404 purposes.

The 'de-minimis limit' forms part of the risk assessment process but is not a stand alone or additional measure, i.e. the de-minimis limit can only be applied where the risk of a significant misstatement in the financial account at reporting entity level is considered as low.

It is critical to the success of documentation programs to ensure that documentation is produced to the right level of detail. It is only necessary to show the critical path of data. Enough information is needed about the flow of transactions to identify where material misstatements due to error or fraud could occur, how transactions are initiated, authorized, recorded, processed and reported and where IT supports the flow of transactions.

Specific IT considerations are to show IT processes and controls that support the flow of transactions. This means documenting application/ERP functionality (i.e. computations and processes performed by applications), use of system-generated information, and significant input and output sources.

Core Transaction processing

Calculations and maintenance of invoices, inventory and other basic records

Transmission software

Sales, purchasing, banking activity

Data Warehouse

Significant when data is extracted and used in non-routine and estimation processes

Financial reporting

General ledger, other subsidiary ledger systems whose main purpose is to report financial information per chart of accounts

For SOX404, business applications are considered to be 'in-scope' where there is a reliance on these applications in terms of the integrity and completeness of the financial statement. In general, ERP type applications tend to be in-scope for SOX404 as they are normally used to consolidate, validate and/or process financial data.

Based on an initial risk assessment as above, and the documentation that describes the key controls from a business process point of view, it is relatively straightforward to draw up an initial list of applications that support these business processes.

The next step is to confirm whether the applications on this initial list are in-scope from a SOX point of view, and companies must perform an analysis to determine whether any of the key financial statement controls exist within or place reliance upon the specific business applications listed.

For example

A company may have in place a number of feeder applications that provide key inputs to their ERP or financial management applications. If the ERP application places full reliance on the data supplied by these feeder applications, sufficient IT controls would be required to be present within the individual feeder applications. However, if the ERP application performs suitable validation of the data being supplied by the feeder systems there may be an opportunity to consider the feeder applications out of scope for SOX404.

Each company must perform a risk assessment of their application portfolio and answer the “What could go wrong?” question and, if something were to go wrong obtain a clear understanding of the implication.

However, due to the complexity and distributed nature of many IT systems it is often unclear where the key financial controls reside in terms of the application landscape.

If you ask the manager of a storage and distribution warehouse if their local on-site systems are critical from a financial reporting point of view, the answer is likely to be ‘yes’. This view would be based upon a common-sense assessment of the function of these systems and that the large-scale management of distribution has a material impact upon the financial statement of a business. However, the manager of the storage and distribution warehouse may not be aware or have a full appreciation of the interfaces that the local warehouse systems have with a centrally managed ERP system such as SAP. In addition, it is unlikely that staff within a local site is fully aware of the control reconciliations performed by SAP and that there are no key controls for SOX404 within the warehouse systems because of a combination of business process and application controls that mean the key controls exist within a centrally located SAP.

Scoping Workshop

For each of the applications identified within this initial list the system owner or business owner should determine answers to the following key questions:

'What does this application do?'

'To which other applications do this application interface?

'What is the purpose of those interfaces?'

'What data is exchanged via these interfaces?'

'What does the interfacing-system do with the data received from this application?'

What Could Go Wrong?

The next step would be to perform a step-by-step 'What could go wrong?' analysis:

For example

If an individual was able to gain unauthorised access to the warehouse management application what could they do?

Risk

Individuals may be able to make unauthorised changes to material information to disguise a loss or theft.

Implication

The warehouse system sends incorrect or incomplete volume information to SAP which results in financial misstatement.

Control

Each time a warehouse receives a delivery the delivery is checked and signed as received and this information is verified against the order number and is input to SAP by an operator.

SAP performs a reconciliation of the orders dispatched and invoice values received from the warehouse. These figures are compared with the current stock levels.

Discrepancies are identified during this reconciliation. The system owner is responsible for managing an investigation to determine the cause of any discrepancies and ensure that appropriate action is taken.

In this example there is a risk that a depot may report inaccurate information. However, a combination of business process and SAP controls ensure that any imbalance is identified, thus mitigating the risk of financial misstatement. Therefore, the key financial statement controls exist within SAP and it would be possible to exclude the warehouse systems from the SOX scope.

These can be defined as those controls, which are provided via IT systems or processes but that are not Business Process specific, for example Change Management. These controls can be considered as forming the foundation upon which applications and business processes operate. The PCAOB requires that a recognised control framework be used to identify and assess the controls within the general IT environment. The de facto standard used for SOX is CobIT, (Controls Objectives for Information and related Technologies) because of its widespread acceptance and use within the IT audit and risk management community.

CobIT provides a comprehensive framework covering, the following aspects of the IT environment:

• Planning and Organisation;
• Acquisition and Implementation;
• Delivery and Support, and
• Monitoring.

These four areas are then subdivided into 34 processes and 318 Control Objectives.

However, CobIT is not SOX specific and is designed to provide 'Good Practice' guidance that covers the management of IT processes. Therefore, in most organisations, a subset of the control objectives detailed within CobIT will be identified as having a material impact on the integrity and completeness of the financial statement and thus be documented as key controls from a SOX point of view.

Using CobIT as a basis and through discussion with IT stakeholders and External audit, a register of those IT General controls which are relevant in the context of a particular companies SOX404 attestation can be produced. In addition, this register can be divided into those IT General controls which the Business areas are responsible for managing and those, which are managed by the IT function.

Business General IT Controls (BGIT controls)
These are defined as the IT general controls which cover the management of business applications, for example, SAP change control and configuration.

IT infrastructure General IT Controls (IGIT controls)
These are defined as those IT general controls covering the operation of the infrastructure which supports the business systems, for example, application hosting and the network.

The documentation of BGIT controls for a company which has in place companywide procedures and standards will require considerably less effort than a company whose processes vary, for example, on a divisional basis. It may be possible to use a single documentation set to describe a particular process with division specific documentation set’s containing the same information for the particular process in question. If differences between divisions occur only in certain areas, they could be documented in a single set of guidelines, but with different actual controls to reflect the differences. 

Therefore, it is suggested that the first step to be taken by in scoping this work is to determine which BGIT sub-processes can be documented at a company level and which must be documented for each division or operating unit. In addition, in the absence of companywide processes an evaluation should be performed to determine whether the processes are similar and can they be made the same.

The degree of detail required should be such that the presence or omission of key controls detailed within the BGIT documentation can be identified and clearly identify the main control points and where potential weaknesses could facilitate misstatement or fraud (for SOX404 consider the risk implications on a financial basis), and identify the boundaries between the manual activities and the IT system activities - this is because the control testing methods will differ and IT tends to support the majority of processes.

There is also a considerable documentation and testing overhead associated with the IT General Controls (predominantly program change and logical access) that support in-scope applications. If the IT Processes (and associated controls) differ significantly from application to application it is necessary to document general controls for each application.

If the IT processes are common it is possible to produce one set of general controls for all the applications supported by these common processes. Where sub-processes differ from application to application, even though the majority are common, it is only necessary to document the differences on separate sets of documentation and reference the common set for all the shared sub-processes.

For each application identified as being in-scope companies should identify the relevant IT processes that apply to these applications (e.g. Change Control, Access Control).

To reduce the level of documentation teams should then consider whether these IT processes are the same in all key respects. That is, companies need to confirm that the key controls within these IT processes are the same.

An essential part of this approach is that the justification for clustering applications in this way is comprehensively documented so that the decision made is clear both to management and the external auditors, who will both need to approve the method adopted as part of their respective sign-off on the SOX attestation.

The first stage of this method is a high-level walk through of the process using an IT Process Description Checklist to allow application owners to understand the key elements of the process.

This should provide enough information to be able to determine which IT processes and controls are common.

The findings and conclusions of this review should be documented and require application owners to walk-through elements of the IT Processes supporting each application to accurately identify any similarities that might exist.

If it becomes clear that the IT processes supporting a number of applications are indeed very different from each other and that the conclusion of this process is that multiple sets of documentation are required it can be advisable to consider implementing a common process across different applications rather than spending the time documenting and testing many different IT processes. 

Example 1 - Global Data Centre

A company runs one application (SAP) hosted as one instance at a Shared Service Centre where it is subject to common IT Processes.

One set of documentation regarding general IT controls is required.

Example 2 - Divisional Cluster

A company uses a common application (SAP) although more than one instance of SAP exists and other applications are in scope for the purposes of SOX.

The same IT process exists across the SAP instances so one set of documentation will suffice for SAP.

If common IT processes exist for the other in-scope applications, one set of documentation can be completed for all those that share a similar process.

Example 3  Unique operating company

A company has 18 applications in scope.  The number of sets' of documentation will be dictated by the number of common IT processes. Often, there are different processes for complex ERP applications than there are for less complex applications and it may be that a common IT process exists for ERP applications and a different, common IT process exists for the other applications.

In this example, more than 1 set of documentation might need completing, one for each common process.

However, if the processes and related documentation could be brought in line for both groups it might be feasible to run one common process, and complete only one set. 

Scoping Applications Embedded Controls (AECs) is determining if a control documented within the controls documentation is an Application Embedded Control - 'in scope'. This involves reviewing the business process control documentation and assessing if a control that is documented within those registers is an automated control, i.e. either a system configuration (system), a control performed by an individual based on a system produced report (IT dependent control), or restricted access to transactions by users or groups of users.

If there are no AECs that management rely upon for the purposes of SOX 404 in a process for a specific application, then, there is no need to have that specific application in scope for SOX.

Example

Inventory data may be held within a separate Inventory System from the ERP system used to report financial results. Data held within the inventory system is used as the starting point for reporting the inventory numbers, however for the purposes of financial reporting, the inventory accounts are subject to manual inventory inspections and counts and manual inventory valuations. Therefore management does not place reliance on any of the controls within the inventory system for the purposes of control over financial reporting, i.e. there are no application embedded controls within the inventory system that management rely upon for the purposes of SOX 404. As a result there is no requirement to document and test the IT general controls over the inventory system.

Alternatively, management may review and approve a 'large or unusual movement report' produced by the separate inventory system, or an automated calculation routine to calculate value within separate inventory systems for the purposes of financial reporting. In this case, both the inventory report (IT dependent Control), and the calculation routine (System Control) should be documented within the business process control documentation.  Therefore these AECs will need to be tested, and documentation prepared for the separate inventory system.

Once the IT general controls have been tested, and found to be effective then it should not be necessary to test the application embedded controls each year provided that all changes to the application embedded controls are subject to the change management controls within the IT general controls. If the IT general controls are not deemed to be effective over change management, then AECs will need to be re-tested if they have been changed before the IT general controls have been remediated.

The use of end-user applications of computing can range from simple tracking of invoices/issues, to analysis for management information and decision making to complex valuations, computations and aggregation of balances into the financial statements.  Errors in the latter category (aggregation/computation of balances into financial statements) can significantly impact data accuracy.  Supporting the use and operation of end-user repositories and the lack of sufficient compensating controls in, for example, the manual reconciliation of spreadsheet output to input, increases the risk of an error impacting the financial processes. An error in a simple, but business critical spreadsheet, database or data warehouse report can result in material misstatements.

This interpretation can result in large numbers of 'in-scope' EUC applications.  Applications including MS Word, PowerPoint, as well as the ubiquitous spreadsheet are considered relevant.

When this occurs a company should 'step back' and consider whether the EUC application is a documented 'SOX control' or merely a carrier of information.

Scope Questions

In order to help determine whether the EUC application is in or out of scope ask the following broad question 'what is the risk if the integrity of this EUC application is compromised, what could go wrong?'

 For example:

Q.        'If the spreadsheet (or other EUC application) were to be manipulated, i.e. the data that it contains were to be changed, added to, deleted, would the reviewer, in this case the Head of Department, be able to detect the change?'

A.        If the answer is 'No' - the Head of Department places full reliance on the spreadsheet then the spreadsheet would be 'in scope'.

            If the answer is 'Yes' - the Head of Department would detect a change and does not place reliance on the accuracy of the sheet because they undertake other reviews (controls) then the spreadsheet would not be 'in scope'. 

ERP reports

Some ERP systems provide reports in spreadsheet format.  Whether these are in scope depends on their use after the report has been run.  If the spreadsheet data is further manipulated and the data used as an input to another system then it is likely to be considered in scope.  However if the spreadsheet is purely a mechanism for viewing the report then it is likely to be outside of scope for end user applications (but in scope for application or embedded controls).

Usage Policy for end user computing

Complex end user applications can be migrated into an applications environment where controls are generally more stringent and effectively executed; i.e. is there an application that could provide similar functionality to the EUC application?  The following factors apply:

• Need for multiple access to data/ sharing of data;
• There is a large amount of data (many different versions, case, projects);
• Flexible and expandable consolidation of data;
•  EUC application is sensitive to deliberate corruption, and
• Long life cycle is required.

SOX compliance can be expensive, manpower/resource hungry and IT is involved at almost every stage. The first attestations confirmed this and lead to an outcry about the cost and value of the exercise. However, changes in the approach defined by the SEC and in the guidance from the auditors have allowed an increased focus on a risk based approach to what business processes need to be documented, tested and monitored for SOX compliance. This, in conjunction with improved project management, has lead to more effective scoping especially within the IT part relating to application software, automated risk controls, general IT controls and end user computing.

This means lower project costs and allows a renewed attention on the benefits of SOX and compliance for participating companies.

• Process control that improves performance with reliability and continuity
• Transparent risk control of financial and operational integrity
• Assured Balance Sheets and Profit & Loss statements
• The increase of shareholders value and therefore competitive advantage