Security Debt Belongs in the Underwriting Model

Security debt is not a technical footnote. It changes purchase price, integration cost, insurance, execution risk and the credibility of the investment thesis.

The answer

Identity weakness, unsupported systems, fragile architecture and absent recovery capacity are not technical footnotes. They change remediation cost, management attention, integration timing and the probability of achieving the investment case.

Security debt is usually discovered in diligence and then quarantined inside a technical report. The report lists unsupported systems, weak identity controls, incomplete asset records, fragile backups, unresolved findings and over-privileged vendors. The investment model continues to assume the same integration timetable, operating margin and exit path. That separation is irrational. Security debt is a claim on future cash, management attention and strategic freedom. It belongs in underwriting.

Not every weakness is debt

A missing control is not automatically a material financial problem. The useful question is whether the condition creates a probable obligation, constrains the thesis or increases the severity of a plausible loss. Security debt becomes economically relevant when it requires one or more of the following:

  • Immediate remediation to preserve insurability, licensing, customer confidence or safe operation.
  • Delayed integration, product launch, data migration or market expansion.
  • Replacement of systems that cannot support the future operating model.
  • Retention of scarce staff or vendors whose undocumented knowledge keeps the environment alive.
  • Acceptance of a loss scenario not reflected in price or reserves.
  • Restrictions on connecting the target to the buyer’s identity, data or network.

This definition prevents a long list of hygiene observations from obscuring the few conditions that can change the deal.

Convert findings into economic objects

For each material condition, create an underwriting object with:

  • Exposure: the business process, asset, revenue stream or obligation at risk.
  • Failure scenario: the credible event the weakness enables or worsens.
  • Remediation path: containment, replacement, migration, redesign or contractual transfer.
  • Cash requirement: internal and external cost, including licences, specialist support and disruption.
  • Time requirement: duration, critical dependencies and the management capacity consumed.
  • Residual risk: what remains after the planned work.
  • Deal implication: price, escrow, warranty, covenant, condition, integration sequence or walk-away threshold.

A red finding without this translation produces anxiety, not a decision.

Model three numbers, not one

A single remediation estimate encourages false precision. Model:

  • Containment cost: what must be spent immediately to prevent inherited risk from compounding.
  • Structural correction: the cost of reaching the control state required by the investment thesis.
  • Failure cost: the range of consequence if the condition is not corrected before a credible event.

Then attach timing. Ten million spent over three years is different from ten million required before integration. A control gap that blocks a revenue synergy is more expensive than the remediation invoice.

Watch for thesis collisions

The most dangerous debt is not always the oldest or most severe technical issue. It is the issue that collides with the reason for buying the company. If the thesis depends on rapid cross-selling, weak identity separation may delay customer and sales-data integration. If it depends on international growth, data location and vendor architecture may create legal and operational friction. If it depends on automation, undocumented processes and poor source data may make the AI programme unsafe or useless. If it depends on margin expansion, a brittle legacy platform may require parallel operation longer than forecast. Diligence should state these collisions explicitly. “High risk” is less useful than “the proposed integration creates a shared identity blast radius before the target can support the buyer’s required controls.”

Do not let insurance replace engineering

Cyber insurance can transfer parts of financial loss. It cannot restore a missed transaction, rebuild trust on demand or make an unsupported system integrable. Premiums, exclusions, security conditions and coverage limits are themselves affected by the quality of the environment. Treat insurance as one instrument in the capital structure of risk, not as evidence that the underlying condition is acceptable.

Put debt into the deal documents and the first hundred days

Where the issue is material, the underwriting response should survive beyond the diligence presentation.

  • Define closing conditions for exposures that cannot safely transfer.
  • Use specific warranties, disclosure schedules or indemnity structures where appropriate.
  • Reserve budget and named management capacity.
  • Sequence integration around containment gates.
  • Retain evidence and test completion, rather than accepting a vendor’s “remediated” label.
  • Revisit the thesis if structural correction changes the expected economics.

The investment committee question

Ask: if we owned this company tonight, which technical conditions would alter tomorrow’s cash allocation, integration sequence or risk appetite? Those conditions belong beside working capital, customer concentration and legal exposure. Security debt is not an annex to the underwriting model. It is part of what is being bought.

Sources

  1. NIST: Cybersecurity Framework 2.0NIST: Cybersecurity Framework 2.0

    Primary authority

  2. FINMA: Risk Monitor 2025FINMA: Risk Monitor 2025

    Primary authority

  3. Swiss NCSC: Current threats affecting companiesSwiss NCSC: Current threats affecting companies

    Primary authority

Ross BelhommePartner, Svperior / Legal

Jonathan P. De Collibus

Jonathan co-founded Svperior in 2014 and leads its cyber practice. His work sits where adversarial pressure, technical architecture, and consequential decisions meet, with experience across clinical, financial, public-sector, and private-client systems where confidentiality, continuity, and technical correctness carry material consequences.

Cyber strategy / Adversarial assessment / Security architecture / Private systems

Need to apply this to a specific situation?

Send us the initial context. If the matter fits, we will respond directly.

Send private inquiry