Maximizing IT Governance for Strategic Success

1. “He who controls the present, controls the past. He who controls the past, controls the future.” - George Orwell EECS4482 2017

2. Session 3 – IT Governance • Understanding the importance of IT strategy • Governance vs strategy • Governance vs internal controls • Types of IT controls • General controls’ relationship with application controls. EECS4482 2017

3. IT Strategy • Must conform to the business strategy. • Covers a rolling forward 3 year span. • Beginning of IT governance. • Addresses infrastructure, software, information and people. Procedures are not part of it, but rather will need to be developed to support the strategy’s implementation. EECS4482 2017

4. Corporate Governance vs. IT Governance Corporate governance: processes employed by organizations to select objectives, establish processes to achieve objectives, and monitor performance. IT governance: process that ensures the enterprise’s IT infrastructure, systems and people support the organization’s strategies and objectives. EECS4482 2017 4

5. IT Governance • Chief information officer is accountable, setting corporate policies and providing the IT infrastructure. • All executives are responsible for participation, e.g., approving IT expenditure and IT projects, monitoring IT projects and developing procedures. EECS4482 2017

6. Internal Control • It is a system function, instruction, tool or procedure to mitigate risk. • It is not simply a statement of what should be done, e.g., the company should …. • It is not a statement of what management wants done, e.g, to ensure… This is a control objective. • Management is responsible for control design and implementation. EECS4482 2017

7. Classifying Internal Controls by Function • Preventive • Detective • Corrective • Difference between preventive and detective is timing EECS4482 2017

8. Classifying Internal Controls by Scope • General • Application EECS4482 2017

9. General Controls • IT controls that apply to more than one systems. • Should be implemented before application controls as there is likely better value for money. • But not every system has the same risk so application controls are needed. • General controls form the foundation for application controls, e.g., a strong network password makes a payroll system password more reliable. EECS4482 2017

10. Application Controls • IT controls that apply to one system or a suite of related systems. • Their effectiveness depends on the strength of general controls. • An example is a system check of credit limit. EECS4482 2017

11. General Controls • Should be reviewed before application controls • Implemented and carried out by the IT department • Consists of automated and manual controls EECS4482 2017

12. Types of General Controls • Organization controls (including segregation of duties) • Software change controls • Access controls • Systems development controls • Disaster prevention and recovery controls • Network controls • Computer operations controls EECS4482 2017

13. Organization Controls • IT governance • Organization chart and job description • Segregation of duties • Hiring practice. • Policies and procedures. • Management supervision, management review and independent review. EECS4482 2017

14. IT Governance • Board responsibilities • System steering committee • Policies and standards EECS4482 2017

15. IT Governance • Strategic direction • Staffing and training • Monitoring processes EECS4482 2017

16. Board Responsibilities • Understand the importance of IT to the organization. • Understand the magnitude of IT investments. • Challenge the adequacy, necessity and validity of IT investments and usage. EECS4482 2017

17. Board Responsibilities • Review IT performance • Approve eBusiness strategy • Consider legal and privacy issues • Approve major outsourcing contracts EECS4482 2017

18. IT Steering Committee • Consists of executives representing a cross section of the organization. • CIO is default member. • Sets IT strategy and IT control environment/structure. EECS4482 2017

19. Systems Steering Committee • Approves and reviews major projects • IT capacity planning • Monitor IT usage and outsourcing • Develops key performance indicators • Sets policies EECS4482 2017

20. Organization Chart • The CIO should report to a senior level to ensure the organization understands the value and challenges of IT and applies IT appropriately. • CIO should report to CEO or COO. EECS4482 2017

21. The IT Department • Systems development (separate from operations) • Computer operations (separate from development) • Quality assurance (may be part of systems development in a small company) • Security (may be part of operations in a small company) • Database administration (may be part of operations in a small company) EECS4482 2017

22. Systems Development Functions • Systems analysis. • Systems architecture. • Systems design. • Programming. • Testing • Project control. The above apply to systems development projects and systems maintenance. EECS4482 2017

23. Systems Development Function • Should not have access to customer data. • Should not have update access to programs used in operation. EECS4482 2017

24. Computer Operation Function • Hardware support • Server administration • Operations scheduling and monitoring • Database administration • Network operations EECS4482 2017

25. Computer Operations Function • System and data backup • Data retention schedule • Data file label indicating when data can be erased • Implementation of application programs and system software • Help desk • Incident response • Capacity planning EECS4482 2017

26. Quality Assurance Function • Develops policies and procedures. • User education. • Change control testing, authorization tracking and software version management. EECS4482 2017

