That brings us to section two, in which we will discover governance, goals, strategies, policies, standards, and procedures. So let's begin the discussion of the relationship of concept to realization.

We begin with a goal which is something that is strategic or tactical in nature, and defines the end towards which the effort will be defined further, as directed. These goals of information governance programs will outline, in a general way, what must be done to achieve a posture, a target, or a favorable outcome of some description.

From the goals, we will develop a strategy. In this case, "strategic" would mean specification of an approach to obtain the goal we have defined. The strategy, therefore, defines a series of steps and objectives that are laid out to attain a programmatic objective, either an overall goal or a specific series of objectives.

Within goals and strategies must exist these objectives. These tend to be both strategic and tactical in nature, but must take their proper place in each part of the overall strategy. In this case, would be seen to be tactical. That is, a "specific attainment of a product of a specifically directed effort; usually recursive and attained in a defined sequence."

In each case, these objectives should be seen as waypoints and attainments to be made as outlined in the strategy that are fundamental building blocks to achieve the desired goal. When we think of governance, we think of an overarching approach to protecting assets, using the assets in appropriate, responsible ways, and taking other reasonable steps to ensure that whatever our endeavor is, proceeding along reasonable, properly regulated pathway.

Governance is a program in which we create a plan for achieving defined business goals, ensuring folks are assigned to those roles within that plan and that everyone executes their portion of the plan in a responsible and timely manner.

In classic business, this has been traditionally seen as the responsibility of the board of directors, of the board of regents, or other governing body of a company executives with attendance of outside appointees. This group then is tasked with the ultimate responsibility for ensuring that the plan is reviewed, accepted, and properly implemented.

Part of achieving the goals of the program of governance is ensuring that people tasked with responsibilities within that plan, have the authority to execute and enforce it. It may seem an obvious point, but there's no point in having responsibility if you don't have the authority to make it happen. So we boil it down to the goal. This of course, is the objective at a high level, that you want to achieve.

A goal, as stated, is the ultimate endpoint of a particular program of action, but in a goal statement, the details of that achievement may not materialize. The example would be colonizing Mars. We define our goal as a desire to establish a colony on Mars, as an output from earth, with 100 settlers.

To reach the goal we have to go into greater depth. In this particular case, a great deal of depth, in order to materialize our goal. The obvious next step is develop a strategy to achieve that goal. Within that strategy, of course, will come the details that will make the achievement of the goal materialize and reveal the actual methodology by which we will achieve it.

So following the goal, as we said, will, the development of a strategy. So continuing our example of the colonization of Mars, we must develop a plan for achieving the goal. This plan, called our strategy, will outline the detailed approach that we are going to take.

In this case, one step we must take is to build a spaceship. Following this, at a general level, will be filling the spaceship with colonists. Once these two steps are accomplished, then we will launch the spaceship to Mars as its destination.

As we've already said, the strategies, when laid out at this level, do not describe all of the details at a very low level of how the strategy will be accomplished. What the strategy will do is lay out the roadmap, highlighting in a general way, the steps that will be necessary to achieve the goal. This is what you would call "a functional level description," so that in accomplishing each of these steps, we've moved the plan forward towards accomplishment.

Going back to the beginning of our strategy, that is building a spaceship, we're going to need some guiding principles on how we go about doing that because if we don't take that first step, the rest of the plan will have no meaning. Questions might be asked would certainly include the obtaining of the necessary parts, costs incurred for getting those parts, availability of those parts, and other factors, including reliability, and so forth. And of course, if we want to keep the mission a secret, we're going to have to figure out how to do that.

One very common first step will be to first understand the issues, then craft the policies, outlining what we're going to do in the way of obtaining and then proving, and providing guidance. So we move on from our Mars example. When we begin the crafting of an information security management system, or ISMS, we have to start at a high level. Building the ISMS represents understanding of issues, both operational and regulatory, that must be addressed by the information security management system.

So let's look at our diagram and see what we have. At the top level we have the business drivers. These business drivers explain the why of what we are about to do. In the business drivers are included, the operational concerns, constraints, and so forth, and the regulatory issues that impact our business.

In the mid level of our diagram are the enterprise policies and standards hierarchy, and the defined roles and responsibilities of the various positions of people and the roles that they will play in the execution of the ISMS. The mid level then defines the what and the who of how this ISMS is going to function.

At the bottom level describes the how-to at a more operational level. Here we have what you might call the nuts and bolts, procedures, specifications, and any form of the implementation guidance, which may come from internal or from an external source.

In the previous slide, we named several different items that will be required to ensure that the ISMS is properly defined and populated with the various things that will see it through to its proper implementation. So let's look at the relationship between these different concepts.

First thing we have to do is examine our operational and our regulatory environments. And from this, we will find the laws and other external requirements sources and using them to frame the structure of the ISMS by preparing other guidance documents that will serve to implement the actual policy.

So first we have the policy, setting the conditions, constraints, and expectations. From the policy we will derive standards, setting and establishing types and conditions. Types of performance or metrics that measure these factors.

Standards, of course, can also name products, such as hardware or software that are to be used as the quote unquote "standard" to be employed. Along with these, we have procedures which will specify precise step-by-step execution of processes and workflows that will accomplish the work defined. Supporting these may be a baseline which will define and set minimums and control objectives to be achieved and maintained throughout the ISMS.

This program will have guidelines. In comparison to a policy which tends to focus on the binary compliant, not-compliant adherence to policy, a guideline is used to provide more flexible guidance in encountering the situation that is not binary, and may in fact be an exception to the expected situation. Thus, the guideline can be used to provide greater latitude and the decision to address the situation, while still achieving the compliance objective.

