Product · BMC AMI Security

BMC AMI Security: priced on protected MSU, not on threats caught.

BMC AMI Security is licensed on mainframe MSU capacity, increasingly under zConsumption Licensing with an annual true up. The metric tracks the capacity it protects, not event volume, so the levers are the protected footprint, the consumption baseline, and the bundle it ships in.

№ 01

What it is

Mainframe securityz/OS

BMC AMI Security is the security pillar of the BMC AMI (Automated Mainframe Intelligence) portfolio. It detects and responds to mainframe security threats, identifies stolen credentials and rogue users in real time, baselines behavior to surface anomalies, and streams security events into enterprise SIEM platforms. It is positioned around compliance with regulations such as DORA and the NIST Cybersecurity Framework, and around protecting z/OS estates from ransomware and data tampering. Important for buyers: it is almost always sold inside the broader BMC AMI bundle, so its licensing has to be read in that context, not as a standalone line.

№ 02

How it is licensed

MSUzCLTrue up

BMC AMI Security is licensed on mainframe capacity measured in MSU. BMC increasingly offers it under zConsumption Licensing (zCL), a consumption model in which the charge is based on the prior year's actual z/OS MSU consumption with an annual true up on any overage, rather than a fixed full machine entitlement. Where a site has not moved to zCL, AMI Security is typically licensed on the authorized MSU capacity of the LPARs it protects. BMC has based its per MSU consumption conversion on a stated MIPS to MSU ratio for the machine models in scope, which makes the ratio applied and the consumption window used to set the baseline both material to the number.

BMC AMI Security licensing at a glance
AttributeDetail
Charge modelCapacity based, recurring; zCL consumption option
MetricMSU (protected capacity)
zCL basisPrior year actual z/OS MSU, annual true up on overage
Not priced onEvent volume, alert counts, or user numbers
Typical contextInside the broader BMC AMI bundle
№ 03

Cost drivers

Protected MSUBundle

The first cost driver is the protected MSU capacity, or under zCL the prior year consumption baseline, which can sit above what the security function actually needs to cover if it was scoped to the whole estate rather than the systems that genuinely require monitoring. The second is the bundle: AMI Security usually ships with AMI Ops, AMI Data, and AMI Storage, and a shared consumption commitment across that portfolio frequently sets the cost more than any single security line. The third is the true up mechanism under zCL, where overage in a peak year can lift the following year's baseline if the consumption window and ratio are not scrutinized.

№ 04

Audit traps

CapacityBundle

AMI Security exposure sits in the gap between protected capacity, the consumption baseline, and what the bundle actually entitles. Common traps we see at pattern level:

Where exposure hides

  • AMI Security deployed on more MSU capacity than the entitlement or zCL baseline covers after a hardware upgrade
  • Protection assumed across LPARs that the agreement scopes more narrowly
  • zCL true up driven by a peak consumption window that does not reflect steady state
  • Bundle ambiguity over which AMI entitlement covers the security function in use
  • MIPS to MSU conversion applied with a ratio that inflates the protected position
№ 05

Renewal levers

5 levers

Security is rarely cut for its own sake, but the licensing around it bends like any other capacity deal. The five levers that pay:

Buyer side levers

  • Align protected capacity: scope AMI Security MSU to the systems that genuinely require monitoring, not the whole estate by default
  • Scrutinize the zCL baseline: validate the consumption window and confirm it reflects steady state, not a peak
  • Validate the ratio: check the MIPS to MSU conversion BMC applies, since the factor moves the position materially
  • Cap the uplift: lock a firm ceiling on annual escalators and on true up exposure
  • Read the bundle: negotiate AMI Security within the AMI portfolio commitment rather than as an isolated line
№ 06

Alternatives, where credible

Reality check

Mainframe security tooling is a competitive category: BMC AMI Security sits alongside offerings from other mainframe security vendors and, for some functions, capabilities native to the external security manager such as RACF, ACF2, or Top Secret. That makes the function more contestable than a database or transaction monitor, and a credible alternative can be a genuine lever, particularly where AMI Security overlaps with controls already in place. The caution is that ripping out a deployed security monitoring layer carries operational and compliance risk, so the realistic move is usually scope discipline and bundle negotiation rather than wholesale replacement. Price the alternative honestly and hold it in reserve.

№ 07

Frequently asked

FAQ
Q1
How is AMI Security licensed?On mainframe MSU capacity, increasingly under zConsumption Licensing (zCL) based on prior year actual z/OS consumption with an annual true up. Otherwise on the authorized MSU of the LPARs it protects.
Q2
What is zCL?BMC's consumption model: pay on measured MSU utilization, reconciled by annual true up, with a stated MIPS to MSU ratio. The consumption window and ratio drive the number, so both warrant scrutiny.
Q3
Does it scale with threats or users?No. It is priced on protected MSU capacity, not event volume, alerts, or user counts. A busy security posture on a small LPAR does not by itself raise the license.
Q4
How do you cut AMI Security cost?Align protected capacity, scrutinize the zCL baseline and ratio, cap the uplift and true up exposure, and negotiate within the AMI bundle rather than as a standalone line.

The bundle and the baseline set the price.

Audit notice or renewal under 18 months out? We mobilize within 48 hours.

Security ships in a bundle. We price the whole thing.

Get expert help