“IS Audit of ERP Software” for ISA 2.0/3.0 ICAI
1. Introduction of IS Audit
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 bench marking with the globally recognized best IT practices of COBIT framework. The initial assignment could primarily focus on the identified areas of SAP Implementation.
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 bench marking 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.
Business Model is:
|BUSINESS: EQUIPMENT MANUFACTURING FOR THE USE IN
|Location 1||Location 2||Location 3||Location 4|
|Mfg. 1||Mfg. 2||Mfg.3||Mfg.4||Mfg.5||Mfg. 6||Mfg. 7||Mfg. 8|
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:
Review of IT Resources as relevant
- Operating Software: Access controls
- Telecommunications Software: Access Controls
- RDBMS Database: Access Controls
- SAP – Major focus area: Configuration of Parameters and Access Controls
- Application controls at various stages such as Input, Processing, Output, Storage, Retrieval and transmission so as to ensure Confidentiality, Integrity and Availability of data.
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. Methodology and Strategy adapted for execution of assignment
Opening Meeting of IS Audit
formation System Audit Process
Reviewing the documents
Interviewing the Key Personnel
Testing of IS Controls
Documentation observations and Findings
Audit Report- Preparation & Distribution
Follow up Activities
8. Documents reviewed
Following things are Reviewed:
- Policies – Are the management guidelines which should be approved by the Top Management and should be reviewed atleast once in each year?
- 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.
- 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.
- Audit logs and Screenshots – Every organization 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..
(1) *Security audit log should be properly configured.* It is configured using transaction 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_disk space/per_day* or *rsau/max_disk space/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 that user need to Input||8|
|login/password_expiration_time||Number of days after which password expires||90|
|login/password_max_idle_productive||Maximum period for which a productive password (a password chosen by the user) remains valid if it is not used.||60|
|login/password_max_idle_initial||Maximum number of days for which initial password remains valid||7|
|login/fails_to_session_end||Number of invalid login attempts until session ends||3|
|rdisp/gui_auto_logout||Maximum time in seconds after which GUI session will automatically logout||3600|
|login/fails_to_user_lock||Number of invalid login attempts until user gets locked||5|
|login/no_automatic_user_sapstar||Controls automatic login using SAP* with default password in the case when user master record of SAP* has been deleted||1|
|rec/client||Activate or Deactivate Table logging in a client||ALL – which 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
Business Process Owner: ABM imited
|Date Of Review: 21/11/2015|
|Control Objective and Control Practices
|Ref||Completeness||Accuracy||Validity||Authorisation||Segregation of Duties|
|1||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 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?|
|2||Source Data Preparation and authorization
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?|
|4||Processing Integrity and Validity
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.
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.