Are you happy that your organization is fully compliant from a software licensing perspective? Do you feel comfortable that all the right checks and balances are in place, with nothing to fear from a software vendor audit? If so, then what about putting this to the test by inviting in a software vendor to stress test your capabilities? Please read on to understand more.
Now that you’ve picked yourself up off the floor, I’ll continue. While this idea might seem sheer lunacy to start with, it actually makes a lot of sense. That by targeting a particular software vendor, and their offerings, you’re able to stress test your IT asset management (ITAM) and software asset management (SAM) capabilities. From the accuracy of your license compliance calculations to your ability to respond in an efficient manner when software vendor audits occur (usually out of the blue).
Before I go any further, it’s worth stating that this isn’t an ITAM or SAM best practice. It might not even be an ITAM common practice (but hopefully you can help to establish this by responding in the comments section below). It’s an idea offered up to help improve your organization’s ITAM capabilities.
There are, of course, risks and potentially unwanted side effects of taking such an action:
But are these any different from an unexpected software audit happening?
Your organization has invested time and money in creating ITAM capabilities and hopefully believes that it has put in place the right people, processes, and technology for an effective ITAM program. But has it ever:
One could argue that: “None of the above is necessary because we never get audited.” However, extending such logic would also lead to: “We don’t need to buy licenses for all our software installs because we never get audited.” Which hopefully most organizations aren’t foolish enough to do.
With a different, but still logical, point of view being that if an organization is happy with its level of ITAM maturity, then it should be able to cope with a software vendor audit (and the requirements it brings). But it will never truly know until it is audited.
Of course, an organization could undertake internally-resourced audits and/or (maturity) assessments; and might have to from a regulatory-compliance perspective. Or it might pay for third-party resource to do something similar – the benefit of course being that it’s done behind closed doors. But this benefit only stands, versus an invited software vendor audit, if the vendor were to publicize the results (and these would need to be newsworthy for that) or adversely punish non-compliance beyond the making-good of license deficiencies.
Is the idea of inviting a software vendor in to audit your organization growing on you yet?
The concept of using real-world scenarios to test the robustness of IT’s capabilities is not unheard of, with a popular example being the Chaos Monkey tool created by Netflix to test the resilience of its infrastructure. Or the invocation of business continuity/disaster recovery plans on an annual basis to ensure that they’ll work as and when the need to deploy the plans (and the continuity resources) arises for real.
Outside of IT, there are risk management/mitigation practices where unwanted situations are prevented or minimized (in terms of impact) through the instigation of a controlled version of the unwanted situation. For instance:
So how different is requesting a software vendor audit?
So, think of the inviting of a software vendor to conduct an audit as being a similarly controlled version of an unwanted situation. Where your organization is better able to control that situation and has a higher probability of being prepared for it and succeeding as a result.
It’s a test not only of whether your agreed and documented ITAM practices, with their embedded internal controls, are being actioned as they should be (after all, how often does real-world activity differ from prescribed processes). Such that ongoing compliance can be assured with a high degree of probability.
It’s also a great way of testing your audit capabilities, identifying improvements where they’re necessary. From the fleetness of foot in responding to vendor requirements for evidence and other data/information in their desired format(s). Through to how staff behave in the context of a vendor audit. For instance, complying with ITAM policies that dictate who can talk with whom, disclose information, etc.
Plus, it also tests the ability of any ITAM technology your organization employs.
To conclude, I’d like to use a couple of sports analogies.
Firstly, most sports teams fare better playing at home than they do while on the road. In the case of instigating a vendor audit, it’s not the same as having “home advantage” but it’s a similar concept of removing unknowns and exploiting the knowns.
Secondly, in sports such as boxing (where the number of professional bouts is limited), it’s unlikely that a successful fighter will take on the biggest and scariest opponent first. Instead they’ll work their way through a number of less-risky opponents first. The same concept applies here – your organization can start with software titles and a vendor where there’s a lower risk of non-compliance and potential financial exposure (because of non-compliance). Thus, preparing itself for the bigger, and potentially riskier, bouts that lie ahead.
So, what do you think about inviting a software vendor in to audit your license compliance and ITAM capabilities? Is it madness, or can you see the potential for using it as a platform for assurance and potentially improvement? Please let me know in the comments.