Reputational Risk

Reputation went unmanaged for a long time. There is no line for it on a financial statement and no way to count it, so it was treated as something you either had or didn't. When an incident happened, the cost of fixing it got calculated and the way it was communicated did not.

In a business selling to other companies, though, trust functions as a purchase requirement. Someone evaluating software doesn't only look at the product; they ask the companies already using it. How the vendor handled the last outage, whether it gave notice before raising prices — those questions are part of that conversation. Reference calls are no formality in enterprise deals: one hesitant answer from an existing customer can stall a contract for a month. Once trust cracks, the sales pipeline drying up and job applications falling off tend to happen in the same quarter.

A familiar scene: a four-hour outage, followed three days later by a two-line notice. Nobody said much at the time. Six months later, during renewal talks, the customer's procurement lead cited that outage while asking for a discount. The loss showed up as a number on renewal day, not on the day of the outage.

Reputational risk is the name that puts that delayed loss on the table in advance.

Something triggers it, the response over the following days hardens into an interpretation, and that interpretation spreads into sales and hiring. What distinguishes this risk is that the aftermath decides the outcome more than the event does.

1. A trigger appears. Some are unintended, like an outage or a security incident. Others the company chooses itself — a price increase, a change to the terms of service. The second kind is the easier one to overlook.
2. The first few hours set the direction. While a company says nothing, a gap opens, and people outside it fill the gap. If the company doesn't explain what happened first, guesses become the explanation.
3. The interpretation hardens. Sentences left in forum threads and search results stay readable for years once they settle. Facts assembled later never travel as far as the first version did, and a forum post from two years ago still outranks the follow-up nobody shared.
4. It spreads. Diligence questions on new contracts multiply, renewal talks hand the other side another card, and fewer people apply to the same job posting. Diligence questions going from ten to twenty while applications halve is the usual shape, and the fact that all three move at once is what this risk looks like.
5. Recovery is asymmetric. Losing trust takes a day and rebuilding it takes quarters, which is why spending on the response on day one always ends up cheaper.

This is why two outages of the same size end differently. A company that says what happened, who was affected, what it will fix and by when, all inside the same day, later cites that response as evidence of how it operates. A company that posts two lines three days later hands the same event over as a bargaining chip.

On a risk list it occupies one row, but it's harder to score than the other types. The size comes out large while the likelihood resists being turned into a number. Unlike an item such as regulatory risk, which has an effective date attached, this one arrives without notice, so checking whether the response is prepared works better than estimating a probability. Some companies drop the probability column on this row and keep a readiness column instead: whether a named spokesperson, a notice template, and a deadline for the first statement all exist.

The place preparation actually attaches is the incident response procedure — deciding in advance who says what and when. That is crisis communication: assembling and delivering a position once something has gone wrong. Drafting the wording after the incident starts is already too late, so the shape of it gets built ahead of time.

After an outage, how much of the postmortem to publish becomes a decision. A postmortem is the record that traces an incident back to its cause and lists the fixes, and it's normally an internal document. For companies with enterprise customers, publishing a summary of it often protects trust better than keeping it inside.

Planned decisions get reviewed through the same lens. When raising prices, when you give notice and how you explain it shape the reaction more than the size of the increase does. A company carrying customer concentration risk — revenue leaning on a small number of accounts — has more reason to be careful, because one unhappy account moves a large share of revenue.

"The outage isn't the problem. Saying nothing for three days is. That's reputational risk."

Pointing out that the damage came from the silence, not the incident.

"The price notice needs the wording and the timing reviewed together, not just the percentage."

Arguing that triggers a company creates for itself belong under this risk too.

"In this market, if five customers know, the whole industry knows."

Word travels at a different speed in a narrow market.

Pagedeck had an outage that left documents unopenable for four hours. While questions poured in to Sofia, Theo tracked down the cause, and Grace posted a notice the same evening once service was back. Four paragraphs: what happened, which accounts were affected, what would be fixed, and by when.

Two days later a summary of the postmortem went out alongside it. No customer churned at that quarter's renewals, and one customer's legal team used that document to clear its own internal review. It was a case of the response building reputation rather than the incident taking it away.

The most common mistake is treating this as a communications problem. The word reputation sits close to publicity, so it sounds that way. But what people read from outside is the output of the product and the operation, and better wording doesn't cover it. Leave that assumption in place and the cause goes unfixed while the notice gets polished — and after the same thing happens twice, a well-written notice becomes evidence against you.

Reading it as something that only arrives with a major incident is nearly as common, because the name sounds like it points at an event. In practice it accumulates from small things. Support replies that run two days late, a billing error once a quarter: none of that gets recorded as an incident, yet all of it comes out when a customer describes you to another company. A useful test is whether a customer asked to describe you in one sentence would mention any of it. Count only large incidents and you conclude there is nothing to put on the table, while the risk keeps accumulating unmanaged.