While it might be nice to understand the pervasive principles, they don't really help us to determine the scope of each of the audits we are undergoing. For instance, CobiT and the ITIL library provide a massive span that covers a great deal of control objectives - everything from security through operational issues and even leadership objectives. Most of which can be ignored if the audit you are going through is an HR audit on hiring practices for your IT department. So for our first attempt to set boundaries for what should be "in play" during any particular audit, we searched for broad functional IT impact zones and came up with twelve of them. By using existing cross-references as a key, we were able to build our first table of impact zones and summaries of requirements for control objectives within each IT impact zone.

The next step was standardizing the terms to be used within the key IT control objectives. For example, we use the common moniker "confidential information" to refer to HIPAA's "electronic Protected Health Information (ePHI)", VISA's and GLB's "customer information," multiple privacy regulations' "client information," as well as Microsoft's "privileged information." Through this methodology we are able to determine when a yellow tomato and a red tomato should be simply referred to as tomatoes. And to ensure that we don't get confused ourselves, we maintain a full working glossary of all terms and their reference sources.

The top level IT Impact Zones

The final step in the process was to examine the commonalities of major impact zones and unify control objective definitions and labels. CobiT divides the world into sections labeled PO, DS, etc. ISO 17799 divides its material differently, as do all of the other standards. While this might seem confusing, what they are all doing is really talking about the same 12 information management impact zones:

The twelve information management impact zones

1. Leadership and High Level Objectives ensures that your organization's top echelon leadership is coordinating strategy with your IS staff's tactics.

2. Audits and Risk Management ensures that you are actively conducting threat and risk audits to assess your vulnerabilities and create a triaged gap plan to fix the problems that could turn threats into reality.

3. Product Design and Development asks much tougher questions than most of us are used to asking when we are creating custom applications.

4. Acquisition of Technology asks the same type of questions when the organization is putting customized systems into place through acquisition. The complex equation of scoping, assessing, sourcing, and implementing acquired technologies are covered in this impact zone.

5. Operational Management is, as it sounds, dealing with the day-to-day activities of most information management needs.

6. Human Resources Management focuses on the areas of identity management, background checks, separation of duties (and when it doesn't make sense), considerations for outsourcing and consulting services, supervision strategies, team development and communication, budgeting, recruiting, job definitions, performance discipline, and more are covered here.

7. Records Management isn't thought of much by most information management leaders, but needs to be brought to the forefront. Paper records have been professionally managed for years. But something happened when organizations moved to electronic records. We'd hazard a guess that most organization's electronic records management systems are no where near as professionally managed as they should be. And that includes e-mails, instant messages, and unstructured information as well as formal documents.

8. Technical Security has always been at the front burner of most IT staff members' minds and continues to play a dominant role in information governance. Access management, identity verification, data protection within and across networks, within databases and records archives, and down to individual computers and their software are all covered within this impact zone.

9. Physical Security is the touch-it-feel-it counterpart to technical security.

10. Systems Continuity has evolved out of the disaster recovery world. Organizations today have learned that it is much better to ensure an organization's continuity rather than waiting for a disaster to happen.

11. Monitoring and Reporting is one of the key regulatory compliance impact zones as it is fundamental to being able to collect data and report on the condition of the systems being monitored.

12. Privacy is becoming one of the most critical issues for information management - especially for organizations that are in multiple states or multiple countries.

13. After the first two years of mapping, we realized that a thirteenth IT Impact Zone was emerging on its own: System hardening through configuration management. So we re-examined all of the configuration and hardening controls we'd already mapped, and then remapped them as appropriate in this new IT Impact Zone.

By looking at the corpus of standards and regulations through the lens of unification and along the lines of the impact zones we just discussed, we created a unification matrix for each impact zone that takes into account regulatory and standards bodies, doctrines, and language.

The hierarchical taxonomy

No other compliance framework has as one if its foundational elements a controlled vocabulary, one of the first tasks the Unified Compliance Framework undertook.

By harmonizing the terms that different authority documents use for the same type of information, controls, activities, etc., a unified compliance framework can more precisely define when controls overlap and when they don't. Take for instance the call by various authority documents to protect restricted data. HIPAA calls for the protection of ePHI. PCI-DSS calls for the protection of cardholder data. Various state, federal, and international laws call for the protection of Personal Identifier Numbers (PINs) or Social Security Numbers (SSNs). Without a controlled vocabulary, there would be no method for establishing that each of these controls calls for the same type of protections for restricted data that the others do.

Metadata items found within a controlled vocabulary

Beyond vocabulary, the framework can eliminate false conflicts by properly defining and abstracting the controls found within the document. Properly defined, "to control" is an activity conducted to bring into check (to manage or to verify), or to constrain (to restrict or confine) something, the results of which bring forth a demonstrable outcome.

Controls within an authority document

Therefore, we can say that each control found within every authority document can be abstracted and broken down into two parts:

1. the action and demonstrable outcome being called for (the basis of the control) as well as

2. the parameters associated with the action

This abstraction allows the organization a methodology for reducing resources by combining overlapping (and even potentially conflicting) controls. As a case in point, two authority documents call for the same control, but use different terms (which can be harmonized through a controlled vocabulary) and have slightly different parameters (which can be ignored in the definition of the control).

Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet).

The risk analysis can be broken down into asset identification, threat and vulnerability identification, likelihood assessment, and risk measure... The Reference and Further Reading Sections of this document provide some information on LAN threats and vulnerabilities.

In its application within the organization, the harmonized control is simply stated as

Establish and maintain a process to identify and communicate newly discovered security vulnerabilities.

By applying a common vocabulary and then abstracting the control, the organization can then determine the appropriate resources to utilize to accomplish the goal, without being fettered by potentially fruitless parameters.

The control in this state can now be placed into an appropriate ontological structure. Ontologies are a rich, controlled order of semantic relationships. They allow a hierarchical structure of compliance controls based upon the relationships defined in the control activities and demonstrable outcomes. For instance, let's take the harmonized control that states the organization has to have proper policies. This control is called for by over a dozen authority documents.

Maintain full documentation of all policies, standards, and procedures that support the compliance effort

We can put this into proper context using ontological rules because we know that in order to have proper policies, those policies must follow some type of governance rules set outside of the organization. Such a control is called for by almost all authority documents.

Define external rules that govern information systems, information, and information technology

Maintain full documentation of all policies, standards, and procedures that support the compliance effort

And in order for the organization to define the rules that govern it, the organization must define the scope of its compliance framework.

Defining the scope of the organizational compliance framework and controls for your organization

Define external rules that govern information systems, information, and information technology

Maintain full documentation of all policies, standards, and procedures that support the compliance effort

In its ontological context we gain the advantage of representing explicitly not only the semantic meaning of the control, but a fluidity of being able to readily assign the appropriate resources to carry out the hierarchy of controls in context.

In our example, we know that the scope of the organization's business defines the rules to be followed which define the policies that need to be implemented. Therefore, we can make a direct correlation between the control list and the content and context of the policies. This allows the organization to

1. limit the content and context of the policies,

2. appropriately size the number of staff to support those policies,

3. apply the correct metrics for analyzing the policies, and

4. limit the audit exposure to the appropriate content and context of the policies.

In essence, we have distilled well over fifty individual authority document citations down to three easily implementable controls. Instead of establishing teams to individually support ISO, PCI, NERC, OMB, FIPS, FISMA, DoD, Security Act, FFIEC, HIPAA, COSO, NIST, and various state laws, the organization can marry teams together where appropriate and enlist only the modicum of resources necessary to support the controls in question.