Fortify on Demand assessment unit counting

Fortify on Demand is the hosted assessment service: rather than running scans on its own infrastructure, an organization submits applications to be assessed and consumes a metered allowance of assessments. Because the unit is the assessment, not the seat, an audit of a Fortify on Demand subscription turns on counting assessments correctly against the purchased allowance. Where the seat overclaim dominates on premise Fortify, Fortify on Demand assessment unit counting is the equivalent trap for the subscription: a finding can inflate by miscounting what an assessment is, double counting reruns, or sweeping in non production work.

This article explains what an assessment unit is, where the count inflates, and how a buyer reconciles consumption against the entitlement. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What an assessment unit is

The metered unit in Fortify on Demand is the assessment: an application submitted for analysis, scoped by the kind of assessment performed and, commonly, by the size or scope of the application. The subscription grants an allowance of these units over a term. Counting consumption therefore means counting assessments that fall within the scope the entitlement defines, not every action the service recorded. This consumption logic sits alongside the broader subscription considerations we set out in Fortify on Demand subscription audit considerations.

Where the assessment count inflates

A Fortify on Demand finding overstates consumption in several recurring ways. Reruns of the same application after a fix can be counted as fresh assessments when the entitlement treats them as part of one engagement. Cancelled or failed submissions can be counted as consumed units. Assessments of non production or test builds can be swept in where the entitlement scopes consumption to production applications, the same boundary we examine in Fortify non production use and license exposure. And assessment types can be conflated, with a lighter check counted at the rate of a fuller one. Each of these is a counting question the entitlement answers, not a fact the raw activity log settles on its own.

Counting against the entitlement

The defensible figure is the number of in scope assessments consumed during the term, measured against the purchased allowance. The buyer reads the subscription first to establish what counts as a unit, whether reruns are chargeable, which assessment types apply, and whether non production work is in scope. Only then is the service consumption record reconciled to that definition. This is a consumption metric rather than a headcount, closer in shape to the metered logic we describe in Fortify token based and floating license models than to a named seat count, and like every Fortify line it is established before any vendor measurement is accepted, as part of reconciling Fortify entitlements before an audit.

Reconstructing the consumption record

The buyer rebuilds the consumption position from the service records rather than from the vendor's summary. Each recorded assessment is classified: in scope or out of scope, a new unit or a rerun of an existing engagement, completed or cancelled, production or non production. The submissions driven by automation are attributed to the applications and teams they served rather than counted as additional consumers, consistent with how Fortify integration and API users are counted. What remains is the count of chargeable, in scope assessments, which is compared to the allowance the subscription granted.

A representative outcome

In a recent engagement, a Fortify on Demand finding counted every recorded submission as a consumed assessment, including reruns after remediation, cancelled jobs, and assessments of test builds. By reading the subscription to establish what an assessment unit was, then classifying each recorded submission against that definition and setting aside reruns, cancellations, and non production work, the buyer rebuilt the consumption count around chargeable, in scope assessments. The corrected figure sat within or close to the purchased allowance, and the finding settled well below its opening position, consistent with the reductions we see across Fortify matters and with our E-02 case file, where a developer seat overclaim of $4.5M settled at $0.9M.

Holding the unit definition

The discipline on a Fortify on Demand subscription is to count the unit the entitlement defines and nothing more. An assessment is not every line in the activity log; it is in scope, chargeable work measured against the allowance. Each inflation, reruns, cancellations, non production builds, conflated types, is correctable from the service records and the subscription terms, and each correction moves the finding toward the figure the entitlement supports. For the broader measurement context, see how OpenText measures Fortify usage in an audit, and for the line by line discipline, see defending a Fortify developer seat finding line by line.

For the full seat counting methodology, read the Fortify seat counting white paper.