Broadcom Audit Data Requests: What to Share
The auditor's first data request is rarely a list of what they need. It is a list of what they want. Knowing the difference protects millions of dollars in eventual claim value.
Every Broadcom audit runs on data the customer provides. The audit clause in the master agreement entitles the auditor to certain data, the customer is obliged to provide it, and findings are built from the dataset that crosses between the two parties. Yet most customers we work with have never thought systematically about the gap between data the auditor is contractually entitled to receive and data the auditor would like to receive. That gap is where audit outcomes are determined.
This article walks through the typical Broadcom audit data request in detail. It explains what is being asked for, why, what the contract usually requires, what the customer should provide, what should be negotiated, and what should be declined. Most of the principles apply equally to a VMware audit, a Symantec audit, and a CA Technologies audit, with product-specific notes where the data requests diverge.
What the contract actually requires
The audit clause typically requires the customer to provide "such records and information as are reasonably necessary to verify the customer's compliance with the agreement". Three words in that phrase do a lot of work: records, reasonably, and compliance.
Records means existing business records, not records the customer must construct for the auditor. If your environment does not capture per-virtual-machine vCPU configuration history, you are not obliged to build a year of history just because the auditor asks for it. Reasonably necessary imposes a proportionality test: the data must be sufficient for compliance verification, not exhaustive of every possible piece of information. Compliance with the agreement limits the data to what is relevant to the products, entities, and time periods covered by the agreement.
Many Broadcom data requests fail one or more of these tests as written. A request that asks for raw vCenter exports for every cluster the customer has ever operated, including those covered by separate agreements or now divested, fails the reasonableness test. A request for HR data, financial data, or detailed network architecture data fails the records test, because most of that data is irrelevant to product compliance. A request for usage data from products the customer has never licensed under the master agreement fails the compliance test, because that data cannot establish compliance with the agreement being audited.
The typical first data request
A typical first data request from a Broadcom audit team will ask for some combination of the following: entitlement records, contract documents, deployment inventory, virtual machine inventory, host configuration data, vCenter system exports, network architecture diagrams, organisational charts showing entity relationships, a list of geographic sites, lab and development environment inventories, disaster recovery configuration, support records, and a customer-prepared compliance position statement.
Each of these categories deserves separate treatment. Some are clearly within the auditor's contractual entitlement. Some are clearly outside. Most fall into a middle zone where the answer depends on how the request is scoped and how the data is structured.
Entitlement records — share, but match the auditor's copy to yours
The auditor will have a copy of your entitlement record from Broadcom's internal systems. You should provide your own copy from your records. The two will usually differ. Discrepancies almost always favour the customer if surfaced early — Broadcom's internal entitlement records have well-documented errors from the acquisition migration, and the customer's records sometimes reflect entitlements that Broadcom has lost track of.
Contract documents — share what they don't already have, no more
Broadcom already has the master agreement. Provide it again only if asked. Provide amendments, side letters, and superseding agreements only if they are relevant to the audit period and the products under audit. Do not volunteer unrelated contracts. Auditors sometimes use unrelated contracts to construct comparative pricing claims that are irrelevant to compliance.
Deployment inventory — share the agreed scope, not the universe
The deployment inventory is the most contested data category in nearly every audit. Auditors ask for "all VMware deployments globally" and customers often comply without thinking about scope. The correct response is to provide the deployment inventory for the entities, products, and time period agreed in the kickoff scope memo. Inventory for entities, products, or periods outside the agreed scope is not the auditor's to receive.
Virtual machine and host configuration data — share what compliance requires
For vSphere and VCF audits, virtual machine and host configuration data is the core dataset. Compliance verification under per-CPU or per-core licensing requires host configuration data. It does not normally require virtual machine inventory at the level of detail auditors typically request. Push back on VM inventory requests that go beyond what is needed to verify host-level entitlements, and push back hard on requests for VM-level configuration history that exceeds the data your environment actually retains.
Categories that should usually be refused
Some data categories should be refused outright unless the contract clearly requires them, which it almost never does.
HR data, including employee headcount, organisational charts at the individual level, and details of internal IT staffing, is not normally compliance data. The exception is Symantec endpoint products where licensing is sometimes tied to user counts; even then, the auditor needs only an aggregate user number, not personally identifiable data.
Financial data, including budget documents, IT spend records, and procurement information, is almost never compliance data. Auditors sometimes request it to build pricing comparison arguments or to support claims that the customer should have known they were over-deployed. Both are inappropriate uses of the data.
Detailed network architecture and security configuration data is rarely compliance data. The exception is when network configuration is the basis for a specific licensing model (for example, NSX licensing tied to network configurations). In that case, provide only the configuration data directly relevant to the licensed product, not the full network architecture.
Data on products outside the audit scope is never compliance data for this audit. If the auditor asks for usage data on a product they were not engaged to examine, the right answer is no.
If you cannot articulate what compliance question a data field would answer, that field probably does not belong in the response. Send the auditor a written request to explain the compliance basis for any field whose purpose is unclear.
How to package the data
The format and packaging of the data is almost as important as its content. Three packaging principles consistently produce better audit outcomes.
First, package data with the scope agreement and methodology assumptions stated explicitly. Every dataset you provide should include a one-page cover memo that states the entities covered, the products covered, the time period covered, and the methodology assumptions used to produce the dataset. The cover memo is the customer's defence against auditor reinterpretation later.
Second, package data in your preferred format, not the auditor's. Auditors sometimes request specific data formats — for example, a particular vCenter export script that captures more data than the auditor needs. The customer is not obliged to use the auditor's tooling. Provide data in a format that captures the agreed dataset and nothing more.
Third, package data with a version number and a delivery date. Audit fieldwork takes months, and customers routinely produce multiple data deliveries during fieldwork. Each delivery should be versioned. Without versioning, the auditor's working dataset and the customer's understanding of what was delivered will diverge, and disputes about findings will be impossible to reconcile.
The compliance position statement question
Some auditors request a customer-prepared compliance position statement at the start of fieldwork. This is the document where the customer declares their own assessment of their compliance position. Do not provide one unless explicitly required by the contract, which is rare.
A compliance position statement is, in practical terms, the customer building the auditor's case for them. Anything the customer concedes in the statement is conceded. Anything the customer overlooks but the auditor finds later is doubly damaging — the customer not only failed to comply, but also failed to recognise the failure. Far better to engage with specific data requests and respond to specific findings than to volunteer a position statement up front.
Data handling, privacy, and the data-handling protocol
The data-handling protocol is the negotiated agreement on how the data the customer provides will be stored, used, and destroyed. It is a contractual document distinct from the master agreement, and it should be negotiated before any substantive data flows.
A good data-handling protocol covers: who at the auditor will have access to the data, where the data will be stored, in what jurisdiction, for how long, under what security controls, with what export controls, how the data will be destroyed when the audit closes, whether the data can be used to inform other Broadcom commercial activities outside the audit, and what notice the customer is entitled to if the auditor needs to share data with third parties.
The last point is the most overlooked. Customers regularly discover that their audit data has been shared with Broadcom's account team, with Broadcom's product organisation, and in some cases with third-party consultancies. None of these are compliance functions. Most are commercial functions. Data handling protocols should explicitly prohibit sharing audit data with commercial functions inside Broadcom, and customers should require notice and consent before any third-party data sharing.
Timing the deliveries
The auditor will propose a delivery schedule. Customers who accept the auditor's schedule typically deliver too quickly, which produces underprepared deliveries with errors and overreach. Negotiate the delivery schedule so that the customer has time to validate each dataset before it leaves the customer's environment.
A realistic schedule for a mid-sized enterprise VCF audit allows two to three weeks per major data category for first delivery, and one to two weeks for any subsequent refinements. Auditors will push for faster timelines because faster delivery favours the auditor. Customers should hold to the realistic timeline, citing data validation requirements rather than negotiating goodwill.
What to do when the auditor asks for something you do not have
The customer is not required to construct data that does not exist. If the auditor asks for, say, twelve months of vCPU configuration history and your environment captures only the current configuration, you are not obliged to retroactively reconstruct twelve months of history. The right response is to state, in writing, what data is available and what is not. Auditors then face a methodology question: how should they build findings on a dataset that the customer cannot fully provide? In most cases, the answer is that findings are built from the available data with reasonable assumptions about non-available data, and those assumptions become a methodology challenge point for the customer later.
Related reading
If you have not already, read our companion guides on limiting audit scope, the Broadcom audit process, and responding to the audit letter. The data-request question is intertwined with all three.