An audit is an investment for IBM, so it points its compliance effort where the expected return is highest. That makes audit selection more predictable than it feels from the receiving end. The same handful of signals comes up again and again, and several of them are things buyers do to themselves. Understanding which behaviors raise your profile lets you decide which risks to retire and which to manage deliberately.
Audits are selected, not random.
The unsettling part of an audit notice is the sense that it came out of nowhere. It rarely does. IBM's selection leans on account history, product mix, purchasing patterns and support activity, all of which it can see. A buyer who treats audit risk as bad luck cannot manage it. A buyer who treats it as a function of visible signals can lower the signals and, with them, the odds.
The triggers IBM acts on.
The recurring triggers fall into a short list:
- Support and subscription non renewal. Dropping S&S on a product while continuing to run it is a classic flag. It suggests use without current coverage.
- Time since the last audit. Three or more years without a review makes an account a candidate simply because drift accumulates over time.
- Heavy use of high risk products. Large estates of WebSphere, Db2, Cognos, MQ, Maximo and Tivoli draw attention because their licensing is complex and sub-capacity is easy to get wrong.
- Requesting support for an unlicensed product. Opening a support case for something that does not appear in your entitlements tells IBM exactly where to look.
- Bundling misuse. Using a component beyond its allowed scope, such as a database bundled with another product pressed into wider service, is a frequent finding.
The self inflicted triggers.
Several triggers are entirely within your control. A support ticket raised for an unlicensed product is a self report. Letting S&S lapse on software you still run is a paper trail that points at itself. Mergers and acquisitions create another, because licenses do not always transfer cleanly and an acquirer can inherit deployments that no entitlement covers. Each of these is avoidable or manageable with attention before it becomes a notice, rather than after.
How to lower your profile.
Prevention is mostly hygiene done before anyone is watching:
- Keep deployment mapped to entitlement for the high risk products, continuously rather than once a year.
- Maintain a defensible sub-capacity posture so the products most likely to draw an audit are the ones you can prove.
- Be deliberate about support cases on anything whose licensing is uncertain, and resolve the entitlement question first.
- Handle S&S decisions knowingly, understanding that non renewal on running software is a visible signal.
- Treat M&A as a licensing event, reconciling inherited estates rather than assuming the rights came with the assets.
None of this guarantees you are never selected. It does mean that if the notice arrives, it lands on a position you have already built rather than one you have to reconstruct under pressure.