provided by: 
Originally published at Internet.comOrganizations are under increasing amounts of regulation which impacts IT. At the same time, IT is implementing configuration management databases (CMDBs) in an attempt to organize and manage the logical records necessary to run an effective and efficient IT organization. An opportunity exists to dovetail these two efforts in a manner that reduces confusion, improves compliance and makes audits easier. The intent of this article is to review the underpinning theory at a high level.
Despite many different definitions about what a CMDB is and how it operates, in the end it is a relational database which tracks categories of records as configuration items (CIs) in the form of tables, as well as the various data fields that enable management, reporting, and so on as attributes. In cases where there are multiple databases that are the systems of record we create a federated model that integrates the various repositories to create a unified view without damaging normalization.
This is why when you ask an experienced ITIL practitioner what are CIs vs. just attributes you get the rather infamous answer of "It depends." This is because it really does. In the world of ITIL, the CMDB is the same as any other database. The same decision making processes about tables and fields apply to CIs and attributes in the CMDB.
This brings us to controls. We often think of controls as something that can stand alone. This is reductionism at work: trying to reduce a system to its most basic parts. For example, it's like removing the heart from the body and saying "Look, here is a heart." However, for the heart to work and to matter it must be in the body and pumping. The same is true for controls.
We can look at them individually but to truly matter they must exist within the context of processes. Furthermore, we can only judge their effectiveness in the context of processes. As Ed Hill at Protiviti likes to call them, these are "IT general control processes" and they are what matter; not just the individual controls in isolation.
Just Add CMDB
Herein lies our opportunity with the CMDB. We can use the CMDB to track processes and documentation as well as the traditional hardware and software. None of this is new, but what we can do is use the CMDB to track the IT general control processes that are relevant to each system in the context of IT service and business service.
This hierarchical relationship of business service to IT service to the various component CIs that make it up allows us to relate these various elements together along with the exact control activity being performed at each level of the CI, by IT, audit findings, remediation activity, etc.
By using a CMDB populated with accurate and timely data such as described above, auditors can immediately understand what business services are impacted by what IT services, what makes up those services, the applicable IT general control processes and what is being done to comply with those processes. This can help streamline audit activity.
In addition to audit, the various groups in IT such as the data center and security folks can see how the IT general control processes apply and perform their tasks accordingly. The ambiguity is lifted as to what should be done and how.
A very important aspect is that, as the IT general control processes and the requisite documentation are in the CMDB, then they should, by definition, be governed by change management to ensure that changes are reviewed and risks managed for each of these categories CIs. This can help with approvals, versioning, communication of changes, etc.
How the CMDB is architected and the level of control information tracked must be governed by the need to be meaningful and manageable to a given organization. On one hand, we could use the CMDB to track everything. On the other hand, that is neither realistic nor cost effective. We need to make doing the right thing easy for the people performing data entry as part of their jobs.
The more difficult and time consuming it is then the more likely there will be errors, people avoiding the system, etc. This then causes the "CMDB death spiral" wherein the system is so inaccurate people don't use it. And, because they don't use it, it gets even more inaccurate, etc. The spiral repeats until the system fails. How we choose to use the CMDB to track control and audit information needs to be done with careful deliberation to ensure the value is in excess of the costs both in terms of implementation as well as the ongoing costs in production.
In closing, the CMDB can be a repository of information for operations as well as for regulatory compliance and audits. By making information about IT general control processes and specific control activities accessible, the veil of confusion can be lifted and streamline the activities of audit and IT. This will result in lower compliance costs, lower audit costs, and better managed risks, not to mention lower stress levels.
George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.
Author: George Spafford
Read article at Internet.com site