PMI Virtual Library 2010 Larry Marks

The Top Five Mistakes to Avoid While Planning an IT Risk Assessment

By Larry Marks, PMP
What is an IT Risk Assessment?

here are several reasons to perform a risk assessment for a rms IT activities and resources. First, an IT risk assessment is intended to help IT management: 1. Better allocate resources and perform capital budgeting 2. Assign resources based on a risk-based approach. Second, various regulatory authorities, such as the Federal Financial Institutions Examination Council (FFIEC), BASEL, Securities Exchange Commission (SEC), and the Financial Industry Regulatory Authority (FINRA) require

risk assessments be performed for all nancial institutions. For example, see below. What Can Go Wrong While Executing an IT Risk Assessment? Following is my list of the ve mistakes to avoid while planning or executing an IT risk assessment: a. Project Plan Supplied by Terminated Employees; What Are the Tasks?

financial institution establishes and maintains truly effective information security when it continuously integrates processes, people, and technology to mitigate risk in accordance with risk assessment and acceptable risk tolerance levels. Financial institutions protect their information by instituting a security process that identifies risks, forms a strategy to manage the risks, implements the strategy, tests the implementation, and monitors the environment to control the risks. Page 1, FFIEC IT Examination Handbook: Information Security A strong security program reduces levels of reputation, operational, legal, and strategic risk by limiting the institutions vulnerability to intrusion attempts and maintaining customer confidence and trust in the institution. Examiners and risk managers should incorporate security issues into their risk assessment process for each risk category. Financial institutions should ensure that security risk assessments adequately consider potential risk in all business lines and risk categories. Page 9, FFIEC IT Examination Handbook: Information Security Information security risk assessments should identify the location of all confidential customer and corporate information, any foreseeable internal and external threats to the information, the likelihood of the threats, and the sufficiency of policies and procedures to mitigate the threats. Page 21, FFIEC IT Examination Handbook: Management

Scenario: Several days after I was hired to help operationalize a risk framework that had been developed, the base-lined project plan was presented to me by the project management oce. Included in the plan were tasks that were agreed on by the sponsor, program managers, and project oce and for which we did not understand the origin. The other aected parties could not explain these tasks to us. Lessons Learned: We received buy-in from the sponsor, program managers, and project oce to modify the project plan if there were tasks that did not appear relevant to the framework; one of these tasks was training of aected users. We werent asked to re-baseline the project plan. The sponsor, program manager, and project oce realized that an eort was needed to implement the project plan and indicated that the re-baselined project plan with best practices in mind (what should be done?) was not immediately needed to implement the framework, so we removed the task because it was irrelevant in planning the risk assessment. b. Lack of Buy-In from Sponsors and Aected Parties Scenario: We were asked to set up the organizational structure and plan and execute IT risk assessments throughout the rm and its subsidiaries; however, the sponsor and aected management team were unaware of the: 1. Rationale for executing the risk assessment. 2. Benets to be derived in executing the risk assessment Lessons Learned: We convened numerous meetings with the interested parties (in this case, the sponsor and members of the project oce) to revalidate the whys and hows of performing a risk assessment. The meetings were conducted so we could understand and revalidate the requirements for the project; we then consulted with the project sponsor to re-identify the method and contents of a risk assessment. c. Lack of Communication of IT Policies to Stakeholders Scenario: The risk assessment to be executed is based on: 1. The controls in place to manage or minimize known risks to the rm 2. Identifying and evaluating the controls in place to minimize unmanaged risks that could aect the rm. The controls in place are derived from legal obligations from available regulations and their compliance requirements,

which reect the operating policies and procedures that must be implemented to ensure management is capable of ensuring an optimal degree of compliance with the laws and regulations governing the business. We found that these policies were not communicated to the aected owners; subsequently, how could we hold someone liable for a process they had never been made aware of? Lessons Learned: 1. We re-reviewed the individual policies and their inherent controls to which we were going to hold parties liable and then re-examined them for clarity of objectives and compliance requirements. 2. The policy was put on the fast track toward approval. 3. IT risk assessments were performed in areas initially determined to be included in the scope by the regulatory authorities. We expected fewer problems from control owners, because every examiner included these processes in his or her review. Therefore, we were the facilitators who trained users about what a risk assessment and its impact on them were. d. Scope Changes Made by the Program Manager Without Upper Management Approval Scenario: The program manager made additions to the scope of the project without timely sponsor approval; as a result, I was performing tasks outside my project plan and road map. These tasks were relevant to the other projects (but not to my project) and were executed to expedite their individual timelines. Lessons Learned: A strong sponsor and program oce are necessary to ensure only budgeted tasks are performed. Why are we adding windows to the house we are building if the customer hasnt requested them? e. Lack of Managing Project Dependencies Scenario: In reviewing the project plan for the risk assessment, we observed that project dependencies werent highlighted for management review. Our project was dependent on the task completion in other related, parallel projects. There was no method for reviewing project dependencies across IT portfolios on an enterprise level, This was recognized as an open item. Lessons Learned: We asked the project oce about using their current project management tools to identify cross dependencies for projects. This is necessary because it will

provide upper management with a clearer understanding of (1) the reasons for not meeting agreed upon tasks and deadlines and (2) a better understanding of where one project started and the next one continued. Work will not be duplicated because tasks would have been identied as necessary for a project in the beginning. We also learned to be more cognizant of project dependencies and ask more questions by communicating and discussing our project more often with other aected parties and at the weekly status meeting. Conclusion The above article is a subjective list of mistakes to avoid while planning or executing an IT risk assessment. Better planning, control, organization, and communication are the keys to ensuring successful project completion.

About the Author Larry Marks, CISA, CISSP, CFE, CGEIT, PMP, is a consultant with DataCom Technologies. He is currently operationalizing an IT risk framework at a rm in New Jersey. Mr. Marks has more than 10 years of experience in IT project implementation, quality assurance and control, process improvement and reengineering and governance (compliance, IT audit, IT risk management, SOX), information security (PCI/ data classication) and formal project methodology experience/training across various the nancial services, insurance, healthcare and telecommunications industries. He holds a Bachelor of Arts degree from New York University in History and Economics an M.B.A. in Accounting from New York University.

PMI Virtual Library | www.PMI.org | 2010 Larry Marks 2

PMI Virtual Library | www.PMI.org | 2010 Larry Marks 3