A Napanee Manufacturer's Sale Nearly Undone by Shadow Software

The situation

The letter arrived by courier on a Tuesday, three business days before the scheduled closing. It came from outside counsel to Pooja, who owned a chain of clinics and had agreed to buy Kavya's manufacturing business for a price in the $50 to $80 million range. The letter was short. It said the buyer's technical diligence team had found something during a routine systems review and wanted answers before funds moved.

Kavya had built the business over two decades, growing it from a small workshop into a mid-sized manufacturer supplying several industrial customers across the region. The last eighteen months had been hard: a major customer had cut its order volume, input costs had risen, and cash flow had tightened enough that a sale, even at a discounted price, looked like the sound decision rather than the aspirational one. The deal with Pooja had been negotiated over several months and was structured as a straightforward share purchase, with representations about the company's systems, data handling, and compliance included in the usual way, the kind of language Kavya had signed without expecting it to ever be tested.

What the letter did not say, but what Kavya's operations lead Nasrin suspected within an hour of reading it, was which department had triggered the review. Nasrin ran the customer service function and had, roughly two years earlier, signed the company up for a low-cost scheduling and messaging tool that lived outside the company's approved software list. It held customer names, order histories, and in some cases payment references. Finance never saw the invoice because it was billed to a personal card and reimbursed through petty cash, a small workaround that had felt harmless at the time and had simply never come up again.

By the time Nasrin told Kavya what the tool was and how much customer data sat inside it, the buyer's diligence team had already found it independently, through a routine scan of network traffic and account logins across the business. The question was no longer whether the problem existed. It was how bad it was, whether the deal's financing timeline had any room left in it, and whether it would blow up a sale that Kavya's business needed to survive. Kavya spent that evening trying to remember every other tool any department might have adopted quietly over the years, aware for the first time that she genuinely did not know the answer.

What made this urgent

Three things collided in the same week. The first was the calendar: closing was scheduled for the Friday before a long weekend, and the buyer's lawyers made clear that funds would not move until the data question was resolved, holiday or not. The second was the representation Kavya had already signed. The purchase agreement included a standard promise that the company's data handling complied with applicable privacy obligations and that all software used in the business had been properly licensed and approved. Discovering an unsanctioned tool holding customer data, after signing that promise, put the truth of the representation itself in question.

The third was leverage. A buyer who finds a real problem three days before closing has two paths open to it: walk away, or use the discovery to renegotiate price and terms while the seller has almost no time to push back. Pooja's team did not threaten to walk, but they did not need to. The timing did that work for them. Kavya's business needed the sale proceeds to satisfy its lenders within a set window, and a delay of even a few weeks risked unravelling financing commitments on both sides of the deal.

There was also a substantive question that had to be answered honestly before anything else: how much customer data was actually exposed, to whom, and for how long. The tool in question was hosted by a third-party vendor with its own security practices, unknown to Kavya's business and unverified. Nobody could say with confidence, on day one, whether the data had ever been accessed by anyone outside the company. That uncertainty was the real problem. A quantified, well-documented issue can be priced. An open question with an unknown ceiling is much harder to negotiate around, and buyers price uncertainty conservatively, against the seller.

Compounding all of this, the long weekend meant that the vendor's own support staff, who would need to confirm what access logs existed and for how long, were largely unreachable until the Tuesday after closing was supposed to happen, leaving a full four days in which the company had no independent way to verify its own exposure.

Kavya also had to weigh a quieter risk: how the discovery would be read by the lenders whose financing depended on the sale closing cleanly. A deal that stalls for a data problem, even briefly, can prompt a lender to reconsider timing or terms of its own, and Kavya's business could not absorb a second source of delay layered on top of the one the buyer had already introduced.

What we did

