Project Report

of
DISA 2.0 Course
 CERTIFICATE
Project report of DISA 2.0 Course

This is to certify that we have successfully completed the DISA 2.0 course training conducted at:

ABM LIMITED _____from_1st, April, 2014 to 31st March, 2015_________

and we have the required attendance. We are submitting the Project titled:

IS Audit of ERP Software_______________________________________

We hereby confirm that we have adhered to the guidelines issued by CIT, ICAI for the project.
We also certify that this project report is the original work of our group and each one of us have
actively participated and contributed in preparing this project. We have not shared the project
details or taken help in preparing project report from anyone except members of our group.

1. Name: Albert DISA No. 0001 Signed Albert

2. Name: John DISA No. 0002 Signed John

3. Name: Anna DISA No. 0003 Signed Anna

Place: London

Date: 21/11/2015
 Table of Contents

Details of Case Study/Project(Problem)

Project Report (solution)

1. Introduction
2. Auditee Environment
3. Background
4. Situation
5. Terms and Scope of assignment
6. Logistic arrangements required
7. Methodology and Strategy adapted for execution of assignment
8. Documents reviewed
9. References
10. Deliverables
11. Format of Report/Findings and Recommendations
12. Summary/Conclusion
 Project Report
Title: IS Audit of ERP Software

M/S ABM LIMITED

A. Details of Case Study/Project (Problem)

B. Project Report (solution)

1. Introduction
A. The IS Audit Team audited project management controls over the implementation of the
SAP ECC 6.00 Version (ERP) Business Solution. Our purpose was to evaluate Security Controls,
User authentication and authorization, Audit Trails, Assess and Evaluate Management System relating
to change, System monitoring and business process configuration of the SAP ECC 6.00 Version (ERP)
Business Solution.
ABM Group has been using Information Technology as a key enabler for facilitating business
process Owners and enhancing services to its customers. The senior management of ABM has
been very proactive in directing the management and deployment of Information Technology.
Most of the mission critical applications in the company have been computerized and networked.
ABM selected SAP Business Suite to bring a more integrated and seamless approach to internal
processes. SAP deployment in ABM posed unique challenges arising out of the need to integrate
multiple units across different locations, involving extensive procedures and large volumes of
data. The family of business applications provides better insight into enterprise-wide analysis
based on real time data and key performance indicators, improved quality and on-time delivery,
reduction in inventory cost and enhanced customer service. This implementation has empowered
ABM to seamlessly connect all its vendors, customers and partners to achieve improved business
efficiency. SAP-R3 ECC 6.00 Version is deployed across all of ABM’s financial, payroll
and human capital functions. The Modules implemented are PP, MM, FICO, Quality, PM and HR
including Pay Roll. ABM has more than 500 sap users across the company. By implementing
SAP solutions ABM has achieved superior operational excellence and business agility.
 2. Auditee Environment
The primary objective of the assignment is to conduct Information Systems Audit of SAP
implementation and develop related IS Audit checklists for future use, through external
consultants by using the globally recognized IS Audit standards and best practices. The IS audit
of SAP would be with the objective of providing comfort on the adequacy and appropriateness of
controls and mitigate any operational risks thus ensuring that the information systems
implemented through SAP provide a safe and secure computing environment. Further, specific
areas of improvement would be identified by benchmarking with the globally recognized best IT
practices of COBIT framework. The initial assignment could primarily focus on the identified areas
of SAP Implementation.
 3. Background
ABM proposes to have a comprehensive audit of the Information Systems (ERP Audit) in
the Company. While the Information Systems Audit to be done covers both audit of ERP System
and review of its implementation, the IS Audit is expected to be in compliance with the IS Auditing
Standards, Guidelines and Procedures. The proposed IS Audit is further subjected to applicable
Auditing Standards of ICAI. The objective is to identify areas for improvement of controls by
benchmarking against global best practices. Further, any specific risks identified are expected be
mitigated by implementing controls as deemed relevant to ensure that SAP implementation is
secure and safe and provide assurance to the senior management of ABM. Further, IS Auditors
are expected to develop an IS Audit checklist for future use.
 4. Situation
Business Model is:

ABM LIMITED

BUSINESS: EQUIPMENT MANUFACTURING FOR THE USE IN

1. Mining & Construction;

