Audits

Types of Audits and Reviews:

1.

Financial Audits or Reviews

2.

Operational Audits

3.

Department Reviews

4.

Information Systems Audits

5.

Integrated Audits

6.

Investigative Audits or Reviews

7.

Follow-up Audits

Financial Audit
A historically oriented, independent evaluation performed for the purpose of attesting to the fairness, accuracy, and reliability of
financial data. CSULB's external auditors, KPMG, perform this type of review. CSULB's Director of Financial Reporting
coordinates the work of these auditors on our campus.

Operational Audit
A future-oriented, systematic, and independent evaluation of organizational activities. Financial data may be used, but the
primary sources of evidence are the operational policies and achievements related to organizational objectives. Internal
controls and efficiencies may be evaluated during this type of review.

Department Review
A current period analysis of administrative functions, to evaluate the adequacy of controls, safeguarding of assets, efficient use
of resources, compliance with related laws, regulations and University policy and integrity of financial information.

Information Systems (IS) Audit

There are three basic kinds of IS Audits that may be performed:
1.

General Controls Review

A review of the controls which govern the development, operation, maintenance, and security of application systems in a
particular environment. This type of audit might involve reviewing a data center, an operating system, a security software
tool, or processes and procedures (such as the procedure for controlling production program changes), etc.

2.

Application Controls Review

A review of controls for a specific application system. This would involve an examination of the controls over the input,
processing, and output of system data. Data communications issues, program and data security, system change control,
and data quality issues are also considered.

3.

System Development Review

A review of the development of a new application system. This involves an evaluation of the development process as well
as the product. Consideration is also given to the general controls over a new application, particularly if a new operating
environment or technical platform will be used.

Integrated Audit

This is a combination of an operational audit, department review, and IS audit application controls review. This type of review
allows for a very comprehensive examination of a functional operation within the University.

Investigative Audit
This is an audit that takes place as a result of a report of unusual or suspicious activity on the part of an individual or a
department. It is usually focused on specific aspects of the work of a department or individual. All members of the campus
community are invited to report suspicions of improper activity to the Director of Internal Auditing Services on a confidential
basis. Her direct number is 562-985-4818.

Follow-up Audit
These are audits conducted approximately six months after an internal or external audit report has been issued. They are
designed to evaluate corrective action that has been

Auditing Security and Privacy in ERP Applications

By S. Anantha Sayana, CISM, CISA, CIA
Volume 4, 2004
Enterprise resource planning (ERP) applications have over the years become the foundation application for many large and
medium enterprises all over the world. ERP systems form the core transaction processing platform for most enterprises in
manufacturing and related industries. The business processes and transactions of the company happen in the ERP system.
The ERP is an integrated system that holds all the data pertaining to these business processes from the beginning to the end of
the chain in a unified database. ERP systems, assisted by networks and central databases, have greatly improved efficiencies
of transaction processing by eliminating barriers of geography and departments.
Does all of this impact internal controls? Yes, substantially. The integrated nature of the ERP enables data entered at one part
of the process cycle to be carried forward to the next part of the cycle for further processing. The acceptance of the validity of
the earlier part of the data is implicit, and there is often no reverification at different stages. An example is provided in figure
1 (each box denotes a process and the department where it occurs).

Every one of these processes would have originated from different departments and may be located anywhere, but the ERP
sees all the data from the common database. At process number 6, the ERP system picks up the purchase order data entered
at process number 2, the goods received and accepted from process number 3, and the supplier's claims from process number
5. It then matches them all, calculates the payment due after applying all the commercial terms, and arrives at a payment
amount and date. The only data that it seeks (even this can be automatically configured) are approvals for payment and the
bank account from which the payment is to be made. In most stable ERP scenarios, there is no verification from base
documents at this stage. Besides this, many other activities performed earlier by other systems may also be done automatically

by the ERP as indicated in box 7. This is only one example. Similar process chains exist for almost all activities, such as the
sales cycle or the manufacturing cycle. As is indicated, the process in box 1 can also be the result of another automated
process called the material requirement planning (MRP) run that might have taken inputs from the sales forecast,
manufacturing capacities, etc.
In this scenario, the impact on controls is that there is no room for checking along the way and again at the end. Two major
requirements of controls emerge from this significant feature of ERP systems:
1.

