What records does OpenText copy in a Fortify audit

When a Fortify audit opens, one of the first questions a buyer faces is what data actually leaves the building. OpenText gives seven days notice before an audit and reserves the right to copy relevant records, and the scope of that right is broader than many buyers expect and narrower than the audit team often implies. Knowing what records OpenText copies in a Fortify audit, and what it cannot demand, is the difference between a controlled data exchange and an open ended fishing expedition that inflates the eventual finding.

This article explains which records are typically in scope, how the seven day notice frames the request, and how a buyer controls the flow of data. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What the seven day notice actually grants

The grounding fact is straightforward: OpenText gives seven days notice before an audit and the right to copy relevant records. Two words in that sentence do the work. "Notice" means the clock starts on a defined date, and the buyer should use that window to organize rather than to react. "Relevant" means the right attaches to records that bear on the license position, not to everything the audit team might find interesting. A request that reaches beyond relevance is a request the buyer is entitled to scope down. The opening days are covered in our broader audit mechanics material, and the same discipline appears in how OpenText measures Fortify usage in an audit.

Which Fortify records are typically in scope

On a Fortify audit, the records that genuinely bear on the license position are a defined set:

• Entitlement documents. The licenses, order forms, and authorizations that define what the buyer holds and under what metric.
• User and access records. The accounts in Software Security Center and the scanner deployments, which speak to the seat count, examined in Fortify Software Security Center user counting traps.
• Scan history. Records of scans submitted and by whom, which distinguish active scanning from passive access.
• Deployment inventory. Where the software is installed and in which environments, including the non production split covered in Fortify non production use and license exposure.

What OpenText cannot simply demand

A request to copy relevant records is not a licence to extract source code, proprietary application data, or unrelated systems. Fortify analyzes code, but the license question is about who uses the tool and under what metric, not about the content of what was scanned. A buyer is within its rights to provide the entitlement, access, and scan records that establish the position while declining to hand over the scanned source itself or data from systems outside the Fortify estate. Holding that line is part of running a single controlled channel, the discipline that keeps an audit from sprawling.

Controlling the data that leaves

The practical defense is to route every data request through one channel and to reconstruct the position from the buyer's own records before producing anything. When the buyer assembles its entitlement, access, scan, and deployment records first, it controls both the content and the framing of what the audit team receives. The records arrive organized around the correct metric rather than as raw exports the vendor can interpret to its advantage. This reconstruction is the heart of reconciling Fortify entitlements before an audit.

Why the records framing decides the finding

How records are produced shapes the number that comes back. A raw export of every account in Software Security Center invites the audit team to count every account as a consumer. A produced record that distinguishes active scan submitters from passive readers, service accounts, and disabled users invites a far smaller count. The data is the same; the framing is not. This is why a buyer reconstructs before it produces, a point developed in defending a Fortify developer seat finding line by line.

A representative outcome

In a recent engagement, an audit opened with a broad records request that would have handed over every account and every scan log as an undifferentiated export. By scoping the request to relevant records, producing entitlement, access, and scan history organized around the actual seat metric, and declining to extract scanned source code, we kept the data exchange controlled and the finding anchored to a defensible count. The matter settled well below its opening position, consistent with the reductions we see across Fortify engagements and with the path our E-02 case file followed, where a technology company brought a developer seat overclaim down by 80 percent.

The discipline in one line

Relevant records, produced through one channel, organized around the correct metric, with everything outside that boundary declined. That is how a buyer answers what OpenText copies in a Fortify audit without surrendering control of the data or the narrative. For the wider measurement context, see can OpenText count repository readers as Fortify users, and to set up a controlled channel from day one you can open a case with our team.

How the four Rs shape the records exchange

The records question is decided in the respond stage of our method, across the first seven days. That is when the buyer establishes a single controlled channel, scopes the request to relevant records, and sets the terms for what will be produced and how. The reconstruct stage then assembles entitlement, access, and scan records into a position organized around the correct metric, before any vendor script runs. By the time anything is produced, the data has been framed by the buyer rather than interpreted by the audit team. The rebut and resolve stages build on that controlled foundation, which is why getting the records exchange right at the outset matters so much to the eventual number.

Holding the single controlled channel

A controlled channel is the practical mechanism that keeps a records request from sprawling. When every request and every production flows through one point, the buyer can track what has been asked, what has been provided, and what falls outside relevance. Side conversations in which a well meaning administrator hands over a raw export are exactly how findings inflate, because the data arrives without framing and the audit team supplies its own. Routing everything through one channel is not obstruction; it is the discipline that ensures relevant records are produced accurately and that irrelevant data stays where it belongs.

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