The Cloud Provider's Email That Changed Everything Overnight

The situation

The email arrived at 11pm on a Tuesday, three lines long, from the cloud infrastructure provider the startup relied on to host its customer data. It described, in vague terms, 'unauthorized access to a subset of systems' and said the provider was 'investigating.' It did not say which systems, whether the startup's data was among those accessed, or when more information would follow. Bohdan read it first and forwarded it to Aram and Hagop within minutes, and the three of them spent the rest of the night trying to figure out what they were actually allowed to ask for.

The startup, built around a scheduling and records platform used by physiotherapy and rehabilitation clinics across the region, had grown quickly over about two years, from a founder-only operation to a small team handling a meaningful volume of clients' health-adjacent scheduling data. Bohdan had spent years as a physiotherapist before starting the company and Hagop had trained as an actuary before joining as the numbers and operations lead, and the two of them, along with Aram running product and engineering, had built the business on the understanding that the cloud provider they used, one of the larger infrastructure vendors in the space, was reliable enough that they had never seriously negotiated the fine print of its standard contract.

That contract, like most agreements offered by large infrastructure providers to companies the size of this one, gave the startup almost no contractual right to be told anything specific about a security incident. It obligated the provider to comply with law where legally required to notify, and otherwise left disclosure entirely to the provider's discretion, with no defined timeline, no requirement to specify which customers or data types were affected, and no obligation to provide detail sufficient for the startup to assess its own notification obligations to its clinic customers.

By the next morning, a second, equally vague email arrived saying the investigation was 'ongoing' and that the provider would 'provide updates as appropriate.' Bohdan, Aram and Hagop realized they had no way to tell their own clinic customers anything meaningful, no way to know whether they had their own legal obligations running on a clock they could not see the start of, and essentially no contractual leverage to demand better information from a vendor many times their size.

The problem

The core problem was not the incident itself, which turned out, over the following weeks, to have affected a narrow slice of the provider's infrastructure that did not include the startup's data. The core problem was that the startup had no way to know that quickly, and no contractual right to demand a faster or clearer answer. A company handling clients' scheduling and health-adjacent information has its own responsibilities if that information is compromised, responsibilities that depend on knowing, promptly, whether a breach touched its data at all. The provider's contract simply did not give the startup the information it needed to meet obligations that were, in a real sense, still the startup's own.

When we reviewed the contract in detail, the imbalance was stark. The provider was a large, well-resourced infrastructure company with standard-form terms it offered to thousands of customers, most of them far smaller than the provider itself. The startup, even having grown to a meaningful size, was still a small account relative to the provider's overall business. That mismatch mattered directly to the legal strategy, because a contract negotiation is never just about what terms are fair in the abstract, it is about what leverage exists to actually get better terms, and a company this size negotiating with a provider this large has real limits on what it can demand unilaterally.

The provider's public position, communicated through its account team once we raised the issue formally, was that its standard security and notification terms applied uniformly to all customers at the startup's contract tier, and that customizing terms for individual smaller accounts was not something it did as a matter of policy. This was not said aggressively, but it was said plainly, and it was true: the provider had far deeper resources to simply decline the request and let the startup either accept the standard terms or migrate its infrastructure elsewhere, an option that was theoretically available but would have cost the startup months of engineering time and real risk during the transition.

The strategic question was therefore not simply what terms the startup should ask for, but how to get a provider with that much leverage to agree to anything better than what it offered everyone else, without a negotiation that either failed outright or dragged on long enough to leave the startup exposed on the next incident before better terms were in place.

What we did