1. Froze the timeline conversation before the technical one. Our first call was not about the software; it was to tell Pooja's counsel that Kavya intended to investigate fully and disclose accurately, and to ask for a short, defined extension rather than let the deadline force a rushed and incomplete answer. A hurried answer under threat of losing the deal tends to be an inaccurate one, and inaccuracy compounds legal exposure later.
2. Mapped the actual data held in the tool. We worked with Nasrin and an outside technical reviewer overnight to pull an inventory of what the tool actually stored: customer names, contact details, order history, and partial payment references for a defined customer set. Knowing the real scope, rather than the feared scope, let us negotiate from facts instead of assumptions.
3. Contacted the vendor directly for access records. We reached the vendor's compliance contact through an after-hours channel and secured a written statement of who had administrative access to the account and whether any external access attempts had been logged. This took the worst-case scenario off the table in writing, which mattered more to the buyer's lawyers than our own assurances would have.
4. Disclosed the issue formally and completely. Rather than let the buyer's team keep finding pieces of the picture on their own, we prepared a full written disclosure covering what the tool held, how long it had been in use, who had access, and what steps had already been taken to lock it down. Complete voluntary disclosure changes how a buyer's counsel frames the conversation, from suspicion to negotiation.
5. Locked down the tool and preserved evidence. We had Nasrin restrict access to read-only for the transition period and export a full record of the account's configuration and history, so nothing could be altered, deliberately or accidentally, while the two sides negotiated. This mattered because any change to the account after the buyer's team had flagged it could look like an attempt to obscure the problem's scope, even if entirely innocent, and a preserved, time-stamped record gave both sides fixed facts to negotiate against instead of a moving target.
6. Renegotiated the representation and the price. Given the confirmed but bounded exposure, we negotiated a specific carve-out to the data representation, an indemnity capped and time-limited to this issue, and a price adjustment that reflected the cost of remediation and the residual risk, rather than an open-ended discount. Anchoring the adjustment to a quantified, documented exposure, instead of leaving it open for the buyer to estimate, kept the renegotiation contained to the actual problem and stopped it from becoming an excuse to revisit unrelated terms.
7. Built a short remediation schedule into the closing documents. We agreed a defined post-closing period during which the company would migrate the affected data into approved systems and formally decommission the unsanctioned tool, with the buyer's technical team given the right to confirm completion. Putting a firm deadline and a verification right into the closing documents, rather than leaving remediation as an informal promise, gave the buyer the assurance it needed to close on schedule and gave Kavya a clean point at which the issue would be considered fully resolved.
8. Ran a company-wide check for other unsanctioned tools before closing. Rather than assume this was the only gap, we asked every department head to confirm, in writing, every software tool touching customer or financial data. Doing this before closing, rather than waiting for the buyer to find something else on its own, caught two smaller, lower-risk instances that were disclosed alongside the main issue, which meant the deal closed on a complete and accurate picture instead of one that could unravel again after the money had already moved.

The outcome

The deal closed, ten days later than originally scheduled rather than not at all. Pooja's team accepted the bounded disclosure and the vendor's confirmation that no external access had occurred, and agreed to proceed on the basis of a specific indemnity rather than reopening the entire agreement. That was the best realistic outcome once the tool had been found; it was not the outcome Kavya would have chosen if the problem had never existed.

The price adjustment came to roughly the low six figures, applied against the purchase price to account for remediation costs and residual risk, plus a capped indemnity that survived closing for a defined period. Kavya's proceeds were lower than expected, and the ten-day delay put real strain on the lender timeline that had to be separately managed. Nothing about the outcome was framed, internally, as a win. It was framed accurately: a real problem, caught late, contained through fast and complete disclosure rather than allowed to sink the transaction.

In the months after closing, Kavya adopted a simple rule that had not previously existed in the business: any software touching customer information required sign-off from someone outside the department proposing it, logged in a single place finance could see. Nasrin, who had signed up for the tool in good faith to solve a real scheduling problem, was not disciplined for it; the absence of a policy, not her judgment, was the underlying failure. The lesson Kavya took from the experience was blunt: the representations in a purchase agreement are only as good as what the seller actually knows about its own systems, and closing week is the worst possible time to find out the gap. Kavya has since said, to anyone in a similar position who asks, that she would run the same internal check on day one of a sale process rather than day one of a crisis, if she had the chance to do it again.

What you can learn from this