Broadcom Audit Scope: How to Limit It

Every Broadcom audit begins with a scope. The auditor proposes one, the contract permits another, and the customer's exposure sits in the gap between the two. In our experience across more than two hundred and eighty Broadcom and legacy VMware audit engagements, the single most common reason a customer pays an inflated settlement is not that the customer was egregiously non-compliant. It is that the customer allowed the auditor to expand scope into territory the contract never authorised, and then was held responsible for findings produced inside that expanded territory.

Scope, in the Broadcom audit context, has four distinct dimensions: product scope (which licensed products the auditor may examine), entity scope (which corporate entities, subsidiaries, and affiliates fall inside the audit perimeter), environmental scope (which deployments, sites, business units, and clouds), and temporal scope (which audit period and look-back window). Auditors routinely propose maximums on all four. The contract almost never authorises maximums on all four. The customer's job in the first six weeks of an audit is to put each dimension back inside its contractual envelope before fieldwork begins.

Read the audit clause before you read the audit notice

The audit clause in your master agreement is the only document that defines what an audit may examine. Most enterprises have never reread it after signing. The clause typically runs four to nine sentences and governs whether an auditor may visit your premises, what data they may request, which entities they may examine, how often they may audit, who pays for their work, and what remedies apply if non-compliance is found. Every one of those points is a scope boundary.

Read the clause carefully and write a one-page memo to yourself before you respond to the audit notice. The memo should answer eight questions in plain language: Who is the contracting customer? Which affiliates are covered? Which products are covered? What is the audit frequency limit? What notice period is required? What confidentiality obligations apply? What remedies apply? And what does the clause say about the auditor's working methodology? When the audit notice arrives, the gap between what the notice claims and what your memo records is your initial scope-limitation worksheet.

Product scope: do not let new products join the audit mid-stream

Auditors frequently expand the product list during fieldwork. A VMware vSphere audit becomes a vSphere plus vSAN audit. A vSphere plus vSAN audit becomes a VCF audit. A VCF audit becomes a VCF plus NSX plus Aria audit. Each expansion happens informally, often via a data request that asks for usage information on a product the auditor was never engaged to examine.

The contractual rule is that the auditor may examine products you have licensed under the agreement that authorises the audit. Products under separate agreements, products you have never licensed, and products that are bundled into a SKU you have licensed but which you do not deploy are not automatically in scope. The auditor's claim to the contrary usually rests on the argument that an installed binary equals a deployed product equals an audit-eligible product. This is wrong on at least two of three steps. An installed binary is not a deployed product if it is not in use, and a deployed product is not audit-eligible if it is not licensed under the agreement being audited.

The practical move is to confirm the product scope in writing during the kickoff meeting, list the products by name and SKU, and refuse any data request that pulls usage data on products outside that list. If the auditor wants to expand scope, that is a contractual amendment, not a unilateral right.

Entity scope: which legal entities are actually audited

Large enterprises operate through dozens or hundreds of legal entities. Subsidiaries, affiliates, joint ventures, recently acquired companies, recently divested companies, foreign branches, and dormant shell entities all create scope ambiguity. Auditors gravitate toward the broadest possible reading: any entity the parent controls is the customer for audit purposes.

The contract almost never supports this reading. The audit clause names a contracting party, sometimes extends to wholly owned subsidiaries, occasionally extends to controlled affiliates, and almost never extends to acquired entities for periods before the acquisition closed. Each carve-out matters. A target acquired last year that ran an unsupported, unlicensed VMware estate before the acquisition is usually not in your audit scope for the pre-acquisition period, regardless of how aggressively the auditor pursues the data.

The acquired-entity question

If you have completed an acquisition in the last three years, treat the acquired entity's pre-acquisition VMware position as a discrete legal question. The acquiring party's audit obligations under the master agreement typically apply only from the date the acquired entity was integrated under the master agreement, not retroactively. There are exceptions for fraudulent transfer and successor liability, but those are rare. Have counsel write the carve-out into the audit-period acknowledgment.

The divested-entity question

If you have divested an entity, the question reverses. The divested entity's deployments after the divestiture date are not your audit responsibility, but auditors will frequently include them in usage totals if they are still using shared infrastructure. Establish the divestiture date in writing and exclude all post-date deployments from the in-scope dataset.

Environmental scope: keep the auditor out of irrelevant environments

VMware deployments rarely live in a single environment. Most enterprises run a mix of on-premises data centres, colocation facilities, dedicated cloud regions, public cloud nested virtualisation, disaster recovery sites, lab environments, development environments, and acquired environments. Each is a different scope question.

Production environments under the master agreement are obviously in scope. Lab and development environments are usually in scope if they use licensed binaries, but the methodology applied to them should reflect their actual usage pattern, not assume continuous production-grade utilisation. Disaster recovery environments are governed by separate contractual language and often qualify for cold-standby or hot-standby licensing exceptions that auditors disregard unless raised explicitly. Public cloud nested deployments are sometimes covered by a separate VMware Cloud agreement and sometimes by hyperscaler terms that override the master agreement.

