The REA Approach to Database Modeling:Implications for Internal Control and Auditing

Implications for Internal Control and Auditing

As with any system, the internal control and audit of ERP systems are issues. Key concerns are examined next within the SAS 78/COSO framework.

TRANSACTION AUTHORIZATION

A key benefit of an ERP system is its tightly integrated architecture of modules. This structure, however, also poses potential problems for transaction authorization. For example, the bill of materials drives many manufacturing systems. If the procedures for the creation of the bill of materials are not configured correctly, every component that uses the bill of materials could be affected. Controls need to be built into the system to validate transactions before other modules accept and act upon them. Because of ERPs’ real-time orientation, they are more dependent on programmed controls than on human intervention, as was the case with legacy systems. The challenge for auditors in verifying transaction authorization is to gain a detailed knowledge of the ERP system configuration as well as a thorough understanding of the business processes and the flow of information between system components.

SEGREGATION OF DUTIES

Operational decisions in ERP-based organizations are pushed down to a point as close as possible to the source of the event. Manual processes that normally require segregation of duties are, therefore, often eliminated in an ERP environment. For example, shop supervisors may order inventories from suppliers and receiving dock personnel may post inventory receipts to the inventory records in real time. Further- more, ERP forces together many different business functions, such as order entry, billing, and accounts payable, under a single integrated system. Organizations using ERP systems must establish new security, audit, and control tools to ensure duties are properly segregated. An important aspect of such control is the assignment of roles, which is discussed in a later section.

SUPERVISION

An often-cited pitfall of an ERP implementation is that management does not fully understand its impact on business. Too often, after the ERP is up and running, only the implementation team understands how it works. Because their traditional responsibilities will be changed, supervisors need to acquire an extensive technical and operational understanding of the new system. Typically, when an organization implements an ERP, many decision-making responsibilities are pushed down to the shop floor level. The employee-empowered philosophy of ERP should not eliminate supervision as an internal control. Instead, it should provide substantial efficiency benefits. Supervisors should have more time to manage the shop floor and, through improved monitoring capability, increase their span of control.

ACCOUNTING RECORDS

ERP systems have the ability to streamline the entire financial reporting process. In fact, many organizations can and do close their books daily. OLTP data can be manipulated quickly to produce ledger entries, accounts receivable and payable summaries, and financial consolidation for both internal and external users. Traditional batch controls and audit trails are no longer needed in many cases. This risk is mitigated by improved data entry accuracy through the use of default values, cross-checking, and specified user views of data.

In spite of ERP technology, some risk to accounting record accuracy may still exist. Because of the close interfaces with customers and suppliers, some organizations run the risk that corrupted or inaccurate data may be passed from these external sources and corrupt the ERP accounting database. Additionally, many organizations need to import data from legacy systems into their ERP systems. These data may be laden with problems such as duplicate records, inaccurate values, or incomplete fields. Consequently, strict data cleansing is an important control. Special scrubber programs are used as interfaces between the ERP and the exporting systems to reduce these risks and ensure that the most accurate and current data are being received.

INDEPENDENT VERIFICATION

Because ERP systems employ OLTP, traditional, independent verification controls such as reconciling batch control numbers (see Chapter 17) serve little purpose. Similarly, process reengineering to improve efficiency also changes the nature of independent verification. For example, the traditional three-way match of the purchase order, receiving report, and invoice and the subsequent writing of a check may be completely automated in an ERP environment. The focus of independent verification thus needs to be redirected from the individual transaction level to one that views overall performance. ERP systems come with canned controls and can be configured to produce performance reports that should be used as assessment tools. Internal auditors also play an important role in this environment and need to acquire a thorough technical background and comprehensive understanding of the ERP system. Ongoing independent verification efforts can be conducted only by a team well versed in ERP technology.

ACCESS CONTROLS

Access security is one of the most critical control issues in an ERP environment. The goal of ERP access control is to maintain data confidentiality, integrity, and availability. Security weaknesses can result in transaction errors, irregularities, data corruption, and financial statement misrepresentations. Also, uncontrolled access exposes organizations to cyber criminals who steal and subsequently sell critical data to competitors. Security administrators therefore need to control access to the tasks and operations that process or otherwise manipulate sensitive corporate data.

Traditional Access Control Models

Traditionally, the owner of system resources (data, functions and processes) grants access privileges individually to users based on the individual’s trust level and job description. Access control is typically achieved via an access control list (or access token) within the user’s application.6 The access control list specifies the user-ID, the resources available to the user, and the level of permission granted such as read only, edit, or create. Although this model allows for the assignment of specific access privileges to indi- viduals, it is quite inflexible. The sheer volume and variety of access privilege needs in modern ERP environments present a significant administrative burden. Any access-granting model must efficiently keep up with new hires, changes to existing privileges brought about by promotions and individuals transfer- ring from one department to another, and personnel terminations. To meet these demands, modern ERP systems employ role-based access control (RBAC), which is discussed next.

Role-Based Access Control (RBAC)

