After the Breach

Editor’s note:Most security writing is about threat vectors. This story is about something harder: convincing an organization that transparency after a breach builds trust. It is an argument most companies are afraid to make publicly.

In January 2025, a mid-size developer tools company discovered that one of their API authentication services had been leaking partial tokens in error logs for approximately six weeks. The actual security impact was limited, the token fragments were not usable for authentication. But the disclosure decision, made by their security team in the forty-eight hours after discovery, is worth examining closely.

They published a detailed incident report within seventy-two hours. The report named the specific service, described the exact log pattern, gave a precise timeline, and included the three architectural decisions that had contributed to the condition. It also described, in engineering detail, every remediation step they had taken and three systemic changes they were making to prevent recurrence. The post was written by the security engineer who found the issue, not by a communications team.

"Every word of that post was a choice," says the engineer, who asked not to be named because she has since moved to a different company. "We chose specificity over vagueness. We chose to make ourselves accountable to a standard that future incidents would also be measured against. That is harder than writing a generic apology."

The response from their developer community was striking. Despite the disclosure (in a different era, many companies would have quietly patched and said nothing), the company saw its trust ratings in developer surveys go up in the quarter following the incident. Not down. Up.

This is the phenomenon that a cohort of security leaders is beginning to study and deliberately engineer. The security team's function is shifting from "prevent bad things," a posture that treats security as a cost center trying to minimize exposure, toward "build the infrastructure of trust," a posture that treats how you respond to bad things as a core part of the product.

"The firewall is a feature," says Taiwo Adeleke, head of security at a cloud data platform. "Trust is the product. And trust is built in exactly the situations where most companies go quiet."

The technical dimensions of this shift are real. Companies that treat trust as a product invest differently: in observability tooling that makes incident timelines reconstructable, in documentation practices that make disclosure possible without requiring heroic effort, in communication infrastructure that lets engineers speak directly to customers rather than routing everything through legal review.

The harder part is cultural. Treating incident response as trust infrastructure requires leaders who are willing to be specific about what went wrong, which requires a level of organizational psychological safety that many security teams do not have. The security engineers doing this work well tend to have built credibility with their leadership over years, and spend a lot of that credibility on exactly these moments.

The alternative is the playbook most people recognize: a careful statement acknowledging that security is taken very seriously, a commitment to notify affected users as required, and a conspicuous absence of any detail that might be used to hold anyone accountable. It is effective in the short term. In the long term, it is not a product.

A breach isn't the crisis. Every company will have one. The question is whether people trust you after.