Posted: Thu Aug 09, 2007 1:15 am Post subject: Why Perform Config Management Audit
I am preparing a management report that will act as a means of explaining to every one in IT department whay we perform Config Management audits.
While I personally know the reason for performing such audits, would anybody help me point to a few points that describes why such an audit should be performed?
Posted: Fri Aug 10, 2007 10:05 pm Post subject: Why audit? Well, what if you don't?
The OGC manual is very clear on audits:
"The configuration audits should check in addition that Change and Release records have been properly authorised by Change Management and that implemented Changes are as authorised. Configuration audits should be considered at the following times:
1. Shortly after implementation of a new Configuration Management System
2. Before and after major changes to the IT infrastructure
3. Before a software release or installation to ensure that the environment is as expected
4. Following recovery from disasters and after a "return to normal"(This audit should be included in the contingency plan)
5. at random intervals
6. In response to the detection of any unauthorised CI's
7. At regular intervals
There you have it. Ofcourse, OGC is best practices and mind the word "should be considered". But, lets see what happens if you do not audit. Any idea on how your CMDB performs? Is it 80% accurate, or 90% or maybe even 30%. Do you get a lot of incidents as result from changes that have not had a proper impact analysis? Does it cost a lot of time to recover those "errors"?
The question is not "do I have to audit?" But "how am i going to perform an audit in an efficent way?".
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sun Aug 26, 2007 4:02 pm Post subject:
Your management, if they're like most management, won't care about what the OGC has to say or why IT thinks you should be auditing your configurations.
Very simply, in order to make it worth "their" while, you will need to break things down in terms of concepts they will understand. I recommend you use drivers such as:
- Minimization/Reduction of Costs associated with poor quality of work
- Risk of poor corporate brand perception, based on customer and market interpretation of corporate capability
- Minimization of labor execution costs through proof of automation
- Proof of control over inventories to ensure optimized spend and appropriate depreciation
The truth is that if you're a mature enterprise, you will have automated most of your processes for things like builds (excluding physical infrastructure), deployments, installations, instantiations, executions, rollbacks, administrative monitoring, etc. Each piece of any one of these processes should have "expected configurations" that can be compared to "actual configurations".
Remember, your leaders think in terms of "money", not "IT". And, to most leaders, IT is an expense. Therefore, focusing on what's important to them will help them understand the need for it. If you focus on what's important to you, your team, or the OGC, you run a strong risk of not getting the support you will need from your leadership.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum