This is the part where we really don't have a lot to say to you simply because your processes are how you go about implementing measurement, collecting data, analyzing that data, and then moving your analysis and measurements into your reporting standards.

In building our your processes, you'll want to go back to our earlier section on Creating your own metrics and read up on what we talked about regarding determining if the information sources are reliable, ensuring the information is measurable (and repeatedly obtainable), etc., as these are the keys to implementing measurement gathering and analysis as a day-to-day organizational process.

Here's what we've learned about creating repeatable processes, in a generic sort of way. There are multiple steps in creating a repeatable process for those of you who have to begin at this phase. For our example, we'll use the Common Control ID 01657, which is the Key It Assets for Which an Assurance Strategy Has Been Implemented metric report.

4.3.1 Ensuring that the information is measurable

We know that for our example metric, we need to establish the number of predefined assets in the organization's Configuration Management Database (CMDB). This means that if the organization doesn't have a CMDB, then we'll need to figure out how the organization does track its assets in order to determine the total number of assets.

The other part of the equation is the "assets that have assigned configuration standards." If the organization hasn't assigned configuration standards to its assets, then there isn't anything that is measurable and this metric will have to be abandoned until such time as there is something to work with.

4.3.2 and .3 Ensuring that audit trails are limited to a need to know basis

Before accurate measurements can take place, your organization is going to need to work with your security team, HR team, and configuration management team to ensure that you are setting the access privileges for your measured information correctly. You want to ensure that the data with which you are working can't be repudiated because someone might have changed it.

How you do that will be up to you in your organization.

4.3.4 Determining what should trigger this control into action

What should trigger this control into action? Is this metric to be performed on a regular basis (daily, weekly, monthly, etc.), as part of a system or document lifecycle management, or is it based on other triggers, such as users coming and going and other factors?

In our example, the metric is triggered during the creation or the updating of the systems configuration plan strategy and implementation.

4.3.5 Gathering the data

This step is relatively straightforward - once you've determined where the data lives and when you should be gathering the data, you'll then want to actually go and get the data. And while you are doing it, you'll want to ensure that you are thinking about that process, as described in the points that follow.

4.3.5.1 Assessing the control process attributes in terms of decisions, documentation, assets in use, etc.

List all of the necessary steps, from first to last, that it takes to accomplish this control. The best way to do this the first time is through a table-top exercise wherein the team you've assembled (all those required to carry out the control) walk through the control from beginning to end. The focus will be to determine what process steps come before others, and which are actually decisions or documentation steps. This is best done on a whiteboard or some other large format drawing table where everyone gets a chance at doodling.

In our example, you'd want the team that maintains whatever asset list you have, the team that maintains your CMDB (or whatever you are using to track systems), your configuration management folks, and the folks getting the data. Then you'll want to walk through when the data should be gathered and where to find the data and in what format the data being gathered is in.

Assessing control process expectations for success

What should the outcome be? What should you have fixed, made more stable, made available, kept confidential, documented, or produced?

Our example revolves around documenting the baseline information (all assets) and the control information (those that should be configured properly). You know that you have success when you can gather the measurements defined in the metric's reporting standard.

Documenting the control process flows (either visually or textually)

This is where you'll do your "pre-writing," as we call it. All you are trying to pre-write here are the steps it takes you to achieve success. This can either be in a flow chart format or it can be written directions.

For our example, the focus is on gathering two sets of data. This can be as simple as "grab X report from person A" and "grab Y report from person B."

There is no cut-and-dried method for pre-writing. Whatever works best for your situation, your organization, and the particular control you are addressing is what you should use.

Identifying problems and potential mishaps with the tested control process (and what the mishap reaction steps should be)

What are the actions that should be taken if something does go wrong? Should anyone be notified? Should extra precautions be taken?

In our example, there really isn't much that can go wrong other than the information not being available, or not updated. If the information isn't updated you could ostensibly open a trouble ticket (or just call the person and say, "Hey, run the configuration report for me").

Having someone else run through the process

This is where you separate hype from reality. Now is the time that you take the control process you've documented and hand it over to the line of business person or someone else on the team and ask him or her to follow your documentation. If he or she can repeat (roughly) what you've set out as an objective for success (and avoid the potential pitfalls you've documented), you are good to go. You'll not only want to give the reviewer your process, but you'll also want to give him or her an analysis sheet that asks several questions about the process as you've documented it so far.

Purpose

• • Does the documentation identify why we are following this process?

Triggers

• • Does the documentation explain when this process should be run?

  • Does the documentation explain exceptions to the basic trigger dates and who in the organization may trigger the process to run?

The process steps

• • Are the process steps understandable and usable?

  • Are all of the steps presented in their correct order?

  • Are there any steps missing?

  • Is the information presented sufficient to complete the process?

  • Are there backtracking steps, and if so, are they documented clearly?

  • Are tool usage and required knowledge detailed and assigned to the correct process steps?

  • Did you arrive at the success point when you thought you would according to the process documentation?

  • Did "success" look the way that the process documented it would?

  • Were you comfortable creating the final report? Did you feel you could stand behind and endorse this report?

Identifying short term improvements with the control process

Most likely, during the previous step, the person to whom you handed your rough draft of a process document will have a few substantial edits and will also have found a few more potential mishaps that you'll want to document.