27. Segregation of Duties • To ensure checks and balances to minimize error • To focus expertise for efficiency • To deter frauds and improper practices • To avoid concentration of power that can be abused • Less practical for small organizations. EECS4482 2017

28. Segregation of Duties • Separate IT department from business areas, this is analogous to separating custody with record keeping. IT plays a key role in record keeping. • Separate development from operations to prevent unauthorized or incorrect program changes. • Security should be a dedicated function. EECS4482 2017

29. Segregation of Duties • Software change implementation and database administration should be separate functions so the person who controls programs have no access to information and this helps to prevent fraud. • Relies on access controls. EECS4482 2017

30. Policies and Procedures • Systems development methodology • Computer operations • Change control • Database administration • Security • Help desk EECS4482 2017

31. Software Change • A new program or a change to an existing program. • Risk can materialize when the program is implemented. • Changes may be ad hoc or part of a systems development project. • Software change controls apply to both types. EECS4482 2017

32. Assessment of Software Change Risks • Non-occurrence – Implementing a software change that was not requested - High • Incomplete implementation - Moderate • Unauthorized implementation - High • Inaccurate implementation - High • Untimely implementation – Moderate EECS4482 2017

33. Software Change Control • Purpose is to ensure that program changes are documented and implemented with authorization and correctly • Relies on access control EECS4482 2017

34. Preventive Software Change Control • Change standards and procedures • Library controls • Testing • Change approval EECS4482 2017

35. Library Control • Need to keep separate libraries: - Development for programmer testing - Testing for independent testing - Staging for user acceptance testing - Production for the live system (in operation) EECS4482 2017

36. Software Operating Environments • An environment is a separate computer, data centre or a partition of a computer logically segregated from other environments in order to control the operation, development or testing. It can also be used to separate different business units or companies to prevent access and avoid data corruption or mix-up. EECS4482 2017

37. Environments • Development – houses the programmers’ libraries and development library (for programmers’ testing. • Test – houses the programs for integration independent testing. EECS4482 2017

38. Environments • Staging – houses the programs for user testing, has all the programs in the production environment and also new programs being tested. Only needed for systems development projects. • Production – houses the programs for live operation. EECS4482 2017

39. Production Environment • The source code does not have to be on the computer for transaction processing, but should be readily accessible for program changes, in order to allow space on the online disks for transaction storage. • Storing production source code offline is better security. EECS4482 2017

40. Development Library • Programmers perform programming, self testing and peer testing. Needs source code and object code. • Can be further divided into a library for each project, group or programmer. • Access to deposit or change should be restricted to programmer(s). • Programmers copy programs from production library into development library to commence work. EECS4482 2017

41. Test Library • Contains programs that are to be tested by independent people, not the programmers. • Can be further divided by projects. • Access control for depositing or changing restricted to people who have no access to deposit or change the development and production libraries. EECS4482 2017

42. Test and Staging Libraries • If errors found in testing, the program has to be returned to the previous library through the previous library’s controlling person. • Movement to test or staging library has to be supported by IT management approval. EECS4482 2017

43. Test and Staging Libraries • Object code must be there because computers need that for data processing. • Source code should be there to maintain consistency with object code. EECS4482 2017

44. Production Library • Contains programs used for transaction processing. • Should be divided by applications. • Source code should be contained in a separate computer from the actual computers used for transaction processing in order not to disrupt operation and to avoid improper changes; a copy of the corresponding object code should be there. EECS4482 2017

45. Production Library • Access to deposit or change should be restricted to people who do not control the development and test libraries. • If the object code is contained in a computer other than the ones used for transaction processing, there should be periodic comparison with the object code in the computers for transaction processing. EECS4482 2017

46. Production Library • Movement to production library has to be supported by IT management and user approvals. • Movements have to be tracked to show who moved, who approved and when. • Movement to production should be done by 2 people together to ensure authorization and correctness. EECS4482 2017

47. Library Control • Source code and object code should reside in each library. • Access to move between libraries should be restricted. • Only people who did not work on the current library version can move to the next library, to prevent unauthorized change. EECS4482 2017

48. Library Control • Should move the source code and object code between libraries. • After each move, recompile the source code to object code and compare with the moved object code. • This ensures that source and object code are always synchronous. EECS4482 2017

49. Library Control • Should compare current production source code with the backup copy to detect changes.; e.g., as simple as comparing the byte sizes. Management can do this. Changes should be reconciled to authorization audit trail. EECS4482 2017

50. Detective Software Change Controls • Log of changes. • Program comparisons. • Review changes for audit trail, testing and approval. EECS4482 2017