In this article we share some of the key insights obtained from our IBM software audit defense experiences in 2021
2021 has again been a very active year with regard to IBM software audit defense projects for ITAA. After the temporary reduction of audits in 2020 we see IBM customers increasingly receiving “Software License Review” (audit) notification letters. Some audit pitfalls remain the same while others are new.
Full capacity risk
This topic may be familiar to experienced IBM license management professionals, however we still see many customers facing audit reports based on full capacity licensing, which can lead to significant compliance exposure. Even customers that have installed and deployed the IBM license metric tool (ILMT) are often told they have not met the requirements for sub capacity licensing due to inadequate ILMT configuration or coverage. It is important to remember that, even in these circumstances, IBM will usually be willing to reach a settlement closer to the sub capacity license position value. In order to achieve the optimal settlement it is essential to identify and document all arguments and corrections that can be used to mitigate the reported shortfalls, including arguments and corrections that are not related to sub capacity licensing. The better and more convincing those arguments are, the more favorable the settlement will typically be. Using this approach we have helped many customers, including customers with compliance exposure exceeding $200M, settle for less than 5% of the initial compliance shortfall value in 2021.
IASP (IBM Authorized Software Asset Management) program
A new development in many audits is that IBM increasingly pitches the IASP program as a way to avoid an imminent software audit or as a way to reach a favorable settlement at the end of an audit. ITAA increasingly receives questions on the merits and drawbacks of the IASP program. Every customer should weigh these based on their specific circumstances, but in general we have found the following benefits and drawbacks to be applicable to most IBM customers:
- Predictability: By reviewing the compliance position on a quarterly basis there is less risk of a large unexpected compliance exposure in any given quarter after the first one.
- Expertise: The IASP partners have the required expertise which a customer may not have in-house, in particular with regard to ILMT and the sub capacity requirements.
- Leniency: The IASP agreement includes some terms which allow “accidental” software installations to be removed without cost, within certain restrictions.
Another benefit often stated with regard to the IASP program is that any information received by the IASP partner is treated confidentially and will not be shared with IBM. However, in our view the value of this arrangement is limited since the client must report any compliance shortfalls to IBM as part of the IASP agreement as well as the general terms and conditions. Some customers cite a lack of back Software Subscription and Support (S&S) charges as a potential reason to choose the IASP program. However, when proactively measuring your compliance position and ordering new licenses such charges are not due. Even in audits such charges are often dropped as part of the settlement negotiation.
Downsides / risks
- Cost: The IASP program is paid for by the IBM customer (as opposed to software audits, which are paid for by IBM).
- Conflict of interest: Even though the IASP partner will be paid for by the customer, those same partners depend on IBM for a significant amount of business, e.g. through the IASP program itself as well as the IBM software audit program (KPMG / Deloitte).
- Control: By giving continuous transparency to the IASP partner and IBM on your IBM compliance position, you are also ceding some control over your commercial relationship with IBM. For example, if the customer decides to significantly reduce their IBM software footprint/spend, this will become clear to IBM quickly and they may take corresponding action.
- Long-term relationship: In the short term, IBM has stated that their goal with this program is customer satisfaction. However, IBM’s priorities might change over time to value revenue over customer satisfaction. The IASP partners are IBM business partners so they may be pressured by IBM to adopt certain new policies.
Although not entirely new, we see the compliance risks related to having IBM software with processor-based licenses installed on legacy operating systems (OS) materializing more frequently at our customers.
In 2021 ITAA provided software audit defense support to an IBM customer who was facing significant exposure as a result of a license compliance audit. The $16M exposure was caused by IBM software installations on Windows 2008 being calculated at full capacity even though those installations were being scanned by ILMT. By leveraging specific circumstances and deployment details at this customer we were able to eliminate this risk entirely, however there is no one-size-fits-all solution to resolve this issue.
Our recommendation is therefore not just to continuously review ILMT reports for legacy OS, but also to proactively identify OS which may be withdrawn from support in the future. For example, even though Windows 2012 is currently eligible for sub capacity licensing, Microsoft has announced the end of Extended Support as October 10, 2023. This means that, assuming a 6 month grace period, IBM may remove sub capacity eligibility for this OS in Q1 2024. This date may seem far away today, however upgrading operating systems or migrating server applications can be a very lengthy and complicated process in large organizations. By identifying such risks in advance, there is more time to implement mitigating measures such as reconfiguring virtual machines so that the full capacity PVU value is minimized.
Scoping the IBM software audit and selection of audit data sources
Although the early audit stages may sometimes appear like formalities in preparation for the actual audit procedures, it is critical to ensure that both the audit scope as well as the data sources for the audit are carefully considered to ensure the optimal audit outcome. The goal should be to avoid any unreliable, inaccurate data from being shared with the auditor which can be subject to multiple interpretations. Instead, the goal should be to share a minimal set of data that ensures a complete and accurate overview of the compliance position. For example, in our experience running auditor scripts on all machines (which is often the preferred approach by the auditor) may sometimes streamline initial data collection but will often lead to a high number of false positive installations being included in the results. Data source selection and vetting is therefore an essential step in audit preparation.
In 2021 we were approached to provide IBM software audit defense services at the very end, when the audit report presented license shortfalls worth $80M based on sub capacity licensing and $265M at full capacity licensing. Based on our initial review of the draft report we concluded that over 95% of these risk values were caused by an unreliable software discovery data source that reported many IBM software installations that did not in fact exist. In the end we were able to help the customer eliminate these false positive findings, but not before many months of arduous technical discussions in which we needed to gather additional technical evidence to refute the initial conclusions.
Another customer we worked with in 2021 engaged us from the very beginning of the IBM software audit. We helped this customer to negotiate an audit approach where a single (reliable) source of truth would be used to collect all necessary software discovery data, combined with basic sample testing procedures to validate the completeness and accuracy of the data source. This approach lead to an audit report with zero license shortfalls, allowing the customer to reassign their $2M audit risk reservation back into the internal organization.
These examples show that diligently scoping the audit, as well as mapping out the trustworthy sources and processes to be used throughout the audit, can help to minimize the effort during the audits as well as minimize false positive findings which can be challenging to counter during the audit reporting phase.
In contrast to the previous topics, this is one we do not yet see as being a main focus during IBM software audits. However we increasingly see customers ask about containerization and the IBM licensing rules surrounding it. We’ve dived into this topic with many of our customers and there are many aspects to consider. A few key takeaways are:
- Contractual arrangement: Before implementing container licensing make sure to sign the Addendum – Special Option for Container Licensing Terms. In the future the Passport Advantage terms are expected to be updated to include the Container licensing terms, at which point signing a separate addendum will no longer be required.
- Tools: Similar to sub capacity licensing and ILMT, the use of the IBM License Service tool is mandatory in order to benefit from container licensing. Make sure to plan, implement and set up regular reporting through this tool prior to deploying IBM products using container licensing. Also, for hybrid environments where a product is installed on both container as well as non-container machines it’s recommended to implement report aggregation from both environments, for example using the IBM License Service Reporter tool.
- Keep track of developments: This is a relatively new area and IBM is likely to change the terms and requirements of container licensing in the future.
Another aspect that can be useful to consider is that Cloud Pak licenses, which are marketed for use in cloud and container environments, can also be used on premise and flexibly allocated to a range of products and license metrics rather than a single product. Allocating Cloud Pak licenses can be a complex task, but doing so wisely can sometimes mitigate audit risks or help achieve a more optimized audit settlement outcome.
ITAA’s IBM software audit services
For many organizations preparing for an IBM software audit may be low on the list of priorities given that there are often more pressing IT issues to address. ITAA can provide guidance not just on how to prepare for and manage an audit, but also on how to minimize the business impact while doing so. It may be that you can relate to the situations outlined in the article and would like support in defense of an IBM software audit. Please feel reach out to our IBM vertical lead Koen Dingjan (email@example.com) whether you have questions on any of the topics in this article, would like ITAA to perform an IBM license compliance maturity check for your organization or would like help with IBM software audit defense.