Business-IT Team

1. Business-IT Team Roles & Responsibilities For AECs/SODs/EUCs

2. What is an AEC? • Application embedded control – when the system logic performs part or all of the financial control. • As defined in the methodology: • a)Manual controls (controls performed by a person) • b)IT dependent controls (manual controls supported by an IT report) • c)System controls (controls performed by the system through the configuration and system access) • Current Issues w/AEC (some mentioned in IAF audit results) • At the moment we have fewer pure “system controls” documented in our registers. The group methodology assumes the controls labeled as “system configuration” in the “control category” of the registers are pure system controls. However, we did not always write our ACD in this fashion (see advice later for consideration on splitting the controls). • The “system access” and “SOD” controls as labeled in the control category usually have other components are are therefore not pure “system” controls. They should be labeled “IT dependent”. It’s more likely the controls fall into the “IT dependent” category especially when it has a manual component.

3. What is an EUCs? • EUCs – End user computing tools – ie spreadsheets, access database, free form data warehouse queries. • Major Concern with EUCs • Because of the nature and flexibility of these tools they are prone to formula and output errors. They must be identified (by the CR teams) and then remediated to lock down the logic and future changes must be controlled through a proper change control procedure. • Responsibility of remediation is still unclear.

4. Why we have the current problems • Control register structure and history of writing actual controls • During Documentation & Evaluation phase not much emphasis was place on getting a lot of IT detail about specific transactions, reports or input values used. No methodology existed at the time of original D&E phase. • Evaluator made decision to label the control “system”, “IT dependant”, or “manual”. The fact is that each control has multiple components that need to be tested by different groups (business, IT and SOD security). • Methodology for writing AEC control was released in February 2005 and was hardly noticed by the documentation teams. AEC testing requirements and methodology not released until May. • Few details about EUCs (end user computing) tools captured.

5. What are we doing to fix the problems? • Expectation • Central Group expects a greater emphasis on Application embedded controls and system SODs for our SOX attestation; therefore all the controls with these components have been flagged as pervasive controls which puts them into the high priority category “red zone”. • Problem • In order to meet the deadline we need more details before we can write test scripts, test and remediate. • How are we addressing the problem: • Special sub-team called the “Business-IT” team was created to perform the AEC/SOD/EUC testing and remediation. Team staffed with people with IT and Shell business process knowledge. Members from this team should work as an integral part of the CR teams.

6. From the Central Methodology AEC Training AECs are a Joint Exercise • For application embedded controls (e.g. System and System Dependent controls), test scripts will be written jointly by business and application specialists. • Tests will also need to be performed by or with the assistance of an application specialist • Testing of IT controls can be combined, i.e. specific system test tools can be used to confirm the operation of application embedded controls. • Please read the methodology document “Good practices for actual AEC control descriptions” when writing ACDs with and Application embedded control AEC Test scripts CANNOT BE WRITTEN IN ISOLATION, they will depend on the accuracy of the register team work including quality of ACD, narrative, process flow

7. Responsibilities of the Business-IT team • The AEC specialists will work with the CR teams and champion to : • To help clarify the ACDs, adding details and splitting the controls were necessary • Writing test scripts • Conduct testing of AECs • Report results in SPUD and test workbooks • Assist the BUFP and CR teams with development of IT remediation plans or compensating control • The SOD specialists will work mainly with the Business role owners and the CR Teams to: • Write test scripts • Classify controls into manual vs system tested SODs • Provide system access details to manual testing team when manual SOD testing is required • Conduct testing of SODs according to the SOX matrix • Work the business to remove unnecessary access and in-role SODs • Report results to SOX team • Assist with the development of compensating controls for SODs • Assist CR teams with re-write of ACDs for compensating control, most of which will require manual testing

8. What we need from CRT teams • Include your AEC team member in workshops. They have a good knowledge of the business processing and the system functions (or who to contact for more details). • Remember to gather specific system details. Per the methodology and our team rules, ultimately the ACD is the responsibility of the CRT team. It drives our testing requirements. If you feel you don’t have the knowledge to gather the details ask your ACD specialist to help. • Some controls need to be re-written all together to remove process details especially if it contains unnecessary AEC or EUC language that is not really part of the control and therefore does not need to be tested. • Some methodology documents encourage splitting the manual piece of the control from the AEC piece. This should be considered on a case-by-case basis. At a minimum the preventative should be split from detective. Also, consider splitting the pure “system control” from the manual piece of the control. • There is no need to split system SOD or Restricted access component from the manual or IT dependent part of the control.

9. What we need from CRT teams • Challenge the idea that the system is actually performing any part of the control? If not, then label as “manual”. • For example, entering an invoice into the system after the approval. If the control is related to the approval and segregation of approval from request, then the system entry transaction is not a part of the control just the next step in the process. However, if the approval is electronic in the system and the system holds the evidence of the approval then it would be “IT dependent”.

10. EUCs What we need from CR teams • We have created an inventory of EUCs from the business registers, however, we expect many changes to this based on the re-work being performed currently. • Use the special flag in SPUD to mark the controls that contain EUCs, this will help the reporting. • At this point is unclear what we need to do with EUCs? We are asking the group for more clear guidance • At a minimum the CR teams should identify the EUCs that make up part of the control. Don’t just assume the spreadsheet is part of the control. • If the EUC is in scope we need the CR teams to capture additional information about the EUC from the control owner (see attached template) • See the attached document for more advise on identifying in-scope EUCs

11. Segregation of Duties • See separate presentation on the approach for SOD testing and remediation. • Key points: • Don’t assume all SODs are tested by this team, many controls like restricted access will need to be tested manually by the self assessment team. We will provide the restricted access information that will be used in the testing process • We have worked with the central team to map the SAP access to the guideline controls; which means we have translated the following into specific SAP transaction conflicts • Access to the order entry system is restricted to delegated individuals who do not have access to the customer or contract master, process cash receipts or are responsible for the physical management of inventory • Register champions will need to approve the compensating controls and incorporate into the register (need fast turn around in this process) See the separate presentation on this subject.

12. Additional Details collected in SPUD • The standard classification of manual, System, IT dependent is not enough to classify the testing requirements. This is why the additional flags have been added to SPUD. • New expanded classifications: • Std. Business Process • Manual SOD • DOA • AEC (System Conf/IT dep) • System Restricted Access • System SOD • EUC (Spreadsheet) (the business testers will need to gather information about spreadsheets while on site) • Also, tracking the system name, transaction report names in discrete fields in SPUD database • These additional classifications will help us write the test scripts, report progress and reduce the risk of having gaps in testing. • We expect additional field to be added to SPUD to help track test results

13. AEC Assignments

14. Key Message The Business-IT team must work hand in hand with the CR teams to deliver a successful attestation! If one piece fails, we all fail !