Every piece of data needs to be authentic and accurate at all stages of the process cycle. An error or a
malicious entry at any of the stages would be carried forward all the way (subject to some validations that
can be built). This requires clear definitions of who should do what and segregation of duties between
people doing those duties enforced through access control. Fortunately, the major ERPs provide excellent
features for defining access control to a great degree of granularity.

2.

Many automatic processes and updates (postings) can happen without human intervention. These are based
on the configurations in the ERP. Therefore, it is necessary that all these configurations be made and
maintained correctly and in line with the control requirements of the business. Most ERPs are designed as
generic solutions that can operate in many countries and businesses catering to different requirements.
Therefore, there is a lot of parameterization, and many parts of the system are configurable. While this is a
desirable feature offering options during implementation, it can also be the source of internal control
weaknesses allowing options that were hitherto completely prohibited.

Approach to Auditing ERPs

The following would be typical prerequisites for carrying out an audit for assessing security and privacy issues in ERP:

Understand the business and the risks specific to that business and its operations. This is the first basic
step, not only in ERP audit, but in any kind of audit.

Understand the enterprise structure. The complexity of ERP arises from the fact that it attempts to
encompass the entire business cycle of the enterprise, covering all major functions and all parts of the
organization in its wake, including financial accounting, human resources and management information. The
mapping of the various organization units is reflected in the enterprise structure in the ERP. An accurate
understanding of the enterprise structure is the first step to carrying out an audit.

Obtain access to the system. The audit of an ERP cannot be done by having someone generate reports and
show them to the auditor. The information systems (IS) auditor should verify the various settings and data in
the system by seeing them in the "live" system. For this, the auditor should obtain a user ID in the
production system with read-only access to all modules and features. Needless to say, the auditor would
need to have a good grasp of SAP and use the access with due care.

Major Areas of Audit Relating to Security and Privacy

The following are the major areas of audit:

Evaluating access controlAll the data in the ERP are in one single database. Theoretically, it is possible
with suitable access to see or modify any part of the data relating to financials, materials, human resources
or sales. In a centralized system connected through a network, access to the ERP is possible from any part
of the network.
Like any other application, access to the data has to be secured not only at the application level, but also at
the operating system, database and network levels through suitable controls. The IS auditor should carry out
a review of the network, OS and RDBMS before evaluating the access controls in the application.
Access control evaluation in an ERP can be a complex exercise and requires good skills with the particular
ERP. Most ERPs control access though menu options, screens and authorization objects, and activity
options, such as add, modify, view and delete. To simplify the access control process, many ERPs use the
concept of roles, assigning standard authorizations to the roles and attaching the roles to users as per their
job descriptions and duties required to be performed. As ERPs are large systems, they have many users.

User ID scrutiny and evaluationA good first step for auditing access control is to obtain a list of authorized
users and their privileges. The IS auditor should also obtain the list of standard roles and the authorizations
required for the roles.
Having obtained this information, the IS auditor can get the list of users from the system through suitable
menu options. (Each ERP has its own procedure for obtaining this information. Such information would be

part of the audit program available with audit firms or can be obtained by discussions with the ERP
consultants or by referring to books.) This can be verified with the list of authorized users. Any mismatch
between these lists needs to be investigated. It is useful at this stage to obtain from the system a list of user
IDs created and deleted during the period of audit and to find the appropriate explanations and supporting
approvals for all these transactions.
The next step is to ascertain that all the authorized users have the appropriate privileges in line with their job
responsibilities. To do this, the auditor should examine the roles that have been assigned to the various
users, and ensure that the roles are in sync with their current job responsibilities. The next step is to identify
from the system the authorizations and privileges associated with each of the roles in use, to ensure that
roles, as defined in the system, are in line with what the role is expected to be. These roles could be called
by other terminology, such as profiles, in different ERPs. Some ERPs provide for a level of granularity that
can be mind-boggling. To cite an example, it would be possible to define a situation where a storekeeper can
create, but not update or delete, goods received notes and only for a certain category of goods at a specified
location of the store. Privileges of create, update, delete and view can be associated with every object based
on the field values. While this is great news to fulfill the very stringent needs of security and access control,
this can easily get out of hand if the entire access control is not properly mapped, planned and documented
meticulously, using all aggregation options at the appropriate levels.
It is also good to approach access control evaluation from another perspective, i.e., from critical functions
and activities that would be required to be carried out only by specific authorized personnel. This would
require a thorough knowledge of the ERP system to identify certain critical transactions. The IS auditor can
query the system to determine the users who have authorization to execute such activities and options. The
IS auditor can evaluate whether the list is aligned with the approved policies of the company. Examples of
these activities include the ability to execute certain sensitive reports, close or open financial accounting
periods for postings, and make changes to certain sensitive masters.
In addition to access control, most ERPs may also require explicit authorizations to approve certain kinds of
actions. These authorizations may be associated with monetary values and other special conditions, such as
approving discounts, sales, purchases and some changes. These should be verified from the system directly
and compared with the organization's policies for such activities.

