Cloud Pak for Security and SOAR licensing.

Cloud Pak for Security, now folded into IBM's broader security and threat management line, was built to run as a containerized platform on Red Hat OpenShift. That architecture decides how it is licensed. The platform and its modules, including the SOAR capability that came in through the Resilient acquisition, are entitled in Virtual Processor Cores, the VPC metric that IBM extended sub-capacity and ILMT style reporting to under Passport Advantage v11. Manual core counting is no longer permitted for VPC products. The count comes from approved reporting, and approved reporting is where audits land.

What makes this product family tricky is that the capabilities can be licensed separately. The threat investigation and data explorer functions, the case management and SOAR orchestration, and any add on connectors can each carry their own entitlement. An estate that bought the platform for one use case and grew into others can be running modules it never counted, and an auditor will count every module that is deployed and reachable, not only the one the purchase order named.

How it is licensed

The unit is the Virtual Processor Core. You entitle the VPCs consumed by the Cloud Pak software running in the cluster, and because this is a VPC product, the count must come from the IBM License Service reporting in the container platform rather than from a manual tally. The SOAR capability, where licensed as its own part number, is counted on its own basis, so a deployment that runs both investigation and SOAR has to entitle both. The platform sitting on OpenShift also implies an OpenShift subscription underneath, which is a separate obligation entirely.

• Platform and modules metered in Virtual Processor Cores
• SOAR and case management can carry their own entitlement lines
• VPC requires License Service reporting, not manual counting
• The OpenShift platform underneath is a separate subscription

The audit traps

The first trap is the reporting gap. VPC sub-capacity depends on the License Service running continuously and its reports being retained, exactly as container reporting works for any Cloud Pak. A gap reverts the affected period to all cores in the cluster, and a security platform often runs on a sizable cluster. The second trap is module sprawl, where capabilities switched on during a proof of concept stay live and uncounted. The third is the boundary confusion between the Cloud Pak VPC count and the OpenShift subscription, where buyers entitle one and assume it covers the other.

How we defend it

We map the deployment module by module, establishing which capabilities are genuinely in use and which were trialed and left running, because an honest inventory often narrows the count before any dispute. We confirm the License Service reporting history so the VPC count holds at sub-capacity, and where reporting lapsed we scope the exposure to the affected window rather than the whole audit period. We keep the OpenShift subscription question separate so a single finding does not get double counted across both layers, and we fold any genuine forward need into the settlement.