Broadcom Audit Data Collection Methodology

When a Broadcom audit begins, the most consequential decisions are often made in the first few weeks — and they're rarely about money. They're about data. The data collection methodology shapes everything downstream: which products fall into scope, how editions get inferred, how features are evaluated, how DR and shared infrastructure get counted, and ultimately what the auditor's findings will look like.

Customers who treat data collection as an administrative formality end up defending whatever the auditor's chosen methodology produces. Customers who treat it as a negotiation produce defensible findings. This article walks through how Broadcom audits typically collect data, the methodological choices that shape outcomes, and the defensive positions customers should establish before any data leaves their environment.

The data the auditor wants

A Broadcom audit's data needs fall into several categories. Understanding the categories is essential because the auditor's information requests will arrive grouped — and consenting to each group commits the customer to that line of investigation.

Entitlement evidence. What does the customer own? This typically includes contract documents, purchase orders, partner-of-record records, and historical licence keys. The auditor uses entitlement evidence to establish the customer's licensed position; gaps or ambiguities in entitlement become arguments that the customer is under-licensed.

Deployment inventory. What is installed and running? This covers ESXi hosts, vCenter instances, vSAN clusters, NSX components, Aria deployments, Carbon Black sensors, and so on. The inventory establishes consumption — the denominator in the compliance comparison.

Configuration data. How is what's installed configured? This includes per-host configuration, cluster configuration, feature enablement, edition flags, and architectural details. Configuration data tells the auditor which features the customer is using, which determines edition requirements.

Usage and performance data. What is actually being run? This includes VM inventories, resource utilisation, capacity history, and sometimes workload-specific information. Usage data is sometimes requested to identify peak consumption or to differentiate test/dev from production.

Operational evidence. How are operations conducted? This includes change-management records, patch-management logs, and sometimes monitoring data. Operational evidence is sometimes used to validate inventory completeness or to identify undocumented infrastructure.

Organisational evidence. Which legal entities are in scope? This includes corporate structure, subsidiary lists, M&A history, and sometimes detail on shared-services arrangements. Organisational evidence determines the audit's legal scope.

Each category carries different risks and benefits to disclose. The customer's response should be structured around informed choice in each category, not a blanket "yes" to whatever is asked.

The collection methods on offer

Broadcom auditors typically propose one or more of several collection methods.

Self-reporting via standardised templates

The customer fills in spreadsheets or templates with inventory, configuration, and entitlement data. The auditor then validates against sampling. This method puts the most discretion in the customer's hands but also requires careful work to produce defensible responses.

Discovery script execution

The auditor provides scripts to run inside the customer's environment that collect inventory and configuration data automatically. The customer runs the scripts and returns the output. This method is faster but cedes interpretation to the auditor.

Discovery tool deployment

The auditor proposes deploying their own discovery tooling — sometimes a Broadcom-provided tool, sometimes a third-party tool the auditor uses. The tool runs in the customer's environment for some period, collecting data continuously. This method produces the most data but represents the largest concession on the customer's part.

Direct vCenter/console access

The auditor requests interactive access to the customer's vCenter, console, or other management interfaces, to run their own queries directly. This method is occasionally proposed but represents an unusually large concession.

Hybrid approaches

Most engagements end up using a hybrid — some self-reporting for areas the customer controls cleanly, some script execution for areas where automated collection is more efficient, sometimes targeted tool deployment for specific verification.

The methodological choices that shape outcomes

The choices made about how data is collected determine what findings are possible. Several specific choices matter.

Snapshot versus continuous

A snapshot view captures the environment at a point in time. A continuous view captures changes over a period. Continuous data is much richer; it also exposes patterns (peak consumption, temporary deployments, test environments) that may not represent steady-state. Whether snapshot or continuous is the right basis depends on the customer's environment and the auditor's framing.

Production-only versus all environments

Some customers have well-documented separation between production and non-production environments, with different entitlement bases. Others run mixed environments where the separation is less crisp. The data collection scope — whether it covers all environments or only production — affects the findings substantially.

Inferred versus explicit edition

Edition is sometimes recorded explicitly in vCenter, sometimes inferred from feature usage. Inferred edition assignments can be challenged; explicit assignments are harder to dispute. Whether the auditor accepts the customer's explicit edition labels or infers from feature use is a methodological choice.

Active versus all-installed

Some inventory includes everything ever installed, including residual installations that aren't actively used. The auditor's treatment of these — count as deployed or exclude as inactive — has compliance implications.

DR and standby counting

Disaster recovery and standby capacity has special licensing treatment that varies by entitlement and contract. The auditor's default approach to DR counting is often unfavourable to the customer; the customer's contractual basis for different treatment needs to be established before data collection.

Shared infrastructure attribution

Infrastructure shared between products (e.g., a vCenter managing both vSphere and vSAN) needs to be attributed somewhere. The attribution rules affect which entitlement covers what.

What the customer should establish before data is collected

Before any data is shared with the auditor, the customer should have established several positions in writing.

Scope

What's in and what's out — by legal entity, geography, product, environment, and time window. Scope should be agreed in writing before data collection begins; expanding scope mid-engagement should require fresh agreement.

Methodology

