The Goal

The course is part of this learning path

Start course

This course is the first module in Domain 2: Information Risk Management, which starts off by taking a comprehensive look at the benefits, practices, and outcomes of risk management. We then move on to look at the importance of goals in risk management and how to work towards them.

Finally, we cover the various methods to consider when forming a strategy for reaching your risk management goals.

Learning Objectives

  • Obtain a comprehensive understanding of risk management
  • Learn the importance of risk management goals and the strategy to achieve those goals

Intended Audience

This course is intended for anyone preparing for the Certified Information Security Management exam or anyone who is simply interested in improving their knowledge of information security governance.


Before taking this course, we recommend taking the CISM Foundations learning path first.


Here we have Section 35, our next module in domain two, and we're gonna discuss risk management and its goal. So when we look at our information security risk management program, we always have to be sure that we focus directly on the goals and not get lost in the process along the way.

We have to examine information security architecture because in the terms of risk management, things that get considered will be the goals achieved through the systems and the risks associated with not achieving those goals, the environment in which the systems will be built or used, each of those built used will have different kinds of risks. Some will be shared, but some will be unique to the building environment versus the using environment. And they need to be assessed in proper context.

Then we have the technical skills of the people who will be building again with unique risks and a unique set of people presenting their own risks. And then the operating systems, the operators again having their unique set of risks, along with those risks that are unique to the operating environment as distinct and different from the environment in which it will be designed and built.

Now, the architecture does go beyond the technical. We have to look at the non-technical aspects with equal attention like we do the technical aspects and we have to see this holistically in the context of the entire enterprise that it will be serving because this will be an overall look at the interaction between the system and the enterprise that it supports.

There is a control point which is a single point that supports controls on behalf of the architecture. For example, a single firewall at a network perimeter represents both a single point of control and a single point of failure potentially. A biometric scanner that goes before you enter a room. This too is a single point of control and a potential single point of failure and both aspects have to be examined carefully.

So then the goal, what is the goal of this assessment program to ensure that what we have actually works in the way that we need and produces the results that we want? As I've said, context is vitally important because it sets the stage and frames the essence of the problem.

So we start with setting context and purpose of the program. This begins with understanding the need for risk assessment which attunes our minds and our observations to risk, its impacts, what it looks like, and how it can affect us because we have to clearly communicate the why as well as being able to refer to it as needs arise. We will have to define a scope and the charter, what we're supposed to be doing and those things within the scope that will be examined in pursuit of this goal.

Classically, the security manager must have the authority to carry out this function since it is within their responsibilities. The charter needs to be stated as the scope does at the beginning, and then used as a guide as we proceed through the program steps. We have to define the authority, the structure, and the reporting to ensure that not only does authority match responsibility and accountability, but to the structures within and the communications up, down, and laterally are going to match to that and the information flows that will be required. The reporting hierarchies need to be clear and they need to be established as clear and definite for the life of this program, or when modified, ensuring that all parties related to this process are properly informed in a timely manner.

We have to ensure that asset identification, classification, and ownership are equally well-established. We have to know what the structure is so that we know when when we see a gap that it's a gap and not something that we incorrectly perceive. There should be an asset register that records all of the different assets in each one of these categories.

This statement, this charter needs to state what the objectives are and they need to be prioritized. Number one should be the most important, working its way down to the last one, which though not unimportant, it needs to be less important than number one, which seems logical, but oftentimes, this doesn't get the attention that it needs and it needs to be worked on as the process proceeds.

At the beginning, we need to determine what methodologies are going to be used, what risk management, processes, what risk analysis model, what the qualitative and quantitative techniques are. This will save us the trouble of having to switch to more meaningful ones mid-course which can confuse and delay our responses. And we need to designate a program development team that will develop and implement the risk management program itself. And this should include both security and non-security representatives to ensure that not only is security properly represented, but the business which creates the context that sets the priorities is equally well-represented.

About the Author
Ross Leo
Learning Paths

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.


Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.