2. Defence; and
3. Rail & Metro.

1. Production 2. Technology 3. Trading Division 4. International

Division Division Business Division

1. Production Division has 4 Manufacturing Location

Location 1 Location 2 Location 3 Location 4

2. Each Location has two manufacturing unit

Mfg. 1 Mfg. 2 Mfg.3 Mfg.4 Mfg.5 Mfg. 6 Mfg. 7 Mfg. 8

3. There are 500 SAP users in all.

 5. Terms and Scope of assignment
The proposed scope of review and the terms of reference as laid down in the following
paragraphs are given in annexure. These terms of reference are based on the preliminary
discussion the assignment team had with the ABM team and is subject to further modification as
required. Broadly the scope of review primarily from security\controls and would involve:

A. Review of IT Resources as relevant

a. Operating Software: Access controls
b. Telecommunications Software: Access Controls
c. RDBMS Database: Access Controls
d. SAP - Major focus area: Configuration of Parameters and Access Controls
e. Application controls at various stages such as Input, Processing, Output, Storage,
Retrieval and transmission so as to ensure Confidentiality, Integrity and Availability
of data.
B. Organization structure policies, procedures and practices as mapped in the information
systems.
Review of policies, procedures and practices as relevant to areas of audit.
 6. Logistic arrangements required

Following logistics arrangements have been made and confirmation about the
same should be obtained before travelling.
• Travel Arrangements – Bus/Train/ Flight bookings
• Accommodation Arrangements – Hotel / Guest House
• Pick-up and Drop arrangements to / from accommodation facility to / from
office and/or station / airport

7. Methodologyand Strategy adapted for execution of assignment

a) Opening Meeting
b) formation System Audit Process
c) Reviewing the documents
d) Interviewing the Key Personnel
e) Conducting Walkthroughs
f) Testing of IS Controls
g) Documentation observations and Findings
h) Audit Report- Preparation & Distribution
i) Audit report
j) Follow up Activities

8. Documents reviewed
Following things are Reviewed:
a. Policies – Are the management guidelines which should be approved by
the Top Management and should be reviewed atleast once in each year?
b. Procedure – Are the detailed documents based on the policies set by the
top management? Procedures contain the detailed information about the
process. All the procedure should be approved by the management and
should be reviewed at least once in each year.
c. Flowcharts – Pictures are worth thousand words when it comes to
understanding the interaction of various processes and how the
transaction flow has the dependencies and branches that run in various
directions.
d. Audit logs and Screenshots – Every organisation implements the
monitoring control over the processes and the preserves the evidences of
the same, in the form of system screenshots and system logs. This gives
an added confidence to the Information System Auditor about the
monitoring control established by the management..
 9. Deliverables
*Security audit log should be properly configured.* It is configured using transaction
(1)
code *SM19*. Certain parameters need to be enabled during configuration of audit logs.

The parameters are:

* *rsau/enable* – The value should be set to 1.

* *rsau/max_diskspace/per_day* or *rsau/max_diskspace/per_file* –

Either of the two can be set

* *rsau/selection_slots* – This is used for deciding the number of filters based on the
various types of logs needed (like a filter for logs related to RFC function calls, filter for
logs related to transaction and reports executed by users etc.)

The logs which get generated can be seen using tcode *SM20*. SM20 giveslogs based
on the filter which has been set ( like what transaction or report was executed by what
user at what time etc.) It also gives a very important information – i.e. from what terminal
the transactions were executed.

The old logs can be deleted using tcode *SM18*. This access should be restricted to
Basis team only.

(2) *Maintaining User Groups* : It is a Best Practice to maintain User groups. User groups
can be created using transaction code SUGR and can be assigned to users. User groups
are very helpful as they help in identifying whether the user is a business user or an IT
user or System user etc. To some extent this helps in identifying the responsibilities that
a user is supposed to have.

Some of the user groups can be as follows (name can be used as per convenience):

 BASIS – For Basis Team members

 SECURITY – For Security Team Members
 MM, SD, FI etc – For IT production support users belonging to
various functional modules
 BUSINESS – Business Users
 ESS – For users who login through portal
 CANCEL – For cancelled users
 INACTIVE – For Inactive users
  SYSTEM – For user type system
 SUPER – For super users like SAP*, DDIC, etc

