6. Speed vs depth: trade-offs in fast-cycle due diligence • EL BANTLI

The banker offered a 12-business-day window and a vendor report. The deal team wanted a “quick tech scan” and a green light for sign.

The tech lead did what most teams do under time pressure: covered everything, shallow. Application landscape, infra, cyber, data, IT org, costs. Forty slides later, the conclusion was “no material issues identified.”

After close, the integration plan hit its first real gate: identity. The target’s admin accounts lived in a different directory than user accounts, privileged access was shared, and the logging stack couldn’t meet the buyer’s baseline. Connectivity slipped by 90 days while controls were rebuilt. The synergy case didn’t break. The timing did. The model assumed benefits in quarter two; they started showing up in quarter four.

Fast-cycle diligence creates a false choice: be fast or be deep. The real choice is more specific:

When time is fixed, will you go deep on the few topics that set the clock and the cash, or will you spread effort across a checklist and still sign with blind spots?

Why “fast-cycle” is where tech diligence matters most

In a long process, you can recover from a wrong call with more work: more workshops, more data pulls, more confirmatory analysis.

In a fast-cycle process, you can’t. The seller controls access, the calendar is set, and the deal is moving whether you have evidence or not.

That’s why the goal is not a comprehensive inventory. It’s underwriting three things the model is sensitive to:

The speed limit: what will gate Day-1 continuity, connectivity, TSA exit (if any), and the first synergy/value milestones
Mandatory cash: one-time spend you will pay whether you like it or not (stabilize, separate, remediate, stand up)
Downside protection: what can create catastrophic disruption or valuation impacts (cyber events, compliance failures, core system fragility)

If you answer those three, you can sign with an explicit posture: “we’ll connect later,” “we’ll fund remediation,” “we’ll delay the value lever,” or “we won’t buy it on these terms.”

A simple triage: deal-breakers, clock-setters, cash-setters

Fast-cycle diligence works when you triage ruthlessly. A practical split:

Deal-breakers: things that can stop the deal or materially change valuation
Clock-setters: things that determine when the deal thesis can move
Cash-setters: things that determine the minimum one-time spend and true run-rate

This is how you get depth in 10–15 days: not by doing everything, but by doing the right things with evidence.

Deal-breakers: eight fast-fail questions (with evidence)

Fast-cycle diligence should start with questions that have binary outcomes. Each needs one or two artifacts, not a workshop.

Have you had a material security incident in the last 24 months? Ask for the incident register and post-incident actions (not a verbal summary).
Can we meet the buyer’s minimum security bar before we connect environments? Validate MFA coverage, endpoint tooling coverage, and log coverage (SIEM) with screenshots or exports.
Is any core system at or near end-of-life during the hold period or integration window? Ask for vendor support dates and internal upgrade plans for ERP/CRM/core platforms.
Is there a known compliance exposure tied to revenue (PCI, HIPAA, SOX controls, data residency)? Ask for the last audit findings and remediation status.
Is revenue operationally dependent on a single system or vendor with weak resilience? Ask for uptime history and the last major outage root-cause analysis.
Does the company have the rights to run and change what it sells? For software-heavy businesses: IP ownership clauses, open-source policy, and the last customer security questionnaire responses.
Can the business close the books reliably today? Ask for the close calendar and the top manual steps; a “10-day close” is often a proxy for fragile data and controls.
Is there a key-person or single-team dependency that makes execution unrealistic? Ask for the org chart including contractors, and confirm who actually runs core systems day-to-day.

Decision trigger: If you can’t get evidence for a fast-fail question, treat it as a risk you own and price it, structure it, or walk.

Clock-setters: what sets the deal’s speed limit

Most teams waste fast-cycle time on diagrams. The speed limit is usually set by a small set of practical constraints:

1) Identity and security controls (the connectivity gate)

If the deal requires any connectivity (data sharing, shared services, shared customers), identity and security controls become the first gate.

Ask one question: what is the earliest date we can safely connect environments? Then test it with evidence.

If/then triggers:

If the buyer’s endpoint tooling can’t be deployed quickly, plan for delayed connectivity or a segmented “clean room” data approach.
If logging coverage is incomplete, assume incident risk during integration and budget remediation as mandatory one-time spend.

2) Core systems and “process gravity” (the synergy gate)

Fast-cycle diligence should identify the systems that the business can’t change quickly without breaking operations: ERP, order-to-cash, WMS, CRM/CPQ, billing.

The question is not “what systems do you have?” It’s what systems will be on the critical path for the deal thesis?

Examples:

Working capital improvement: close process, order/invoice data consistency, inventory accuracy
Procurement synergies: vendor master, approval workflows, catalog discipline
Cross-sell: customer master, account ownership rules, quoting workflow

Decision trigger: If the value plan assumes a lever moves in the first 2–3 quarters, diligence must prove the underlying data and workflows are stable enough to support it.

3) Interfaces and data flows (the hidden critical path)

The fastest way to miss a schedule is to ignore interfaces. Integrations are where “simple” becomes slow.

In fast-cycle diligence, you don’t need every interface. You need the top set that represents business-critical flows:

order entry → fulfillment → invoicing
customer updates → billing/collections
ERP → reporting/BI
identity → critical SaaS apps

If/then trigger: If no one can produce an interface inventory or name the business-critical feeds without guessing, assume the integration/separation path will take longer and cost more than the plan.

4) Capacity to execute (the resource gate)

Even when the tech is fixable, execution fails when the team is already at capacity.

Fast-cycle diligence should answer: who will do the work, and what stops them from doing it? That means:

internal team bandwidth (not headcount)
dependence on a small number of contractors or one vendor
whether the business is already mid-stream on a major program (ERP upgrade, data migration, security remediation)

Cash-setters: three numbers you need before you sign

Fast-cycle diligence should force three numbers into the model while it can still move.

1) Normalized run-rate IT cost (not the budget)

Budgets are political. Run-rate is economic.

Normalize around:

outsourced services and shadow contractors
non-recurring project spend that’s actually “keep the lights on”
cloud cost trend (last 12 months) and what drives it (usage, data egress, poor tagging)
license true-ups and renewals in the next 12 months

Decision trigger: If IT cost is a material part of gross margin or the cost-out plan, get the cloud bill export and top vendor contracts early. Interviews won’t find the offsets.

2) Mandatory one-time cash (Day-1 and the first 100 days)

This is the money you will spend even if you don’t “transform” anything: stabilize, remediate, stand up, document, test.

Common buckets:

security baseline (MFA, endpoint, logging, privileged access)
separation stand-up (if carve-out): identity, network, ERP access, new tooling
data cleanup required to run finance and reporting reliably
short-term continuity workarounds (parallel run, temporary integrations)

3) TSA and exit cost (if a carve-out is involved)

In fast-cycle carve-outs, the TSA is often the biggest hidden cost driver and schedule constraint.

If/then triggers:

If TSA < 9–12 months, treat identity, ERP access, and interfaces as first-class diligence topics. “We’ll exit post-close” is not a plan.
If the TSA has hourly caps, fee escalators, or vague service definitions, assume your true cost will exceed the headline number.

How to get real depth quickly: the “evidence pack”

Depth in fast-cycle diligence comes from high-signal artifacts that compress uncertainty. Ask for a small evidence pack early and build your analysis around it.

In the first 48 hours, ask for:

top 15 applications by business criticality (or IdP/SSO app list as a proxy)
interface list for the 10–20 business-critical data flows (even if incomplete)
month-end close calendar and the top manual steps/known failure points
cloud cost export (last 12 months) and the top 10 cost drivers
top 20 vendors/contracts by spend, including renewals in the next 12 months
last external pen test summary and vulnerability scan summary
security tool coverage snapshot (MFA, EDR, backups, logging)
incident/problem summary for the last 6–12 months (top categories, major outages)
IT org chart including contractors and key vendor dependencies

You can run interviews in parallel, but interviews should explain the artifacts, not replace them.