Which collection methods will be used, what data will flow, and how the data will be interpreted. The customer should propose specific methodologies (not just react to the auditor's proposals) and require that interpretive choices be documented.

Data handling

Who will see the data, where it will be stored, how it will be secured, how long it will be retained, and how it will be destroyed at engagement end. The customer's information security and data-protection teams should review the data-handling commitments before the data flows.

Confidentiality

The auditor's contractual confidentiality obligations should be explicit and supplemental to any general NDA. The auditor's right to use the data for purposes beyond the specific audit (e.g., internal benchmarking) should be addressed.

Review and challenge process

How findings will be presented to the customer, how the customer can challenge them, what evidence is required to support a challenge, and how unresolved disputes are escalated. The process should be agreed at the start, not negotiated when findings arrive.

Communication protocols

Single point of contact, written-only communications, copy-to-counsel rules, response timelines. Ad-hoc verbal exchanges and informal email chains generate problems; a defined communication protocol prevents them.

Reading the auditor's data requests

Auditor data requests carry signals about where the auditor expects to find issues. Customers who read the requests carefully can identify the areas under investigation and prepare accordingly.

Some patterns to notice:

• Disproportionate focus on a specific product — the auditor likely has a hypothesis about under-licensing in that product
• Requests for historical data over multiple years — the auditor is looking for changes over time, often growth in deployment without corresponding entitlement
• Detailed feature-usage queries — the auditor is checking for use of features that require higher editions
• M&A-history requests — the auditor is checking whether acquired subsidiaries are properly entitled
• Service-provider or shared-services questions — the auditor is checking compliance with the relevant licensing programmes
• Cross-checks against Broadcom's records — the auditor is reconciling the customer's claim of entitlement against Broadcom's records of what was sold

Reading the requests doesn't mean refusing to respond — it means responding with awareness of what the auditor is testing.

Tooling and the customer's right to validate

When the auditor proposes tools, the customer should require validation of:

• What the tool collects. Some tools collect more than is needed for the audit; the customer should limit collection to what's necessary.
• Where data is sent. Local-only collection, with the customer transferring results, is preferable to direct upload to vendor systems.
• What is exposed to the auditor's other clients. The customer should have written commitments that its data is not pooled or used for benchmarking against other customers.
• Tool security. The tool's own security posture, vulnerability history, and update model should be evaluated before deployment.
• Performance impact. Continuous collection tools can affect environment performance; the customer should validate the impact in a non-production environment before production deployment.

The customer's information security and infrastructure teams should be involved in tooling decisions even if procurement and legal are leading the audit response. Tool deployment without infrastructure review has produced incidents.

The internal data collection that should run in parallel

While the auditor is collecting data, the customer should be collecting the same data independently. The parallel internal collection has several purposes:

• Validating the auditor's findings. The customer can compare its own counts against the auditor's findings and identify discrepancies.
• Establishing a baseline for disputes. If the customer's data and the auditor's data diverge, the customer has independent evidence rather than just objecting to the auditor's numbers.
• Surfacing issues before the auditor finds them. Internal collection sometimes finds compliance gaps the auditor missed; addressing them proactively (with internal remediation rather than audit settlement) is much cheaper.
• Building institutional knowledge. The customer that has run its own collection comes out of the engagement with better visibility into its own estate than it had going in.

The internal collection should be run by the customer's own team or its independent advisor, not by the auditor. Using the auditor's tools or methodology for internal validation defeats the purpose.

Common methodology mistakes

Letting the auditor set the methodology by default

Auditor-set methodology produces auditor-favourable findings. Customers should propose methodology proactively.

Accepting tools without security review

Tools deployed without infrastructure and security review can create incidents independent of any audit findings.

Mixing audit data with production operations

Audit data should be handled separately from normal operational data, with restricted access and clear retention rules. Mixing them creates confidentiality and discoverability problems.

Responding informally to data requests

Informal responses — email chains, ad-hoc spreadsheets, verbal answers — produce inconsistent and indefensible positions. All responses should go through a controlled review process.

Failing to track what's been shared

The customer should maintain its own log of every data item shared with the auditor, including date, format, and rationale. If a finding later turns on a specific data item, the customer needs to know what was shared and on what basis.

Treating data collection as separate from negotiation

The data collection phase is part of the negotiation. The methodology choices made during collection determine what the negotiation will be about.

Frequently asked questions

Can we refuse to deploy the auditor's discovery tools?

Generally yes — the licence agreement typically requires the customer to provide audit cooperation but doesn't compel specific tool deployment. Alternative collection methods can usually be negotiated.

How long should we retain audit data?

For the duration of the engagement plus a defined period for dispute resolution. Negotiate destruction commitments in writing.

What if the auditor asks for data outside the contractually agreed scope?

Refuse and require the scope to be formally expanded in writing if the auditor wants the data. Don't extend scope informally.

Should our internal collection use the same methodology as the auditor's?

Use similar methodology so the results are comparable, but maintain independent execution. Identical methodology defeats the purpose of independent validation.

How much internal effort does parallel data collection require?

Typically 200-600 person-hours over the audit period for a mid-size enterprise, less for smaller environments. The investment usually pays back many times over in reduced findings.

What if our data is incomplete?

Document gaps proactively rather than letting the auditor discover them. Acknowledging known gaps with remediation plans is more defensible than having them surface as findings.