(3) *Table logging* : There are certain tables where table logging should be enabled in
Production system. The technical setting of such tables need to be adjusted to “/Log data
changes/”. Transaction code *SE13* can be used for verifying whether table logging is
enabled or not. Table *DD09L* can also be used with the condition /Log = X/ to get an
overview of the tables for which table logging is enabled. Change document for such
tables can be viewed using table *DBTABLOG*.

(4) *Maintaining proper values for Profile Parameters* :Proper profile parameters values
must be maintained as per the Best Practices so as to satisfy Security Audit
Requirements. Below are examples of some such profile parameters.

Profile Parameter Description Expected

Value

login/min_password_lng Minimum length of password 8

that user need to Input

login/password_expiration_time Number of days after which 90

password expires

Maximum period for which a 60

login/password_max_idle_productive productive password (a
password chosen by the
user) remains valid if it is not
used.

login/password_max_idle_initial Maximum number of 7

days for which initial
password remains valid

login/fails_to_session_end Number of invalid login 3

attempts until session ends

rdisp/gui_auto_logout Maximum time in seconds 3600

after which GUI session will
automatically logout
 login/fails_to_user_lock Number of invalid login 5
attempts until user gets
locked

login/no_automatic_user_sapstar Controls automatic login 1

using SAP* with default
password in the case when
user master record of SAP*
has been deleted

rec/client Activate or Deactivate Table ALL – which

logging in a client means table
logging
activated in all
clients

(6) *System and Client Setting options:*

Following System change options should be set for Production environment.

These can be set using transaction code SE06 (System Change Option):

* *Global Settings*: Not Modifiable

* *Software Component*: Not Modifiable

* *Namespace / Name Range*: Not Modifiable

Following client setting should be set in Production environment:

* *Client Role*: Production

* *Changes and Transports for Client-Specific objects*: No changes allowed

* *Cross-Client Object Changes*: No changes to Repository and cross-client

customizing objects

* *Catt and eCatt Restrictions*: Catt and eCatt not Allowed

Audit is a never ending topic. We can continue to talk about as many security audit
concepts as possible. We will discuss about some other very important points in our /*next
post*/ on SAP Security Audit Guidelines.

Controls & Check list

IS Auditor Review of Application Controls

Process/Application Name: IS Audit of ERP Software Date Of Review: 21/11/2015

Business Process Owner: ABM imited

Control Objective and Control Practices Information Objective

Description

Ref

Segregation of Duties
Completeness

Authorisation
Accuracy

Validity
Source Data Preparation and Authorisation

Ensure that source documents are prepared by authorized and qualified personnel following established
procedures, taking into account adequate segregation of duties regarding the origination and approval of
1
these documents. Check whether the source document is a well-designed input form. Detect errors and
irregularities so they can be reported and corrected.

a Whether the source documents is designed in a way that they

increase accuracy with which data can be recorded, control the
workflow and facilitate subsequent reference checking?

[Where appropriate, include completeness controls in the design of

the source documents.]

b Whether the procedures for preparing source data entry, and ensure
that they are effectively and properly communicated to appropriate
and qualified personnel? [These procedures should establish and
communicate required authorization levels (input, editing,
authorizing, accepting and rejecting source documents).The
 procedures should also identify the acceptable source media for
each type of transaction.]

c Whether the function responsible for data entry maintains a list of

authorized personnel, including their signatures?

d Whether all source documents include standard components and

contain proper documentation (e.g., timeliness, predetermined
input codes, default values) and are authorized by management?

e Whether application automatically assigns a unique and sequential

identifier (e.g., index, date and time) to every transaction?

f Whether the document that are not properly authorized or are

incomplete to the submitting originators for correction, and log the
fact that they have been returned is maintained? Whether review of
logs periodically done to verify that corrected documents are
returned by originators in a timely fashion, and to enable pattern
analysis and root cause review?

Source Data Preparation and authorization

2 Establish that data input is performed in a timely manner by authorized and qualified staff. Correction
and resubmission of data that ware erroneously input should be performed without compromising
original transaction authorization levels. Where appropriate for reconstruction, retain source documents
for appropriate amount of time.

a Whether criteria for timeliness, completeness and accuracy of

source documents have been communicated?

Whether mechanisms are there to ensure that data input is

