You are going to be dealing with the creation of a lot of documents here, as you are going to be creating two types of standards.

One standard will define which metrics you'll be tracking within each subgroup, and the second standard will define precisely how each of those metrics should be calculated, analyzed, and displayed.

4.2.1 The metrics group standards

The format for a generic standard is much like the format for a generic policy. It contains an overview, purpose, compliance, recourse for non-compliance, scope, description, etc.

The biggest difference between the two is that in the description, wherein a policy focuses on who should be taking action, the standard focuses on the demonstrable outcome, or as some call it, the "artifacts" that should be created. Your metric group standards will define which reports should be included for each of your metrics types.

As an example, your Risk Management Metrics standard might state in its description the following reports:

The organization will report on the percentage of key IT assets for which an assurance strategy has been implemented. [CCI 01657]

The organization will report on the percentage of key organizational functions for which an assurance strategy has been implemented. [CCI 01658]

The organization will report on the percentage of key external requirements for which an assurance strategy has been implemented. [CCI 01659]

The organization will report on the percentage of the organization's information system budget that is allocated to information security. [CCI 04571]

In your implementation pack, we've provided over 25 metrics group standards that cover each and every metric that the UCF tracks. What you'll want to do is to go through each of the metrics groups you want to cover, and ensure that those standards have the individual metrics you want to use. If not, you'll either need to delete or add to them as you see fit.

4.2.1.1 through .3 metrics reporting standards

One of the things you'll also want to create is a standard on how you are going to format each of your metrics. We used the Unified Compliance Framework's database to create a suite of metric reporting standards predefined for you. You'll find them in the implementation toolkit. Each of these is a pretty simple standard that has ten parts as listed below.

1. The metric Control ID which is exactly the same thing as the UCF Control ID (because the creation of a metric is actually a control).

2. The metric title which is simply the title of the metric (this should correspond to the title information on your presentation as well).

3. The update date and time so that the end users know when the document was last revised.

4. The metric overview which has been provided by the UCF controls taken directly from the key authority documents.

The metric reporting standard

5. The authority documents being complied with which has also been taken directly from the UCF control list and references each of the specific metrics as stated by the authority documents.

6. The metric formula as specified by the authority document which is also listed in the UCF controls list.

7. The target goal that the measurement should be reporting against, such as "100% of all systems in place have been appropriately patched."

8. The data source which was either extracted from the authority document and added to the UCF control, or if the authority document didn't list a data source, the UCF team has suggested one.

9. The report format which states how the report should be formatted - especially if the report is going to be a slide presentation or graphic report.

10. Applicable controls are those controls to which this specific metric can be used for reporting purposes. The controls listed in the metrics reporting standards all refer to controls found within the Unified Compliance Framework. Each of the Common Control IDs is a clickable URL reference to that control.

If you are wondering about that last item there - mapping metrics to their applicable controls - yes, that is a very important part of the process. As one of our distinguished field editors pointed out

"You rightly talk about the importance of mapping metrics to controls. We've taken it one level higher and identified a series of key questions for which we want to maintain current answers. These key questions are linked to a group of metrics which individually measure performance against a set of given controls and collectively provide the insight we're after. The utility in this approach is that our hands on technical staff can focus on the metrics and management gets the answers they're after without getting bogged down in underlying detail (although they can certainly drill down as desired)."

Because the above is so important, we've provided all the templates you'll need (over 150 of them) in the implementation pack. You should edit each of these documents as you see fit.

4.2.1.1 through 4.2.1.3 Tailoring your standards

Once you have a basic standard, you can then tailor your standards to each and every metric that you want to deploy.