Decision trigger: If the seller can’t produce the evidence pack, you are not “going faster.” You are signing with a lower standard of proof.

A practical depth decision tree (so you don’t “boil the ocean”)

Use deal facts to decide where to invest depth.

If the deal thesis depends on early integration (first 6–9 months):
Go deep on identity, security controls, network boundaries, and business-critical data flows. Assume everything else is phase two unless it blocks connectivity.

If the deal is a carve-out with tight TSA terms:
Go deep on TSA scope, exit triggers, ERP access, identity, and interfaces. The separation path will be your critical path, not “future transformation.”

If the business is software/SaaS or gross margin sensitive:
Go deep on cloud unit economics, architecture constraints that drive cost, and the release/incident posture. A “modern stack” can still have margin-destroying cost curves.

If the business is regulated or sells into security-sensitive customers:
Go deep on security baseline, audit findings, and customer security requirements. The risk is not just an incident; it’s stalled revenue because you can’t pass customer diligence.

If you can’t get depth anywhere due to access constraints:
Narrow the Day-1 posture (delay connectivity), increase contractual protections, and fund a post-signing confirmatory plan with explicit gates.

What goes wrong in fast-cycle diligence (and why)

Fast-cycle failures are predictable.

Pattern 1: The checklist trap

Teams try to cover everything equally. The output becomes a list of observations, not a set of decisions. The deal team hears “green” because nothing sounds fatal. The clock and cash risks are still there; they’re just not named.

Pattern 2: Interview optimism replaces evidence

Management believes the story they’ve told themselves: “tech is fine,” “we’re mid-migration,” “security is mature.” Without artifacts, fast-cycle diligence becomes a narrative review.

Pattern 3: The vendor report becomes a shield

Vendor reports are useful inputs. They are not underwriting. They rarely answer buyer-specific gates (connectivity readiness, TSA exit feasibility, synergy timing constraints).

Pattern 4: Findings don’t change terms, timing, or resourcing

The diligence team finds real issues, but the deal still signs on the original timetable with no added funding, no contractual protections, and no change in Day-1 posture. The issue doesn’t disappear; it shows up post-close as a schedule slip and unplanned spend.

What best-in-class teams do in 10–15 days

Best teams treat fast-cycle diligence as an underwriting sprint, not a research project.

Start with the model, not the checklist. Identify the 3–5 value levers with timing commitments and ask what systems and controls gate them.
Run a “gates session” in week one (deal lead + finance + tech). Write down the required Day-1 posture, earliest safe connectivity date, and TSA exit posture (if relevant).
Use the evidence pack to do depth-by-exception. Go deep where artifacts show anomalies (cost spikes, repeated incidents, missing controls, fragile close).
Quantify the three numbers and force them into the model. Normalized run-rate, mandatory one-time, and TSA/exit cash. If the model can’t absorb them, it’s better to learn that before sign.
Translate findings into an explicit posture. Delay connectivity, fund remediation, re-sequence value levers, or renegotiate TSA terms. Ambiguity is the enemy.

What to do in the next two weeks (owners included)

If you have a fast-cycle diligence window, these actions protect outcomes.

Write the one-page “clock and cash” brief (deal lead + tech DD lead). Top value levers, timing assumptions, and the 5 gates that must be true.
Pull the evidence pack in the first 48 hours (tech DD lead). If you can’t get it, treat that as a finding and adjust posture/terms.
Decide deep dives by day 3 (deal lead + CIO/security lead). Pick the 2–3 areas where depth changes the sign decision (identity/security, ERP/core systems, interfaces, cloud cost).
Force three numbers into the model by end of week one (finance + tech DD lead). Normalized run-rate, mandatory one-time, TSA/exit cash (if carve-out).
Convert findings into gates and protections (integration/separation lead + deal counsel). Define what must be true by Day 1, what you will not connect until controls are met, and what protections you need if evidence is missing.

Speed is not the enemy. Unpriced uncertainty is. Fast-cycle tech diligence works when you go deep where the deal is sensitive and you sign with an explicit posture, not a hope.