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.