A role is a formal technique for grouping together users according to the system resources they need to perform their assigned tasks. For example, a system administrator could create a Sales Role for sales department personnel that permits access only to the ERP’s Sales Module and certain documents such as customer orders, sales orders, and customer records. When an employee joins the sales department (whether a new hire or transfer from another department), he or she will be assigned to the Sales Role and, through it, can access its prespecified resources. Figure 11-8 illustrates the difference between RBAC and the traditional access control list approach.

Notice from the figure how this technique assigns access permissions to the role an individual plays in the organization rather than directly to the individual. Therefore, more than one individual can be assigned to a role and a predefined set of access permissions. Also, an individual may be assigned more than one role, but can log into the system only under one role at a time. Thus, RBAC conveniently handles many-to-many relationships between users and permissions and facilitates dealing efficiently with vast numbers of employees.

ERPs come with predefined roles with preassigned permissions. Administrators and line managers may also create new roles, modify existing roles, and delete roles that are no longer needed. Creating a role involves defining the following role attributes:

1. A stated set of business responsibilities to be performed within the role

2. The technical competencies needed to perform the role

3. The specific transactions (permissions) required to carry out the stated responsibilities

Figure 11-9 presents a SAP role definition for an accounts payable role in a hypothetical organization. The individual(s) assigned this role is governed in his or her access to specific SAP program modules (in this case AP) and to specific activities within the module by the transaction code list in the SAP Security Considerations section of the role definition.

INTERNAL CONTROL ISSUES RELATED TO ERP ROLES

Although RBAC is an excellent mechanism for efficiently managing access control, the process of creating, modifying, and deleting roles is an internal control issue of concern for management and auditors alike. The following points highlight the key concerns:

1. The creation of unnecessary roles

2. The rule of least access should apply to permission assignments

3. Monitor role creation and permission-granting activities

The Creation of Unnecessary Roles

The fundamental objective of RBAC is to provide access in accordance with an organization’s needs, which derive from defined tasks rather than an individual’s wants. Managers in ERP environments, how- ever, have significant discretion in creating new roles for individuals. This may be done for employees who need access to resources for special and/or one-time projects. Such access-granting authority needs to be tempered with judgment to prevent the number of roles from multiplying to the point of becoming dysfunctional and thus creating a control risk. Indeed, an oft-cited problem in ERP environments is that roles tend to proliferate to a point at which their numbers actually exceed the number of employees in the organization. Policies need to be in place to prevent the creation of unnecessary new roles and to ensure that temporary role assignments are deleted when the reason for them terminates.

The Rule of Least Access

Access privileges (permissions) should be granted on a need-to-know basis only. Nevertheless, ERP users tend to accumulate unneeded permissions over time. This is often due to two problems:

1. Managers fail to exercise adequate care in assigning permissions as part of their role-granting authority. Because managers are not always experts in internal controls they may not recognize when excessive permissions are awarded to an individual.

2. Managers tend to be better at issuing privileges than removing them. As a result, an individual may retain unneeded access privileges from a previous job assignment that creates a segregation of duties violation when combined with a newly assigned role.

Policies should be in place to require managers to apply due diligence in assigning permissions to roles to avoid the granting of excessive access. They should assign privileges based on the task at hand and be aware of the individuals’ existing permissions that may pose a control violation

Monitor Role Creation and Permission-Granting Activities

Effective RBAC management demands procedures that that monitor role creation and permission grant- ing to ensure compliance with internal control objectives. Verifying role compliance across all applications and users in an ERP environment, however, poses a highly complex and technical problem that does not lend itself to manual techniques. Role-based governance systems are available for this purpose. These systems allow managers to:

• View the current and historical inventory of roles, permissions granted, and the individuals assigned to roles.

• Identify unnecessary or inappropriate access entitlements and segregation-of-duties violations

• Verify that changes to roles and entitlements have been successfully implemented.

These systems can continually monitor for risk and issue alerts when violations are detected so that remedial action can be taken. In addition, role-based governance can maintain an audit trail to provide a record of violations and evidence of compliance.

CONTINGENCY PLANNING

The implementation of an ERP creates an environment with a single point of failure, which places the organization at risk from equipment failure, sabotage, or natural disaster. To control this risk an organization needs an effective contingency plan that can be invoked quickly in the event of a disaster. Two general approaches are outlined next, but a more extensive discussion is presented in Chapter 15 within the broader context of IT governance.

Centralized organizations with highly integrated business units may need a single global ERP system that is accessed via the Internet or private lines from around the world to consolidate data from subsidiary systems. A server failure under this model could leave the entire organization unable to process transactions. To control against this, two linked servers may be connected in redundant backup mode. All production processing is done on one server. If it fails, processing is automatically transferred to the other server. Organizations that want more security and resilience may arrange servers in a cluster of three or more that dynamically share the workload. Processing can be redistributed if one or more of the servers in the cluster fail.

Companies whose organizational units are autonomous and do not share common customers, suppliers, or product lines often choose to install regional servers. This approach permits independent processing and spreads the risk associated with server failure. For example, BP Amoco implemented SAP’s R/3 into 17 separate business groups.