performed in accordance with the timeliness, accuracy and
completeness criteria?

b Whether per-numbered source documents for critical transactions

are used? Whether application allows identification and listing of
missing source documents?

c Whether definition for who can input, edit, authorize, accept and
reject transactions, and override errors is there?

Whether the same is as per roles and responsibilities of individual

and record supporting evidence to establish accountability is
maintained?
d Whether procedures to correct errors, override errors and handle
out-of-balance conditions, as well as to follow up, correct, approve
and resubmit source documents and transactions in timely manner
are defined?

e Whether application system generates error messages in a timely

manner and as close to the point of origin as possible?

Whether the transactions are processed without errors being

corrected or corrected or appropriately overridden or bypassed?
Whether the errors that cannot be corrected immediately logged in
an automated suspense log?

Whether error logs are reviewed and acted upon within a specified
and reasonable period of time?

f Whether errors and out-of-balance reports are reviewed by

appropriate personnel, followed up and corrected within a
reasonable period of time and that, where necessary, incidents are
raised for more senior attention? Whether automated monitoring
tools are used to identify, monitor and manage errors?

g Whether all source documents are safe stored (either by the

business or by IT) for a sufficient period of time in line with legal,
regulatory or business requirements?

3 Accuracy, Completeness and Authenticity Checks Establish that data input is performed in a timely
manner by authorized and qualified staff. Correction and resubmission of data that were erroneously
input should be performed without compromising original transaction authorization levels. Where
appropriate for reconstruction, retain original source documents for the appropriate amount of time.

a Whether the transaction data are verified as close to the data entry
point as possible and interactively during online sessions?

Whether the transaction data, whether people-generated, system

generated or interfaced inputs, are subject to a variety of controls to
check for accuracy, completeness and validity?

b Whether controls to ensure accuracy, completeness, validity and

compliancy to regulatory requirements of data input put in place?
Whether validation criteria and parameters should be subject to
periodic reviews and conformation?
c Whether access control and role and responsibility mechanisms are
established so that only authorized persons input, modify and
authorize data?

d Whether requirements for segregation of duties for entry,

modification and authorisation of transaction data as well as for
validation rules defined?

e Whether report of transactions failing validation generated?

Whether report all errors are generated in a timely fashion?

f Whether transactions failing edit and validation routines are subject

to appropriate follow-up-until errors are remediated? Whether
information on processing failures is maintained to allow for root
cause analysis and help adjust procedures and automated controls?

Processing Integrity and Validity

4 Maintain the integrity and validity of data throughout the processing cycle. Detection of erroneous
transactions does not disrupt the processing of valid transactions.

a Whether mechanisms to authorize the initiation of transaction

processing and to enforce that only appropriate and authorized
applications and tools are used defined and put in place?

b Whether processing is completed and accurately performed with

automated controls?

[For example: Controls may include checking for sequence and

duplication errors, transaction/record counts, referential integrity
checks, control and hash totals, range checks, and buffer overflow. ]

c Whether transactions failing validation routines are reported and

posted to a suspense file? Whether the errors are reported in timely
fashion? Whether the information on processing failures is kept to
allow for root cause analysis and help adjust procedures and
automated controls, to ensure early detection or to prevent errors?

d Whether the transactions failing validation routines are subject to

appropriate follow-up until errors are remediated or the transaction
is cancelled?

e Whether there is a unique and sequential identifier to every

transaction (e.g., index, date and time?)
f Whether an audit trail of transactions processed. Include date and
time of input and user identification for each online or batch
transaction maintained?

Whether there is a listing of sensitive Transactions and before and

after images maintained, to check for accuracy and authorisation of
changes made?

g Whether integrity of data during unexpected interruptions in data

processing with system and database utilities, maintained? Whether
controls are in place to confirm data integrity after processing
failures or after use of system or database utilities to resolve
operational problems?

h Whether any adjustments, overrides and high-value transactions are

reviewed promptly in detail for appropriateness by a supervisor who
does not perform data entry?

i Whether reconciliation of file totals done? [For example, a parallel

control file that records transation counts or monetary value as data
should be processed and compared to master file data once
transactions are posted identify report and act upon out-of-balance
conditions.]

4 Output Review, Reconciliation and Error Handling

a Whether the handling and retaining output from IT applications,

follow defined procedures and consider privacy and security
requirements?

