Every vendor risk playbook assumes steady state. Continuous monitoring, quarterly review, renewal-cadence attestation — the whole framework depends on a portfolio company existing in the same corporate structure it existed in last quarter. Then the fund closes a carve-out, or bolts on a competitor, or spins a business unit into a stand-alone entity for its own exit path. The steady-state playbook stops working at the moment the paperwork closes, and the vendor risk team spends the next six months figuring out which of a hundred and eighty vendor contracts came with the newly-acquired entity, which of them belong on the parent register, and which of them are duplicative.
The interesting cases in third-party risk are not the steady-state ones. They are the transactions. Carve-outs where the parent still holds some of the vendor relationships. Bolt-ons where the acquired company's vendor stack overlaps forty percent with the acquirer's. Restructures where two portfolio companies are being merged and the fund needs to know which vendor obligations survive. These are the moments the vendor risk register earns its keep or embarrasses itself, and most portcos do not realize which one it is until the transaction is already six weeks in.
Here is what actually needs to happen to third-party risk when a portfolio company's corporate structure changes, in the order it matters — and the three questions the fund should be asking before the transaction closes, not after.
What actually happens to the vendor register at transaction close
At the moment of close, the parent's vendor register and the acquired entity's vendor register exist as two separate documents. Neither reflects the new corporate reality. Some vendors show up on both. Same vendor, two contracts, potentially different terms and different negotiated rates. Some vendors show up on only one. The acquirer inherits obligations they did not see. Some vendors show up on neither register but exist as shadow-IT relationships surfaced only when the vendor sends their next invoice to an accounts-payable address that has changed.
KPMG's 2025 M&A integration report names vendor fragmentation as a specific workstream, alongside HR, finance, operations, legal, communications, and synergy capture. The steady-state playbook says: reconcile the two registers, deduplicate, renegotiate. That is the right work. It is done in the wrong order. The right order is inverted — surface the transactions that need immediate action first, then reconcile the strategic long tail second.
Every enterprise SaaS contract signed by the acquired entity has a section titled “Change of Control” or “Assignment” or “Successor Interest.” Most define the trigger as a change of more than 50% of voting equity — which every PE transaction crosses. The clause typically grants the vendor renegotiation rights, and in a meaningful minority of contracts, termination rights “at the customer's sole discretion.” Sixty- and ninety-day notice windows are common.
The immediate work at close: pull every acquired-entity contract with more than $10K annual spend, grep for change-of-control language, flag the ones with notice windows or termination rights, and act in week one. Every day the acquirer delays is a day a vendor can invoke a clause the acquirer did not know existed.
Every SaaS the acquired entity used carries security-control obligations back to the acquirer at close. If the acquired entity had a BAA with a healthcare vendor, the BAA now covers the parent portfolio, with all the parent's incident-notification obligations. If the acquired entity had a DPA with an EU customer, the DPA now covers the parent's data flows. If the acquired entity signed AI-usage terms with a customer for a specific product, and the parent has an AI product too, the parent inherits enforcement scope they did not underwrite.
This is where the acquirer's cyber-insurance policy gets tested first. Most carriers require notification of material changes to the insured's footprint within 30 days of close. Missing that window can void coverage on incidents that touch the newly-acquired scope. The vendor risk team's job in the first thirty days is not to reconcile the register — it is to notify the carrier, notify the compliance function, and make sure the acquired entity's obligations are visible before an incident tests whether they were.
The strategic reconciliation — inherit vs. cut vs. renegotiate
After the immediate triggers are handled, the deduplication work begins. Every vendor on the combined register goes into one of three buckets: inherit as-is, cut and consolidate, or renegotiate for combined-scale pricing. The bucketing decision has a specific logic — and specific overrides for the cases where the default gets it wrong.
The three questions the fund should ask before close
Most vendor risk failures on transactions trace back to three questions the fund did not ask during diligence. Asking them at close is late; asking them before close changes the transaction economics.
- Question 1 — how many change-of-control triggers are we walking into?: Have the diligence team grep every acquired-entity vendor contract with more than $10K annual spend for change-of-control language. Not a summary; the actual clauses. This is the single most under-diligenced vendor risk in mid-market PE, and the pattern that most reliably surfaces surprise renegotiation demands in the first quarter after close.
- Question 2 — which of the acquired entity's security-critical vendors have obligations that survive the merger?: BAAs, DPAs, AI-usage terms, incident-notification cascades. These are not liabilities that can be restructured; they follow the data. The parent needs to know before close what regulatory scope they are inheriting so the cyber-insurance notification and the compliance function are ready on day one.
- Question 3 — what is the vendor concentration risk on the combined portfolio, and does it change our insurance posture?: Verizon 2025 DBIR reports third-party involvement in 30% of breaches, a materially higher number than prior years. If both entities used the same three cloud providers, the combined portfolio has vendor-concentration risk that carriers now price into premium. If any single vendor holds more than 20% of combined spend, expect the next renewal to reflect it. Underwrite for it during the transaction, not after.
The playbook for the first ninety days post-close
The ninety-day post-close vendor risk playbook breaks into three phases, each with a specific deliverable that the operating partner and the portco security lead sign off on before the next phase begins.
Days one through fourteen: change-of-control triggers and immediate security notifications. Legal pulls every acquired-entity contract over $10K annual spend and produces a change-of-control clause matrix — vendor, trigger threshold, notice window, termination language, consent requirements. The vendor risk lead maps that matrix to a week-by-week action plan for the notice windows that fire soonest. Security notifications go out to any customer or vendor whose contract obligates notification of ownership change. The deliverable at end of week two: a change-of-control action list ordered by fire date, and confirmation that the top ten security-critical customer and vendor notifications have gone out.
Days fifteen through forty-five: cyber-insurance carrier notification, regulatory re-attestation, shadow-IT hunt. The acquirer's cyber-insurance broker gets the material-change notification within the carrier's specified window — typically 30 days but check the specific policy. Every regulatory-obligated vendor relationship (BAAs, DPAs, PCI, DORA, HIPAA, etc.) gets re-attested with the acquirer's counterparty for the record. The shadow-IT hunt runs in parallel: SSO logs, IdP audit exports, expense-report vendor-name search, and network egress logs against the AP vendor list — every SaaS the acquired entity paid for that does not appear on the register. Shadow-IT is highest-yield in the first thirty days; after that, invoices start routing to the new AP system and evidence disappears.
Days forty-six through ninety: strategic reconciliation, tool consolidation, combined-scale renegotiation. Every vendor on the combined register lands in one of the three buckets from the reconciliation table above. The top ten overlapping vendors by combined spend get formal renegotiation kickoffs. Tool consolidation on the security stack (SIEM, EDR, GRC) completes before day 90 or moves to a scheduled decommission with a firm date; unbounded “we'll consolidate eventually” drift is where the $200K-per-year duplicate spend hides for another eighteen months. The deliverable at day 90: a clean, single vendor register with per-vendor risk tier, next-review date, and combined-scale contract status.
The portco lead who runs this playbook out of order (reconciling before handling change-of-control triggers, consolidating tools before notifying the carrier) loses more money than the portco lead who does nothing. Doing nothing is at least defensible in a post-mortem. Doing it in the wrong order looks like malpractice.
The shadow-IT hunt — three signals that surface faster than the invoice
Shadow IT is where the vendor register post-close is most incomplete, and where the biggest surprises hide. Before the invoices route to the new AP system — which is when most acquirers pretend they will discover shadow IT — three signals surface faster.
SSO and IdP audit logs. Every SaaS integrated with the acquired entity's IdP shows up in the IdP's audit history. Pull the last twelve months of unique app-launch events from Okta, Azure AD, Google Workspace, or the equivalent. Any app the register does not know about is shadow. This surfaces enterprise SaaS the finance team knows about but the security team does not — the marketing team's fifth analytics tool, the sales team's Chrome extensions, the engineering team's third code-review vendor.
Corporate credit-card and expense-report vendor-name search. Every SaaS someone expensed shows up in the expense system. Even without an IdP integration, the vendor name is on the statement. This surfaces the low-dollar shadow SaaS — the $15/month team tools, the individual pro subscriptions, the trial-that-turned-into-a-subscription pattern — that never touched the vendor register because they were charged directly to individual credit cards. Low-dollar per instance, high-count in aggregate.
Network egress logs against the AP vendor list. Any SaaS receiving data from the acquired entity's production network has an egress footprint. Diff the last thirty days of outbound network destinations against the vendors on the register — the delta is shadow. This is the highest-signal method for surfacing security-relevant shadow IT: data-processing vendors that never routed through IT procurement because they were engineering tools with a self-serve signup.
Running all three signals in parallel in the first thirty days finds ninety percent of the shadow IT that matters. Waiting for invoices to route to the new AP system finds it in month five. The delta is four months of shadow-IT exposure the acquirer's cyber insurance policy does not know about.
The way a portco's vendor risk team handles the ninety days post-close is the best proxy the fund has for how the portco will handle the next transaction. Portcos that run a clean playbook on a carve-out are the ones the fund puts on the platform strategy for the next bolt-on. Portcos that show up with a mess in month six are the ones the fund quietly downgrades in its own operating-partner rating. Nobody tells the portco that is what is happening. But it is what the fund is doing.
The bottom line
The vendor register is the highest-value asset in the transaction bundle and the fastest to rot at close. Freeze it on day zero. Run all three shadow-IT signals — SSO grants, expense reports, egress logs — in the first thirty days, before the invoice reroute obscures what was there. Categorize every vendor inherit / cut / renegotiate by day forty-five. Land on a single register with per-vendor risk tier, named owner, and combined-scale contract status by day ninety. Every day past that is exposure the acquirer's cyber-insurance policy does not know about, sitting in a spreadsheet nobody owns, waiting for the first cross-portfolio incident to translate into a claim the carrier will contest. The fund watching the loop is deciding, in real time, whether this portco gets the next bolt-on.
Put the playbook to work
The portco-side vendor register — inheriting the acquired entity's vendors, running them through a real risk review, and shipping the quarterly cyber packet the fund reads — is where the three-slide quarterly cadence comes from. The pre-close diligence side runs on the same methodology at Quantitative Cyber Diligence, and the fund-facing view lives at diligence.vcisolite.com. Visit diligence.vcisolite.com to see how the pre-close and post-close pieces stitch together for a fund managing more than one deal a year.