Let's be good by looking at the policies here on slide 20. Classic policies are high-level statements that dictate the direction the business is heading by providing a statement of executive management's expectations, legal requirements, or other rules of the road that have the endorsement of senior management and the expectation that the workforce will comply with them.

In mature organizations, policies are normally well-developed and may remain static for prolonged periods of time. Policies are often derived from external regulatory rules and laws, and may change only when the laws change that caused them to be formed in the first place.

Let's return to our example of Mars colonization. Here's an example of a policy that might be put in place. "Spaceship design information shall be controlled in a manner that prevents unauthorized access." This policy does not state details about how this will be done. It simply describes the expectation.

You might consider that policies create the so-called constitution of the organization. Policies must however trace back to strategies, as well as to expectations derived from regulatory sources and other constraints. In our example above you can see the policy can trace back to step three of the Mars strategy, that is to keep the launch secret. This traceability is a very important characteristic because it shows the origins and traces it back to the founding of the strategy, or plan.

It is of course possible to create sub-policies or specialized policies to address other more unconventional sorts of needs, those things that are considered variations on the standard occurrences or themes. Having described the policy, let's look further and describe the attributes of what makes up a good policy.

One point is that the policy will describe a strategy from which the policy derives its purpose. A properly written policy will have a single point or focus to it. A well-drafted policy will be very clear and easily understood by all who read it. A properly written policy will assign ownership to a corporate officer to ensure its promulgation and enforcement throughout the organizational units to which it will apply.

Good policies usually are not book-length, but are in fact very concise in presenting their points and objectives. In addition, the best policies describe measurable conditions, will also define the metrics by which those conditions will be measured. But a policy may just be the beginning.

The other documents we've already named must come and play to ensure the policy is properly understood so that it can be properly implemented. One of the documents we previously named as the standard, as we said, the standards described conditions, products, or other items that will be used to the exception of all else.

If the policies are described as the constitution of the organization, then standards may well define the laws that then describe how that constitution, or those policies will be enforced. Here's an example of a standard to be issued for passwords. "Passwords for low and medium security information shall be composed of no fewer than eight characters consisting of a mixture of upper and lower-case letters and at least one number and one punctuation mark."

As you see, our example standard states necessary limits, but does not greatly create a restrictive form. As with all of these documents, standards can change and should change, as conditions change. It is possible to have multiple standards per policy. However, these standards should be carefully examined to ensure that they are not in conflict with each other.

As is often the case, policies and standards normally will include exception handling for any conditions that vary from the expected ones. Normally, standards are seen as being tactical, but don't actually get the work done. For that, you need to have procedures. Procedures outline the step-by-step process of achieving a specific goal or objective. There are some conditions, however, that give rise to well-defined, well-written procedures.

Procedures should be precise, and as concise as possible, defining clearly the steps to follow. Part of this will include stating required conditions, expected outcomes, and what to do in the event that the outcome is not what is expected. Certain language within a procedure may have specific meanings.

For example, the term "must," may indicate something that is mandatory, or the term quote "should," may mean a preferred way, but not a mandatory way. In the same sense, the term "may" can be used to indicate an aspect of the procedure that is discretionary. There will be conditions, of course, that don't follow exactly in accordance with the written procedure. When we encounter those, we must turn to a guideline to deal with unexpected conditions or situations.

In comparison to policies, procedures, and other documents, a guideline can be seen as taking a more flexible approach to deal with variations in expected norms. The guideline is written in such a way that it states clearly the desired objective to be achieved. The objective may be a compliance outcome or a condition that the business requires for operational reasons. However, it may be that the expected norm is a condition that does not occur, and a variation presents itself. This is where a guideline can provide needed information to still obtain the desired objective while providing greater latitude in doing so.

Using our Mars colonization example again, we might have a procedure that details how to put 100 colonists in the spaceship. However, the writer of that policy and its procedure may not have taken into account the stowage of the colonists' personal effects. That being the case, a guideline may provide information or flexibility and how to achieve the desired outcome, that is, having the 100 colonists aboard by having a flexible application of the policy to include the colonists and the stowage space for their baggage.

As you see here, there's a hierarchical relationship with the documents we've been describing. At the top of this chart we see the laws, regulations, accepted industry best practices, are at the top. Being so, they drive how we put together all the other ones. Below that, we have general corporate policies and system-specific policies.

At this level, in each case, they are management's security statement or operational statement about how things will be handled. In the general corporate policy, these will be generally addressed to all workforce members. In system-specific policies, such as email, or accounts payable or payroll, the system-specific policies will interpret the general corporate policy, as may apply, and provide guidance on how these specific systems will be used or will behave, subject to the general corporate policy. Below both will be the subordinate documents we've spoken of: standards, procedures, baselines, and guidelines.

So in bringing all of this together, we have developed a flow. The process flow that these documents, in their interrelationships describe is, as follows: The process flow begins with the definition of a goal that seeks to achieve. Once the goal is established, a strategy must be defined to actually seek to achieve that goal.

In order to follow the strategy, policies must be crafted that will carry it out. For the policies to succeed, additional documents will need to be created that would allow for its action, its measurement, and the specific steps required for its performance. Standards will be defined as foundational. Procedures will be defined to specific steps in its achievement. Guidelines will be created to handle non-standard, non-normal conditions.

While all of this is being created, it must be kept in mind that the guiding documents will be the goals specification, the strategy to implement the program to achieve the goals, and the subordinate documents, such as policies, will form the pathway of how to get there.