Configuration Management How To (Part 3)

Following on from our previous articles on Configuration Management, this week we’ll be taking a look at Status Accounting and Verification.

Status Accounting


Status Accounting is the part of the process responsible for recording and reporting the lifecycle of each configuration item; essentially making sure that each CI has a valid lifecycle status, accurately recorded in the CMS. The thing to remember about status accounting is that you can have all the statuses (statusi?) in the world but if you have too many, it will be a nightmare to maintain your data. Again, my advise would be to start small and then build up over time as your process matures. Some example Configuration Management statuses could include:

  • Purchased
  • In Test
  • In Pre production
  • In production
  • In repair
  • Spare
  • Disposed

Status Accounting ensures that all CIs that make up the service baseline or snapshot have been captured and that all Changes have been captured by Change Management and reflected in the CMS. I would also make the case that if a Change has failed or a planned Release CI has defects, then a Known Error (with a workaround if appropriate) should be raised and linked within the CMS.

Automated discovery tools make it easier to manage your estate; they can do in hours what it would take people days or even weeks to complete. If you don’t have a dedicated asset discovery tool could you use an existing tool such as SMS or Alteris (commonly used for deploying software releases)?

Verification & Audit

16811751576_ba60a74652_z (1)

Our final part of the Config process is to look at the activities responsible for ensuring that information in the CMS is accurate and that all configuration items have been identified and recorded.

Verification includes routine checks that are part of other processes – for example, verifying the serial number of a desktop PC when a user logs an Incident or checking that the version of software updated in a planned Change has been added to the CMS.

Audit is a periodic, formal check. Configuration audits generally include the following activities:

  • Defining audit schedule and procedures
  • Identifying who will perform the audits
  • Performing audits on the established baselines
  • Generating audit reports
  • Managing exceptions
  • Lessons Learned

When defining an audit schedule look to the rest of the business for guidance. Do you have any regulatory requirements such as SOX, BASEL 3, IL3 or NGN224 or any standard s such as ISO 20000 that need to be adhered to? If so, they will probably come with a defined audit cycle. When preparing for external audits, the best thing you can do is run an internal audit first so that you can correct any potential issues or at least come up with a plan to improve in the case of any major findings. Ideally, get someone from outside your department to carry out the audit as they will have a fresh perspective and there will be no room for bias (however unintentional).

Configuration audits will include a mixture of automated and physical checks on established service baselines. Once complete, the audit report will be generated summarising the results of the audit and highlighting any differences between the CMS and production CIs. In the event of discrepancies, a get well plan should be planned and acted on as soon as possible, perhaps with the support of your Problem Management team to understand the root cause and suggest actions to prevent further discrepancies. I would also suggest keeping a lessons learned log for Configuration Management and ensuring that it is updated and acted upon following all audit activity.

That’s our take on Status Accounting and Verification & Audits – what do you think? Let us know in the comments!


Image Credit
Image Credit