Cybersecurity Across the Investment Lifecycle

In a transaction, the technical asset is usually described in a language that never reaches the committee. Architecture, technical debt, security posture and dependencies become an annex — read by few, translated by nobody — while the decision is taken in price, timing and condition.

The translation exists and it is direct: technical exposure is value exposure. It changes price, because it changes the risk being assumed. It changes closing conditions, because part of it has to be resolved first. It changes what can be integrated and how quickly. And it changes what can be sold on, because the next buyer will ask the same questions with more information. What varies across the lifecycle is not the importance of the subject. It is the question.

A technical diligence that returns a list of findings did not serve the decision. There is no useful answer to the question of whether a company is secure, and insisting on it produces a report nobody can act on. The questions that produce decisions are different: what it would cost to bring this asset to the standard the thesis requires, expressed as work and as time; which obligations are inherited along with the purchase, including contractual commitments to customers, regulatory requirements and responsibilities over data; where the concentration sits — one person, one vendor, one environment nobody knows how to rebuild; and what state identity and access management is in, because that determines the cost and the timeline of every subsequent integration.

The output of that is not an opinion. It is a set of items that converts into price, into a condition precedent, into escrow, or into a post-close plan with an owner and a date. When that conversion does not happen, the risk does not stay neutral: it stays embedded. And a buyer who cannot assess it assumes the worst, which is also a way of being wrong — this time at the seller's expense.

Technical risk that cannot be assessed does not sit neutral in the price. It becomes a discount, or it becomes a surprise.

The period immediately after closing is the only one in which changing how the company works is expected by everyone. After it, every change starts costing political capital, and the cost rises each month. That is why the window is decided by sequence rather than by completeness: what can only be done now comes before what can be done at any time.

What the window is for shares one characteristic — everything in it is the foundation of something else:

• —Identity and access, because every integration, every separation and every later control depends on knowing who is who.
• —Ownership of the critical systems: for each one, a person who answers for it, rather than a team that maintains it.
• —The incident path, walked once before it is needed — who is called, with what authority, and what that person is entitled to stop.
• —An inventory of what exists: dull, always deferred, and the silent dependency of the three items above.
• —Untangling whatever remains attached to the seller — shared accounts, common infrastructure, transition services with an end date — because the date arrives and the coupling does not.

During the hold, the thesis gets executed, and every move in the thesis alters the exposure. Add-on acquisitions multiply identity systems and introduce environments nobody on the buying side has seen. Entering a new territory adds regulatory obligations that change what may be stored and where. Volume growth makes what was sufficient inadequate without anything breaking — and that variety is the hardest to notice, because it generates no event.

The practical conclusion is that security posture has to be a function of the operating plan, not a fixed programme running alongside it. A programme that does not change when the company changes is, by construction, protecting last year's company. This is also where the exit is built: the questions a buyer will ask are known years in advance, and it is cheaper to be able to answer them by construction than to assemble the answer under a transaction timetable.

At sale, everything that could not be answered at purchase comes back as a question, now asked by someone with the time and the incentive to press. What gets examined is predictable: ownership of intellectual property, including what third parties produced and what arrived through open dependencies; licensing hygiene; data provenance, with growing attention to whatever fed a model; the ability to demonstrate controls rather than assert them; and the incident history, together with how each one was handled.

That last point is widely misread. An incident handled competently, disclosed to whoever was owed disclosure and documented, is rarely what reduces the price. What reduces it is the incident that appears during diligence without having appeared before — because from that moment the buyer is no longer assessing the incident, they are assessing what else might not have been said. Exit diligence is scored on the ability to demonstrate, not on the state itself.

This work carries an obvious temptation: to produce comfort. A reassuring report is easier to sell than a usable one, and the cost of comfort only appears later, once it has already been priced in. We refuse a few things in writing, and it is worth naming them:

• —We do not certify that an environment is secure. That is not a claim engineering can support.
• —We do not execute anything against an environment without scope and authorisation agreed in writing, including when the transaction timetable is the argument.
• —We do not deliver a finding without a path. A report nobody knows how to turn into work is transferred debt.
• —We do not state an impact on value that we cannot derive from what was observed. Where the derivation does not exist, we say so.

Cybersecurity across the investment lifecycle is not a service that shows up before closing and disappears afterwards. It is the same reading of the same system, taken at four moments where the right question differs. The continuity between those moments is most of the value, and it only exists when the reader is the same.