Using the CMDB to Manage Controls

Organizations 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.