Whether procedures for communicating and follow-up defined for

distribution of output?

b Whether Physical inventory of all sensitive output, such as

negotiable instruments taken and compared it with inventory
records?

Whether there are procedures with audit trails to account for all
exceptions and rejections of sensitive output documents?
 c Whether out-of-balance control totals exist and exceptions reported
to the appropriate level of management?

d Whether procedure exists to check completeness and accuracy of

processing before other operations are performed? Whether reuse
of electronic output subject to validation check before re-use?

e Whether procedures are defined to ensure that the business owners

review the final output for reasonableness, accuracy and
completeness?

Whether the output is handled in line with the applicable

confidentiality classification? Whether the potential errors are
logged in a timely manner?

f Whether for sensitive output, definition exists as to who can receive

it? Whether such output is properly labeled for reorganization?

10. Format of Report/Findings and Recommendations

ERP ECC 6.00 Version Business System Reports

We determined that

(1) Controls could be improved for recording restricted transactions and Activities.
(2) System interface modification prevented posting payroll during the period October 2013
through March 2014,
(3) Petty cash expenses were not promptly posted,
(4) Centrally billed travel was not posted in a timely manner, and
(5) Beginning balance reports were not made available to the units until July 2014, nine months
after the October 2013 Phase I implementation date. As of September 24, 2014, units across the
Institution were still verifying their respective beginning balances.
(6) Audit of the Purchase Card Program, December 3,2014. We determined that the Chief
Financial Officer did not ensure that the ERP working group that developed the purchase card
functional requirements included cross-functional experts. Also, cardholders and fund managers
could not use the ERP system to determine whether available fund balances existed prior to
making purchases because the system provided inaccurate fund balances.
(7) Inaccurate fund balances have contributed to the erosion of confidence in the SAP ECC 6.00
Version (ERP) Business Solution information.

(8) Audit of the Smithsonian Financial System, July 12, 2011. We determined that the Smithsonian
Financial System was not meeting internal management and reporting needs of Institution units.
The Smithsonian Financial System was not a user-friendly system and did not provide the units
with the financial information needed to manage their various projects and activities related to
project accounting, ad-hoc reporting, and monthly reports.

Proiect Management Reports

Audit of the Project Management of the Steven F. Udvar-Hazy Center, July 31,2014. We identified
improvements needed in financial management and project controls for monitoring budget-to-
actual project revenues and expenses; planning system user requirements; and procedures for
monitoring contract modifications.

Audit of Project Management of the National Museum of the American Indian Mall Museum,
September 30,2013. We determined that the Office of facilities Engineering and Operations was
not completing reconciliations of its internal project financial tracking system records to the
Institution's financial system in a timely manner. We recommended that financial and
management controls be strengthened by the ERP project team defining requirements and
reports needed for monitoring construction projects.
Audit of Trust Fund Budget Process, September 28,2012. We determined that significant
management control weaknesses existed in the trust fund budget process. We recommended
improvements in two areas: (1) completeness of the trust fund budget process and (2) controls to
ensure that budgeted expenditures are not exceeded.

Audit of Financial Management of Traveling Exhibits, September 26, 2012. We determined that
controls were inadequate due to inaccurate managerial cost accounting information. We
recommended that policies and procedures be established for accumulating and reporting costs
regularly, consistently, and reliably. Such cost information is necessary for the Institution to
manage its operations and to carry out its fiduciary duties and responsibilities effectively. Routine
cost information is fundamental to any well-managed, cost-effective organization.

Audit of Project Management Related to the Purchase of the Victor Building, February 21, 2012.
We determined that there was no dedicated project manager to ensure that prudent business
practices and generally accepted project management procedures were in place and operating
properly. As a result, there was a high risk of cost overruns on the projects, delays in their
completion, and added costs inevitably occasioned by such delays.
 11. Summary/Conclusion
This report is quite reasonable as verified from various departments and managers and
workers, to the best of our knowledge & belief. This report is issued without any prejudice &
subject to terms & conditions of the policy issued. Thanking & assuring you best of my attention
at all points.

PREPARED AND SIGNATURE BY

C.A. Albert M.NO.425 ISA NO 0001

C.A. John M.NO.079 ISA NO 0002
C.A. Anna M.NO 421 ISA NO 0003