1. Overview
The objective of this document is to outline a standardized procedure to be followed while performing and documenting the SOX test scenarios. However, the procedure and criteria may vary from organization to organization.
2. Importance of SOX Testing
Every organization is responsible to comply with the provision of SOX Act (Sarbanes-Oxley). Most of the organizations run on SAP as an ERP system. Therefore, all the IT controls are linked to an Organizational Business process. These controls being set up correctly and working as desired form an integral part of an organization's performance in the Global Market. In order to achieve the above, a fully complied quality assured SOX Audit of the IT controls needs to be done to give assurance to the shareholders. Hence, it is vital that the SOX activity is completed with due diligence and professionally in line with the quality standards.
Generally, there are three parties involved in SOX testing:-
3. Scope
The scope of testing is applicable for all the existing SOX scenarios and the newly identified scenarios by the organization's compliance team and auditors. The identified SOX scenarios cut across almost all the modules in SAP any may require the testing with third party tools. The number of SOX scenarios varies due to the addition of new scenarios in between the SOX testing cycle. The frequency of the testing depends on an organization's policy, it can be performed monthly, quarterly, half yearly or annually.
4. Scope Identification
The scope of testing the IT controls can be based on multiple approaches. Again, it is the discretion of the organization's compliance team along with the auditors to define the approach and frequency of testing. Following is one of the approaches. Here, we are assuming the frequency of testing to be a yearly activity.
- Compliance team decides on X years testing validity of any given IT control. Let us assume X here represents 2 years.
- Any control which is not tested in past 2 years forms part of the yearly testing cycle.
- Any control which is tested in the past 2 years, but modified in the interim period forms part of the yearly testing cycle. These kind of changes to an existing control can be due to some change requests, Bug fixes correction or new projects.
- Any new control which is introduced and brings a change in business process (es) to be part of the testing cycle.
- Testing to be carried out only for the report which has changed in the Audit Period in case of control consisting of multiple reports/objects.
- Identify the objects/reports which have not changed in the audit period. This helps to identify the scope of the testing.
How to identify or carry out modifications check procedure? Below are the technical steps involved in carrying out the modification check in SAP:-
- T-code SE93/Table TSTC to show the linkage between the report and the underlying program.
- Table D010INC to retrieve the list of all includes under the main program. Enter the program identified in previous step in selection screen of D010INC.
- Identify if the program and corresponding Includes were modified: Input the main program and includes in table TRDIR to retrieve Program Name, created by, created on, changed by and changed on.
- If the Changed on Date for all includes doesn’t falls in the current Audit period, report need not be tested.
Guidelines for documentation (again there are not limited as mentioned below)
- Modification check to be performed in Production system.
- If a control has multiple programs (3) to be tested and only one program is changed during the Audit Period, it need not be captured in the Modification document. The document should contain the modification check carried out for other two programs which have not changed in the Audit Period.
- The screenshots provided in the document are of good quality, with the right level of resolution for viewing. It should also depict the full system level details along with the user Id performing the tests.
- Only those programs to be captured which have not changed in the Audit Period.
Please not that the modification check is carried out where a report or object is involved. It is not carried out for standard SAP customizations and hence such types of controls have to be tested as per the testing cycle.
5. What exactly are we testing?
- Test of design:-To test whether the control is designed effectively in line with the control objective. For example, SAP is configured to block the invoice if price or quantity are outside the defined tolerance. Therefore, from test of design perspective, OMR6 will be executed to review the settings of limits maintained for selected tolerance key for the active company code and if they are in line with the organization's procurement policy. Any deviation as per settings in SAP should be highlighted as part of the test of design.
- Test of effectiveness:- To perform the actual testing. Taking the above scenario, select a company code and create a PO, post a GR that equals PO quantity and then post invoice with IR quantity above tolerance limit and IR net unit price equal to PO price. System should block the invoice.
- Test of completeness:- To confirm if the data reconciliation at the table level and the report matches. For example, in case of bank reconciliation, the documents shown by standard SAP t-code FS10N should match the output of standard SAP table BSEG for the same set of selection parameters.
- Test of accuracy:- Taking the above scenario of bank reconciliation, in this case the total amount of all documents as shown by standard SAP t-code FS10N should match the output of standard SAP table BSEG for the same set of selection parameters.
The control documentation template should be created taking into consideration the control objective, Business process involved, associated risk if the control fails, control owner, testing details, conclusion remarks template, year of testing, control frequency, tester details and above four testing criteria's.
6. Guidelines for testing and documenting:-
Once the scope of testing is finalized with the list of all controls to be tested and sample company code for each control is provided by the auditors/compliance team, the activity for testing the controls can be started. The assumption is that if a control works for one of the in scope randomly selected company code, it should work for all other active company codes in SAP. Before starting the testing, it is important to identify the right set of testers with the right kind of skill set required for testing the SOX controls. Apart from domain knowledge, prior testing experience is an added advantage.
- Testing should be performed in the production systems for the provided sample company code.
- In case the control requires posting of transaction data, in that case the test of effectiveness should be performed in the quality system/pre-production (copy of Production system). However, the test of design can be performed in production system.
- If the control requires testing in pre-production system, version comparison of the transaction between the pre production and production system should be documented.
- Screenshots should be clear and not blurred with the system ID and the tester details being captured. This is important as it captures that the control is tested in production/pre production system and is performed by the identified SOX tester.
- Testing to large extent should be done for the data range in the given audit period. For example, if testing is performed for 2013, data set should be for 2013.
- Briefly explain the steps while pasting the screenshots in the document.
- All the control steps to be performed as per the template.
- Better to use a conclusion success or failure template. This helps to have a common standardization across all the tested controls,
- Highlight the smallest of deviation as that is the very purpose of this activity to find out if the IT control is correctly set up/ working as per the organizational guiding principles.
7. Guidelines for review:- This is an important activity as this is a pre check before the control documentation is submitted to the auditors.
- Check if the control is tested for the sample company code provided by auditors.
- Check if the screenshots are clear and all control steps are addressed.
- Clear and concise conclusion with deviations (if any) are highlighted.
- Documentation does not have any cosmetic mistakes like typos, incomplete sentences etc.
- If the control documentation involves any calculation, to ensure if it is accurate.
8. Closure report: Once the control testing is completed, SOX testing team to submit a closure report stating the controls tested and any noted deviations along with the tester profiles from audit point of view.
