Carve-Out Tech Diligence: When the Seller Won't Give You Access

The seller is the system The counter-intuitive thing about carve-out diligence is that the worst-prepared deals are the ones where the buyer trusts the data room. The data room is curated by the seller. The seller is the operator. The operator runs the systems the buyer is buying. And in every carve-out we have advised on, the seller had a defensible commercial reason, competitive sensitivity, regulatory constraint, simple operational risk, to hand the buyer a narrower view of those systems than the buyer assumed. Most carve-out diligence is run with one hand tied behind your back. The buyer's diligence team plans like they're doing a clean platform deal. They draft a cyber and tech diligence list assuming they'll get the same artifacts a willing target would provide, admin reads on the identity provider, exports of the asset inventory, sample audit logs, third-party penetration tests, full schemas of the production data store. Then they get to the data room and find that two-thirds of the list is unavailable because the carved-out unit shares those systems with the seller's retained business, and the seller is not handing over an admin read of their own corporate IdP to a competitor or a financial sponsor. The diligence team scrambles, the timeline compresses, and the buyer signs an SPA with a TSA that papers over what was supposed to be diligence. Across the carve-outs we have run diligence on, strategic-acquirer carve-outs from public-company parents, PE platform formations built from a single carve-out, bolt-ons that came out of a strategic seller, the lesson is consistent: access constraints are not a reason to skip diligence. They are a reason to scope diligence differently. The artifacts the buyer cannot see become the negotiating list for the TSA. The verifications the buyer can do without seller access become the spine of the cyber and tech sections of the SPA. The 30-day post-close access plan becomes a deliverable the buyer should demand a draft of before signing, not after. This guide walks that scope shift, what makes carve-outs uniquely hard, what the buyer can verify without seller access, what to negotiate in the TSA, how to sequence Day-1 and post-close access, and the four sources of integration cost overrun. It closes with the named diagnostic and three actions to take this week. Why carve-outs are uniquely hard A platform deal, buyer acquires whole company, founders roll, target's CIO becomes the platform CIO, is the easy diligence shape. The target wants the deal to close, and the target's tech leadership has every incentive to surface what they own. The data room is broad because the seller's interest is the same as the buyer's: produce the picture the buyer needs to fund the deal. A carve-out inverts that posture in four specific ways, and each creates a class of diligence gaps the standard checklist does not anticipate. The seller is the operator. In a platform deal the company being sold is a discrete entity with its own systems. In a carve-out the unit being sold is a slice of a larger operation that continues to run on the seller's infrastructure after close. The IdP, the email tenant, the help desk, the SIEM, the EDR, the productivity suite, the financial system, the HRIS, the procurement system, most of these are the seller's, not the unit's. The unit is a tenant, not a building. Diligence requests that ask for "your identity configuration" or "your security tooling stack" run into a hard wall. Competitive sensitivity is real. When the seller is a strategic and the buyer is a strategic competitor, the seller's legal and commercial teams will not approve disclosures that expose the seller's broader operations. We have seen sellers refuse to provide vendor lists because the lists reveal tooling choices across retained business lines. We have seen sellers refuse to share network diagrams because the diagrams expose internal segmentation logic the seller considers proprietary. The seller would rather lose the deal than expose the parent. TSA scope is doing diligence's job. The Transition Services Agreement is the legal document that says "the seller will keep providing X services for Y months at Z price." In a clean carve-out, the TSA is a transition mechanism. In most carve-outs, the TSA is also where the unverifiable diligence answers live: the buyer is buying a forward commitment to access in lieu of present access. If the TSA is drafted thinly, the buyer signed without diligence. Regulatory access constraints can override commercial flexibility. When the unit operates in a regulated context, healthcare, life sciences, regulated SaaS, federal contractors, certain professional services, statutes and customer obligations prevent the seller from disclosing certain artifacts pre-close. PHI access logs cannot be shared with a buyer. Some federal-contract security artifacts require contracting officer approval. Customer-specific confidentiality regimes can block disclosure of data flows. The seller is not being difficult; the seller cannot, legally, hand it over. The sum of these four conditions is a diligence environment where the standard playbook produces a deceptive output. The checklist gets answered, the answers are technically true, and the picture is incomplete in ways the checklist does not surface. We have read post-close retrospectives where the integration team discovered in week three that the unit had no independent SIEM, EDR, IdP, backup posture, vulnerability program, or third-party risk register, because all of those were the seller's, and diligence had read "the company has SIEM, EDR, IdP, backups, VM, and TPRM" in the data room and not asked the next question. What you can verify without seller access The first move is the inventory of what the buyer can verify on their own, without seller cooperation, TSA support, or any data-room artifact. It is a longer list than most diligence teams plan for, and a properly scoped engagement leans on it heavily. We group the techniques in five categories and describe what each tells you and, equally important, what it does not. External attack surface analysis. DNS records, SSL/TLS certificates, IP allocations, exposed services, web-facing applications, and the leakage trail across cloud-provider public-asset registries are all observable from the public internet. For a unit with its own customer-facing surface, the buyer can produce an external posture assessment independent of the data room. Certificate transparency logs reveal subdomains the seller may not have disclosed. Passive DNS reveals service migrations. Cloud-provider asset enumeration reveals exposed buckets, exposed databases, exposed admin interfaces. What this tells you: patch posture on edge services, certificate discipline, forgotten subdomains, exposed dev/staging environments. What this does not tell you: anything about the internal environment, identity posture, data-store configuration, or shared systems. The signal is the perimeter, not the platform. Customer reference calls run through the right script. Diligence teams usually treat customer references as commercial signal. They are also technical signal. A customer integrated into the unit's product, API consumer, SSO federated, data exchange in either direction, knows things the seller will not disclose. They have seen incident notifications. They have seen credential rotations. They have negotiated DPAs and audit rights. They have asked for SOC 2 reports. They have noticed when the status page lights up and when it doesn't. What this tells you: incident frequency, communication maturity, contractual security commitments and how they have actually played out. What this does not tell you: anything internal that has not produced a customer-visible event. Audit-report review (SOC 2, ISO 27001, HITRUST, CMMC, FedRAMP, customer-specific). If the unit has its own attestations, those are the most credible non-seller-controlled artifact in the data room. SOC 2 Type II reports describe the actual control set, the testing period, the exceptions, and the auditor's opinion. We read the Section 5 management response, the auditor's exception language, and the carve-out scoping language to confirm whether the report covers the unit being sold or the parent. The system description matters: "the company's production environment" reads differently than "the company's production environment, including the X subsystem operated by the parent." What this tells you: the control state at audit time, trajectory across cycles if you have them, the discipline of the compliance program. What this does not tell you: anything since the audit, anything outside the scoped system boundary, or anything the auditor was prevented from testing. Vendor invoice and contract review. Invoices reveal the third parties the unit actually pays for, a more truthful list than the vendor inventory the seller produced. Invoices reveal the security tooling actually licensed, data-platform spend, cloud spend by region, SaaS sprawl, and vendors not on the diligence-supplied list. Contracts reveal SLAs, breach notification obligations, BAAs, DPAs, audit rights, data residency commitments. What this tells you: what the unit is actually running and what contractual obligations transfer at close. What this does not tell you: how well any of it is configured. A unit that pays a six-figure annual bill to a major SIEM vendor is not the same as a unit that uses the SIEM. Invoices are a floor on capability, not a measure of it. Public regulatory, litigation, and incident-disclosure search. SEC filings if the parent is public, state attorney-general breach notifications, HHS Office of Civil Rights breach portal entries, court records, plaintiff-side data-breach complaints, and Wayback Machine archives of the unit's prior security and trust pages. What this tells you: disclosed incidents, regulatory engagements, public posture changes over time. What this does not tell you: undisclosed incidents, which are the ones that matter most. The point is not that the buyer can do diligence without the seller. The point is that a substantial portion of the credible signal comes from artifacts the seller does not control. The diligence work left after the no-seller-access work is the negotiating list for the TSA and the SPA. The TSA: what to negotiate before close The Transition Services Agreement is the diligence document for what the seller will not show the buyer pre-close. Most TSAs we read are drafted by seller's M&A counsel as a transition-of-services document, what the seller will keep doing, for how long, at what price. Most buyers' counsel review the TSA as a commercial document and negotiate scope, duration, and pricing. Both are right; neither is sufficient. The TSA also has to negotiate the access the buyer needs to verify, post-close, the diligence questions the buyer could not verify pre-close. Five access categories matter for cyber and tech, and the TSA either covers them or quietly omits them. Logs. Administrative read access to the SIEM events for the unit's environment for the TSA period, plus an exportable archive of the prior twelve to twenty-four months at effective date. Without this, the buyer cannot investigate against history, validate seller representations about prior incidents, or establish a baseline. Sellers fight on the historical archive because it includes retained-business activity; the negotiation is scoped extraction filtered to the unit's environment. Identity. Administrative read access to the IdP configuration for the unit's users, applications, and groups, plus the ability to begin standing up a new IdP tenant before TSA wind-down. Sellers will not give administrative read on their corporate IdP. The negotiable middle is a scoped read, user list, application assignments, group memberships, MFA enrollment, and a defined identity-migration path with seller cooperation built into the TSA. Data. Administrative read access to the unit's production data stores, with the ability to enumerate schemas, sample row counts, and validate backup/restore posture. Sellers fight here when the stores are shared. The negotiation moves to logical separation guarantees, schema-level read, and a defined data-extraction event the TSA covers operationally and contractually. Code. Administrative read access to source repositories, history, branch protection, secret-scanning, dependency-scanning, CI/CD configuration. Less contested since the code is the asset, but access details are often deferred and then take six weeks to materialize. The TSA should specify Day-1 access. Vendor relationships. The right to contact each third-party vendor directly and renegotiate or replace the relationship. Sellers sometimes resist because vendor relationships are master-agreement-level with the parent. The negotiation is around assignment rights, parallel direct contracts, and a defined vendor-transition window. What the buyer should demand in every TSA: a defined Day-1 access list, a defined opening sequence at 30/60/90 days, a defined extraction window for historical artifacts, and a defined wind-down trigger schedule. What the seller will fight on: any request that exposes retained-business operations, anything counsel can frame as broader than necessary, any pricing structure that does not give the seller margin. The buyer wins these fights by articulating specifically why the access matters and accepting an appropriate confidentiality regime; the buyer loses them by asking generically and letting the seller paint them as fishing. Day-1 readiness without full access The TSA buys time. Day-1 still has to happen. The unit has to operate as a separate entity from the moment the wire clears, regardless of how much of the stack stays on TSA-shared infrastructure for the next nine months. There are four Day-1 capabilities that have to be in place before close, and most are buyer-side, not seller-side. Identity stand-up for buyer-side personnel. Every buyer-side person with any operating role post-close needs identity in a buyer-controlled IdP from Day 1, the portfolio CIO, the integration team, the finance function closing the books, the legal function fielding incident notifications, the unit's executive leadership if they are rolling. We have seen Day-1 plans where the integration team was issued seller-domain email addresses for "operational continuity," then could not send deal-related communications without going through a three-day seller-IT queue. Stand up the buyer's IdP, email tenant, and productivity suite for buyer-side personnel before close. Financial system access. The finance function needs access to the unit's billing data, AR aging, contract registry, and revenue recognition source artifacts from Day 1, even if the underlying ERP is on TSA. The buyer needs to confirm pre-close which mechanism delivers the artifacts the team needs to close month one under buyer ownership without relying on seller goodwill. Customer communications readiness. Customers need to hear about the change from a single, coordinated voice, the unit's commercial leadership co-signed by the buyer. The Day-1 communication, status-page update, commercial-team script, customer-portal copy, and billing-rebrand-or-no-change decision should all be written, reviewed by both sides' counsel, and queued for release at signing. We have seen carve-outs where customers learned about the change from a press release before they had heard from the unit; the resulting churn was a multi-million-dollar event. Security-incident escalation path. From the moment of close, the unit has its own incident-response posture, even if the SIEM is on TSA. The path for a Day-1 incident, who declares, who notifies, who has authority to engage outside counsel and outside IR, who notifies customers and regulators, has to be defined. The buyer's portfolio IR posture has to extend to cover the unit on Day 1. We deliver a one-page Day-1 incident escalation chart on every carve-out we advise on. These four are achievable without full seller access because they are buyer-side or buyer-coordinated. They are also non-negotiable; a Day-1 operational gap on any of them attracts trade press, regulator attention, or customer termination. The diligence team's job is to confirm pre-close that each has an owner, a plan, and a tested path. The 30-day post-close access plan The TSA opens access on Day 1 to a subset of the systems. The unit's full operational autonomy, its own SIEM, EDR, IdP, backup posture, vulnerability program, third-party risk register, is built over the TSA period. The buyer who treats the post-close access plan as a Day-1 deliverable avoids the integration-cost overrun. The buyer who treats it as something the integration team will figure out in month two pays for that figuring-out twice. The 30-day plan we run sequences access in a specific order, prioritizes signal-to-watch over signal-to-collect, and treats the TSA period as a series of opening events rather than a single transition. Days 1–7: identity, code, customer comms, incident path. The four Day-1 capabilities operationalize. Buyer-side identity is fully populated. Source-code repositories are administratively accessible to engineering leadership. Customer communications run on plan. The incident-escalation chart is tested with a tabletop on Day 5. Days 8–14: log extraction. The TSA-defined log extraction begins. The buyer ingests the prior twenty-four months of SIEM logs into a buyer-controlled environment and begins historical investigation, looking for indicators of unreported incidents, anomalous data exfiltration, and patterns the seller's IR team did not investigate. The TPRM function pulls the vendor inventory from invoices and begins re-papering critical vendors. Days 15–21: data extraction. The TSA-defined data extraction begins. The buyer validates schema, row counts, and backup posture against what was represented in diligence. Data engineering begins migration planning off shared seller infrastructure, scoped to what can move within the TSA period vs. what requires post-TSA execution. Days 22–30: integration plan finalized. With log, vendor, and data signals from the prior three weeks, the integration team finalizes the 12-month plan, slots remediation for gaps surfaced, and identifies what stays on TSA longer than the original duration, triggering the extension negotiation early enough to land it on commercial terms rather than under wind-down pressure. The signal-to-watch list, in priority order: anomalous activity in the historical SIEM logs the seller did not investigate; vendor relationships that fail re-papering due to seller-side master-agreement obligations; data-platform shape that does not match what was represented; unit personnel who decline to come over or give notice within the first 30 days; customer escalations that suggest perception of the change is more negative than modeled. The 30-day plan does not solve the integration. It surfaces, in 30 days, the gaps that determine whether the integration runs to plan or runs over. Technical-debt valuation for sub-deals When a carve-out integration runs over budget, the overrun is rarely a single line item. It is the sum of four sources, each mappable to a diligence question that should have been answered pre-close. The four reliably account for the bulk of variance between modeled integration cost and actual. Identity rebuild. The unit's users, applications, groups, MFA configuration, conditional-access policies, and federation relationships have to move from the seller's IdP to the buyer's. Every SaaS application is re-federated, every user re-provisioned with verified attributes, every group re-mapped, every conditional-access policy re-derived from the seller's (which the buyer cannot fully see) to the buyer's. Cost range: for a 100–500-person unit, $250K–$1M depending on application count, federation complexity, and the buyer's tooling maturity. Compresses with a portfolio identity-migration playbook; expands without one. Security tooling rebuild. The unit had access to the seller's SIEM, EDR, vulnerability scanner, secret-scanning, threat intel, email security, and managed-detection function. The buyer stands up the unit's own. License procurement, agent rollout, ruleset porting where possible, tuning, integration with the buyer's portfolio SOC. Cost range: for a 100–500-person unit, $400K–$1.5M year-one licensing plus $150K–$500K deployment labor. Material variance based on whether the buyer can extend portfolio enterprise agreements to cover the new unit. Data residency rebuild. Production, analytical, archival, and backup data sit on the seller's cloud accounts and storage. They have to move to buyer-controlled accounts within the TSA period, with no customer-perceptible disruption and no regulatory residency violation in flight. Egress is the visible cost; migration labor is the larger one. Cost range: for 50–500 TB of relevant data, $100K–$750K. Expands materially when the data has regulatory residency obligations (PHI, regulated EU data, federal-contract data). Third-party contract renegotiation. Every vendor relationship the unit had through the seller's master agreement has to be re-papered as a direct relationship. Some vendors will honor original terms; many will not, and will use renegotiation to capture margin the seller's volume had suppressed. SaaS pricing typically rises 10–40% on the re-paper. Some vendors refuse to re-paper at all, forcing replacement. Cost range: for 30–80 material vendor relationships, $200K–$2M in year-one pricing increase plus replacement implementation. Together, on a typical mid-market carve-out (100–500 people), the four sources produce $1M–$5M in integration cost above the buyer's pre-close model. Diligence that surfaces them pre-close lets the deal team price them into the bid, model them into the integration plan, and negotiate them into the TSA. Diligence that does not ships a deal-economics surprise into year one. Where the diagnostic fits The Securem Carve-Out Diagnostic is what we run when a buyer engages us pre-LOI or pre-signing on a carve-out where the access constraints are real and the diligence window is short. It is the same fixed-scope, fixed-price, written-deliverable shape as the rest of the Securem Diagnostic family. It is not implementation. It is not a retainer. It is the audit-grade pre-close assessment that produces a written report the corp-dev team can hand to the IC, the operating partner can hand to the LP, and outside counsel can use to draft the cyber and tech sections of the SPA and the access provisions of the TSA. The Diagnostic runs in 21 days against three parallel workstreams. Workstream one is the no-seller-access verification: external attack surface, certificate transparency, customer reference scripting, audit-report deep read, vendor invoice and contract reconstruction, public regulatory and litigation search. Workstream two is the data-room and management-presentation review against the carve-out-specific question set, what is the unit's, what is the seller's, where are the dependencies, what does the TSA need to cover. Workstream three is TSA and SPA negotiation support: access provisions, representation and warranty language on cyber and tech, indemnification scope on undisclosed incidents, post-close access sequence. The deliverable is a 30–50 page written report plus a TSA access-provisions appendix the buyer's counsel can paste into the draft. The Diagnostic is paired with the Carve-Out Tech Diligence Checklist, the field-tested request list that distinguishes what to ask for, what to expect not to get, and what to negotiate into the TSA when the seller declines. The checklist is the working artifact; the Diagnostic is the engagement. Most of the checklist work can be done internally by a corp-dev team with the right pattern recognition; the Diagnostic exists for deals where the access constraints are atypical, the deal economics are sensitive to integration cost, or the buyer's internal team does not have repeat-pattern carve-out experience. Three actions any corp-dev or operating partner can take this week, regardless of whether they engage us: 1. Re-read your last carve-out's TSA against the five access categories. Walk it against logs, identity, data, code, and vendor relationships. Mark each Covered, Partial, or Missing. A 90-minute exercise that produces the template for your next TSA negotiation. Most teams find at least two of the five were Partial or Missing, and paid for the gap in integration cost. 2. Pull the public-surface report on a current pipeline target. Run the external attack surface, certificate transparency, and public regulatory search before the next management presentation. Half a day of analyst time. The value is asking the seller a question they did not prepare to answer. 3. Draft the Day-1 four against your portfolio standard. Confirm that buyer-side identity, financial-system access, customer communications, and incident escalation each have an owner and a tested plan. Most portfolios have two of the four; the missing two are the ones that bite on Day-1 of the next deal. Three actions, one week, no engagement required. If the access constraints are unusual, the deal economics do not have room for surprise, or the unit operates in a regulatory context that expands cyber scope, that is where the Carve-Out Diagnostic fits. Twenty-one days, fixed price, written report you keep regardless of whether the deal closes. The Carve-Out Tech Diligence Checklist download paired with this guide is the working request list, what to ask for, what the seller will provide, what the seller will resist, and what each gap maps to in the TSA. Use it on every carve-out evaluation. Update it as seller patterns evolve in your sector, and we will keep doing the same on our side.