Verification and evaluation of configurations relating to business processesThis is another major area of
audit for an ERP system. The process flow in every business activity, and the possible options for carrying
out these activities are decided by the configurations in the system. Such configurations exist literally in
every process and module, and the process of evaluating them can be a long and tedious job for the auditor.
The best way to do this is to approach it from the business risk perspective and identify the configurations
pertaining to those processes. Each of these configurations can be seen on the system by executing certain
commands or following a certain path in the menu. An audit program that lists these and the possible values
and options of these is a necessary tool, without which it would be difficult to carry out this evaluation.
The recent books published by ISACA on the security, audit and control of SAP, Oracle and PeopleSoft can
be useful for doing such reviews. IS auditors can use these programs as the baseline and customize them to
their environment based on their experience, with help from the functional consultants.

Change managementThe other factor that can influence security is change management. The way
modifications are done to the programs and the configurations, the effective segregation between the
development and production environments, the processes for testing, quality assurance and migration need
to be reviewed by the auditor.

InterfacesERPs invariably need to send or receive data from other systems. Interfaces can be simple batch
uploads of data or real-time data movement from multiple systems to and from the ERP through an
integration middleware platform. An interface has the potential to become a weak point that can compromise
security. Audit scrutiny of interfaces is one of the important aspects of ERP security reviews. At a simple
level, controls should exist to validate data before upload and verify accuracy and integrity through control
totals and logs, but a review of interfaces through middlware would be a specialist exercise.

PrivacyERPs are such a large repository of different kinds of data that they can impact privacy issues in a
significant way. Most ERPs have a human resources and personnel module, and such modules handle a lot
of data about the employees of the company. The ERP can also hold information about customers, suppliers
and partners.
Privacy laws have been enacted in many countries, and they all have their own flavors. ERPs may operate
across countries in a multinational company and deal with data about employees and customers from
different parts of the world. ERPs or their CRM extensions can also collect other information, such as credit
card or credit rating information, which is impacted by privacy requirements. Such companies have to take
due cognizance of the laws pertaining to privacy in each of the countries in which they operate or have
dealings.

Without getting into individual laws, general requirements may be grouped under a few broad requirements:

Securing personal information from unauthorized access, ensuring its protection through the life cycle of the
information and ensuring its effective destruction when it is no longer required

Catering to the rights of the subject about whom data has been gathered, processed and stored

Not using personal information for purposes other than those for which the information is gathered or
maintained

Many of these requirements can be met only if access controls are rigorously implemented and enforced. The way to address
audit is first to identify the legislation, statute or rules that are applicable. This itself may be a formidable task, spanning across
countries, and there may also be industry-specific regulatory requirements. The second step is to verify what kind of personal
data are stored in the ERP and then go through the audit relating to securing them.

Conclusion
Many factors need to be reviewed during an audit to ensure security and privacy in an ERP system. However, the most crucial
among these is maintaining the access controls and configurations, as these are widespread and can have a significant impact.
These are constantly subject to change; therefore, maintaining them is a challenge. In this context, it is necessary to carry out
the audit of all aspects of an ERP comprehensively at a post-implementation review. Subsequently, the review of access
controls and configurations should be carried out regularly, at least once in six months. The ideal situation would be to move
this kind of audit to a highly automated process using tools to perform a continuous monitoring audit.

http://www.academia.edu/2750399/An_information_systems_auditor_s_profile