The most important environmental boundary is the one between your environment and a managed service provider's environment. If a third party operates VMware on infrastructure you do not control, the licensing obligation may rest with the service provider under their Cloud Services Provider Program licensing, not with you. Auditors often miss this distinction and bill enterprise customers for usage that contractually belongs to the service provider.

Temporal scope: how far back the audit can look

The audit period is the time window the auditor may examine. The default position auditors propose is the longest period the contract permits, typically thirty-six months from the audit notice date. Some master agreements allow only twenty-four months. A few allow only twelve months. None of the standard VMware enterprise agreements allow unlimited look-back, but auditors sometimes write data requests as if they did.

The temporal scope conversation has three live issues. First, the look-back window itself, which should be confirmed in the kickoff record. Second, the cut-off date for the audit, which is normally the audit notice date, not the report date — usage that grows during the audit itself should not be added to findings. Third, the treatment of expired or terminated entitlements, which auditors sometimes count against later-period deployments even when the entitlement was contractually valid at the deployment date.

Data requests: scope in disguise

The auditor's data request is where scope is usually expanded in practice. A request that asks for "all VMware deployment data across all entities for the last five years" is a scope claim disguised as a data request. Customers who provide the data without negotiating the request first have effectively accepted the implied scope.

Treat every data request as a scope document. Map each field in the request to the agreed scope memo. If a field falls outside the agreed scope, reject the field, not the request. Auditors will often accept narrower data without renegotiating the overall data request, particularly if the customer cites the kickoff record as the basis for the narrower delivery.

The categories most frequently overreached are: usage data on non-licensed products, deployment data from non-covered entities, lab and development utilisation data treated as production, historical usage data outside the agreed look-back window, and configuration data that goes beyond what is needed to verify entitlement use (for example, full architecture diagrams of unrelated systems).

Methodology challenges as scope tools

Methodology and scope are linked. An auditor with a broad methodology can convert narrow scope into broad findings by, for example, calculating per-CPU usage at peak rather than average, or by counting every powered-on virtual machine regardless of actual workload. Methodology challenges are scope challenges in disguise.

The most consequential methodology challenges in current Broadcom audits include: the conversion of perpetual entitlements into subscription-equivalent units (which is a pricing question, not a compliance question); the treatment of disaster recovery and cold-standby workloads; the per-core licensing application to vSphere environments licensed under earlier per-CPU terms; and the treatment of nested virtualisation and container workloads, where methodology is genuinely unsettled and customers retain reasonable arguments.

The kickoff is your scope-defining moment

The kickoff meeting is the single most important scope event in a Broadcom audit. Most of what happens in the next ninety to one hundred and eighty days is determined by the scope record produced in the kickoff. Customers who treat the kickoff as a formality consistently end up litigating scope in the middle of fieldwork, when the auditor's position has already hardened.

Prepare for the kickoff by writing a four-section pre-read for your own team: the contractual audit clause verbatim, the entity list with carve-outs, the product list with SKU-by-SKU notes, and the proposed look-back window. Present these positions at the kickoff in clear language. Ask the auditor to confirm each in writing. Treat any divergence between the kickoff record and the auditor's later positions as a renegotiation, not a refinement.

What never works

Three scope-limitation strategies fail almost every time. The first is silent refusal — declining to engage with the auditor until they propose narrower scope. Auditors interpret silence as an opportunity to expand scope unilaterally, and the contract gives them more procedural leverage than customers usually expect. The second is informal scope deals that are not documented. Auditors rotate staff, and a verbal agreement with a junior auditor in week three has no force in week sixteen when a senior auditor revisits the question. The third is using legal threats as the primary scope-limitation tool. Threats sometimes work but they almost always damage the commercial relationship that you will need to manage during settlement and renewal.

What does work

Three approaches do work consistently. The first is what we have already described: a written scope memo grounded in the contract, presented at kickoff, and confirmed in writing within two weeks. The second is data-request discipline, where every request is mapped to the scope memo and overreaching fields are rejected by reference to the memo rather than to general principle. The third is methodology-challenge sequencing, where the customer raises the most defensible methodology challenges early in fieldwork so they are on the record before the auditor builds findings that depend on contested methodology.

Combined, these approaches typically reduce the in-scope universe of deployments by twenty to forty per cent before fieldwork even begins, which in turn reduces final findings by a similar or larger margin once methodology challenges are applied. The headline number on the eventual settlement is mostly determined in the first six weeks of the audit, not in the negotiation at the end.

The customer's standing question

One question worth asking explicitly, because almost no customer asks it: does Broadcom actually have the right to audit, here, now, in this form? The right derives from the master agreement, and master agreements have been amended, assigned, terminated, and replaced over the years that VMware, Symantec, and CA Technologies products have been in customer environments. Broadcom inherited contracts via acquisition. Not all of them clearly authorise the audit Broadcom is asserting. Where the underlying authority is weak, the entire scope conversation changes.

This is not a question to raise lightly, and not a question to raise without counsel. But the standing question is real, and in a meaningful minority of engagements it produces a path to a much narrower audit, or no audit at all.

Related reading

If you have not already, read our companion guides on the Broadcom audit process, responding to the audit letter, and Broadcom's contractual audit rights. Together these articles cover the procedural framework inside which scope is contested.