1. Reviewed the existing contract's security and notification provisions in full. We identified precisely what the provider was and was not obligated to do, including the gap between its legal notification obligations, which are triggered by specific circumstances, and what the startup actually needed to meet its own downstream obligations to clinic customers, which was a lower bar than the contract currently guaranteed.
2. Assessed the startup's own legal exposure arising from the incident and the information gap. Before negotiating anything, we needed to know what the startup itself might be required to do if the breach had affected its data, since that shaped both the urgency of the negotiation and what specific information rights actually mattered most. A company that cannot tell its own customers what happened cannot meet obligations that depend on knowing, which meant the negotiation had a real deadline behind it, not just an inconvenience to fix eventually.
3. Escalated the request beyond the provider's standard account team. Given the provider's stated policy against customizing terms for smaller accounts, we advised Bohdan to request a conversation with a more senior contracts contact rather than continuing to negotiate with the account representative, who had no real authority to deviate from the standard template. Negotiating with someone who cannot say yes wastes time and signals the request is not being taken seriously, so reaching the right person mattered as much as what was actually asked for.
4. Framed the request narrowly around notification and information rights rather than broader security guarantees. Asking a large provider to rewrite its entire security posture for one small customer was unrealistic. Asking for a defined notification timeline and a minimum level of incident detail was a narrower, more specific request the provider could grant without treating it as a precedent affecting its whole customer base.
5. Proposed a defined notification clause specifying a maximum number of days to notify, and a minimum set of details to include. The draft required the provider to confirm, within a set window, whether the startup's specific data had been affected, without demanding the granular technical detail the provider had legitimate reasons to withhold during an active investigation. Asking for confirmation rather than a full technical postmortem kept the request realistic, since an unrealistic demand gives a large counterparty an easy reason to refuse the whole request outright.
6. Negotiated over several weeks as the provider pushed back on setting any precedent. The provider agreed in principle relatively quickly but resisted specific numbers, and resisted putting the commitment in the master agreement rather than a side letter. We accepted a side letter, since it bound the provider just as effectively, in exchange for firmer numbers than the provider's first offer.
7. Accepted a modest fee increase and a longer renewal term as part of the final deal. The provider was willing to grant the improved terms but tied them to a two-year renewal commitment and a small increase in the monthly service fee, framed as the cost of a non-standard arrangement. We advised the founders this was a reasonable trade given the alternative of switching providers entirely.
8. Documented the startup's own internal incident response steps to run alongside the new contractual notification window. Better notice from the provider is only useful if the startup can act on it quickly, so we helped set out, in writing, who at the startup would be notified, and what internal steps would follow within the newly defined window. Without that plan, a faster, clearer notice from the provider would just have produced a faster, clearer version of the same confused scramble that followed the original 11pm email.

The outcome

The provider agreed to a side letter guaranteeing notification within a defined number of days of confirming an incident affected the startup's data, along with a minimum set of details about what was affected. In exchange, the startup accepted a two-year renewal commitment and a modest increase to its monthly service fee, an increase that, given the startup's revenue in the high single-digit millions, amounted to a manageable but real ongoing cost rather than a token concession.

The original incident, once the provider's investigation concluded roughly three weeks after the first email, turned out not to have touched the startup's data at all. That outcome was fortunate, but it was not the point of the negotiation. The new notification terms exist for the next incident, not this one, and Bohdan, Aram and Hagop were candid with themselves that they had negotiated from a position of real weakness against a much larger counterparty, and had paid, in fee increases and a longer commitment, for protection that a company their size arguably should not have had to negotiate for at all.

The founders came away from the experience with a changed approach to vendor contracts generally. Every new infrastructure or data-handling vendor the startup has signed with since has had its security and notification terms reviewed before signing, not after an incident forces the question, and two vendors have been rejected in favour of alternatives specifically because they would not negotiate meaningful notification terms even for a modest fee. The cost of the original gap was real, in money and in a stressful week, but it did not repeat.

Aram, who had pushed hardest during the negotiation for the provider to commit to specific numbers rather than vague assurances, later described the two-year renewal commitment as the part that stung the most, since it meant the startup lost some flexibility to shop for a better deal or a better platform in the near term in exchange for information rights it felt it should have had for free. Hagop, working through the numbers, calculated the total added cost of the fee increase over the two-year term against what a serious, undisclosed breach could have cost the startup in its own downstream notification obligations and client trust, and concluded the trade was still worth making, even if it was not the outcome any of them would have chosen if the provider had simply offered fair terms from the start.

What you can learn from this