SPSS rarely tops the list of products people expect to be audited, which is exactly why it produces findings. It is statistical software with a deceptively simple core and a long catalog of add on modules, sold predominantly on a named user basis. Teams install the base, then over time enable modules for specific analyses, and the entitlement record quietly falls behind the deployment. When SPSS appears in an audit, usually alongside Cognos or other analytics tools, the exposure is almost always in the modules rather than the seat count.
Named users and the module stack.
SPSS Statistics is typically licensed per named user: each individual authorized to run the software needs an entitlement. On top of the base, IBM sells a range of add on modules, for example advanced statistics, regression, forecasting and others, each licensed separately and each tied to the same named user basis. The trap is that a single user enabled for several modules requires an entitlement for the base and for every module they can use. Counting only the base users, or only the seats, understates the position substantially when modules are widely enabled.
Where SPSS exposure hides.
- Modules enabled beyond entitlement. Add on modules switched on for users who are only licensed for the base, the most common SPSS finding by far.
- Authorization code sprawl. Shared or reused authorization codes that put the software on more machines than the named user count supports.
- Concurrent versus named confusion. Deployments mixing license types where the rules differ, so the count is built on the wrong basis.
- Dormant but provisioned users. People who left or changed roles whose entitlements were never reclaimed, still counting against the position.
Counting modules, not just people.
The defensible SPSS count is two dimensional. You need the population of named users, and for each user the set of modules they are actually able to run. Multiply that out and compare it to the entitlements on the Passport Advantage record module by module. The result almost always differs from a naive seat count, in both directions: some modules are over entitled and can be trimmed, others are over deployed and must be addressed. Doing this before IBM completes its own count is what turns a vague module finding into a precise, negotiable number.
SPSS findings live in the add on modules, not the base seat count. The buyer side response is a user by module reconciliation: who can run which module, matched against the entitlement record line by line. That detail is what lets us challenge an inflated module claim and settle on the count the deployment actually supports.
The buyer side defense.
We contain the data request, then build the named user population and the module entitlement each user can exercise, reconciling both against the Passport Advantage record. Over entitled modules are identified, genuine module gaps are confined to the specific users and period, and authorization code sprawl is mapped and corrected. The reconciled position is carried into the negotiation so the settlement names the modules, the user count and a forward plan that keeps module enablement matched to entitlements rather than drifting again.