Looking at the two dozen or so control frameworks, a theme starts to emerge. While not one of these frameworks encompasses all of the elements mentioned here, most of them have some or even most of the elements mentioned here.

Control Identifiers

Many of the control frameworks, like CobiT and CMMI, have distinctive control IDs (such as PO1 in CobiT or GP 2.10 in CMMI). Some frameworks, like the ISTPA's Privacy Management Reference Model or the AICPA/CICA's Privacy Framework both use simple titles like "Disclosure" (AICPA/CICA) or "Enforcement" (ISTPA) to define their areas of concern. Another type of identifier is the simple legal paragraph or section number methodology that PCI-DSS, the ISO standards, and legal documents use. And yet, there are other control frameworks, like Six Sigma, don't really have control IDs, numbered paragraphs/sections, or titles at all.

So we know that the better control frameworks have easily recognizable IDs to work with. This is important because as controls within the framework change, there has to be a way to communicate that § 1.2 used to say this and now it says that. Or that § 1.2 has been completely redacted.

Taxonomies

Simply put, a taxonomy is a hierarchical way of organizing information. It means that if a control framework says in § 1.2 do this, and in § 1.2.1 do that, the that of the control in § 1.2.1 is dependent upon the this in § 1.2.

Because of their complexity, most of the control frameworks have organized their control identifiers into a taxonomic hierarchy.

Change tracking

One would think, in a control framework, that tracking and communicating the changes of the framework would be very important. It is obviously very important to the ISACA folks who publish CobiT, the PCI-DSS committee, and the ISO standards group. However, some of the other frameworks such as the Malcolm Baldridge National Quality Program or the CICA CoCo - Criteria of Control Framework seem to have completely ignored this fact.

Glossaries

Most, if not all, of the control frameworks have established some form of glossary. Whether that is a simple glossary at the back of their framework document, or a separate glossary document (such as that with the PCI-DSS), you can almost guarantee one exists. And of course each of the control frameworks has to have its own special set of acronyms as well.

The problem is, many of the control frameworks use the same terms to mean slightly different things, and different terms to mean the same thing. For instance, personal information is called just that in some frameworks, as well as electronic protected health information, personal data (as opposed to information), cardholder data, and even ESPI (Electronically Stored Personal Information). Yeesh. And yes, of course they all use the same acronyms to mean completely different terms in many cases.

Role definitions

One of the nicer things about many of the control frameworks is that they are moving away from a structure whereby they name titles (CIO, IT Director) as they assign controls, to naming roles (the role of data custodian) as they assign controls. This is significant in that most organizations do not share the same job description for the same title. By naming functional roles instead of titles, control frameworks can incorporate any number of titles or job responsibilities to include those roles and thereby end definitional confusion (at least on this front).

Assets and configurable items

Only some of the control frameworks go out of their way to define assets and configurable items and link those to their controls. Many of the US National Institute of Technology's framework documents are actually asset specific (OS, application, and hardware configuration guides as an example). Some control frameworks, like the PCI-DSS, have supplements that address particular types of assets (such as their wireless guidance). However, many, if not most, of the control frameworks such as the ISO standards and CobiT only tangentially touch upon assets and configurable items.

Operationalized polices, standards, and procedures

Here's where control frameworks start to disintegrate into oblivion. Most of the control frameworks we've studied mention policies, standards, and procedures. However, those same control frameworks don't actually provide a structure for what should be in those stated policies, standards, and procedures. And that's really strange, because those same control frameworks will call for examining the policies, standards, and procedures during the audit phase.

Data, information, and records classification

While not all of the control frameworks focus on data (think data field in a database), information (think combining multiple bits of information, such as name + e-mail address together in a report), and records management, some very important ones do. What none of the frameworks have done to date, however, is provide a direct methodology for linking data, information, or records together with other controls, such as "protect the data elements while in storage, while in transit, and once published outside of the system."

Audit or assessment guidelines

Whether the control framework calls it an audit, an assessment, or a "organizational self-evaluation", the outcome is still the same - someone is checking on whether the organization in question is following the tenets of the control framework. Initially, PCI-DSS had a separate audit guide. After version 1.1 the audit guide became a part of the control document. The US' NIST 800-53 control framework still has a separate audit guide. The AICPA/CICA has published several, and the CobiT auditors crank out more mini-audit guides than rabbits crank out babies.

The newest trend for control frameworks is to publish an XML-based audit framework that allows the "assessor" the ability to ask questions on the web, through surveys, through software, and in person. Both the US' NIST XCCDF program and the Financial RoundTable's SIG have XML-based audit structures.

Metrics

The accumulation of most of the elements above, plus the addition of measurement and reporting, is what produces metrics. Metrics frameworks are few and far between. However, a great many of the control frameworks have sections on metrics or include metrics throughout.