One of the most critical parts of a configuration management system is to keep track of changes. Fundamentally that importance comes from two areas. The first is operational safety. Being able to trace back your steps, when (not if) something goes wrong, is crucial. The other reason are legal requirements like SOX (Sarbanes-Oxley Act).
For the implementation there are basically two ways:
- Feed the configuration management with data that are already audited.
- Have the configuration management system do the audit itself.
The first approach will usually involve a Version Control System like Git or Subversion. This has the huge advantage that it is already established in the organization and its processes. It also means that dependencies between a certain configuration item and the code that makes use of it are implicitly covered. In other words: If you check in your code change, make sure to include all relevant changes to configuration items and everything will work.
That sounds great, doesn’t it? No additional tools, processes, or organizational challenges to deal with and everything works by definition. Unfortunately life is not that easy. Here are just a few areas where this approach falls short:
- Emergency changes: If every seconds counts to fix something, you don’t want to wait even for the best CI/CD pipeline in the world. If you have the latter, that is.
- Non-developers: You typically have people involved in changing configuration details who are no developers. Good luck teaching someone Git just for performing a small configuration change.
- Separate process: It is more than likely that some configuration changes (although not an emergency) need to happen outside of the normal deployment cycle. It may be an option in your organization to just adjust the deployment. But what if that is not an option?
- Approval process: If you have an approval process, hopefully implemented in some kind of workflow tool, how do integrate that with your Version Control System or CI/CD pipeline?
- Security: You typically have different rules and people involved for production systems vs. earlier stages (especially development). Quite often it is therefore not even allowed to have certain values under version control.
The list above, although certainly not complete, should be more than enough to convince you that relying only on something like Git is not a great idea.
So the configuration management needs to support auditing by itself as well. The detailed functionality can, to an extent, be derived from the aforementioned situations. So whenever a certain requirement or situation does not lend itself (well) to be dealt with by a Version Control System, that is already a candidate.
As a minimum the delta of every change needs to be saved, together with relevant metadata. So the old and new value, the user that performed the change, the IP address from the change originated, etc. In addition it should be possible to provide some kind of information as to why the change was done. The rational is the critical aspect here. Because we can automatically capture the old and new value(s) with much more precision than what people will usually enter. But to know the intent behind the change is really important.
If required, and you should assume that this will come up sooner or later, it should be possible to connect the audit with a GRC system (Governance, Risk Management, and Compliance) or legal frameworks like the aforementioned Sarbanes-Oxley Act.
But the possibility for integration should not be limited to GRC systems. Ticket systems like JIRA and workflow tools are just as important. And with proper APIs only your fantasy will limit the options. Experience teaches us that customers have always many more idea for connecting software than the developers who build it. So to not only have specific integrations (which are usually very comfortable to use) but a generic way for connecting is crucial.
That’s it for today. I am aware that there is a lot more to this subject than what I have covered. But I wanted to start with the fundamentals first and take it from there.
If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.
© 2024, 2025 by JahnTech GmbH and/or Christoph Jahn. No unauthorized use or distribution permitted.
One Response
Good one Jahn .
I completely agree that a robust configuration management system should support auditing by itself and capture not only the changes but also the intent behind them. Your mention of integration possibilities with GRC systems, ticket systems, and workflow tools highlights the need for flexibility and adaptability in such systems.
Overall, this article serves as an excellent foundation for understanding the fundamentals of configuration management, and I look forward to reading more on this topic in the future