How to conduct a postmortem that makes a company better

Ray Umerley knows how to ask and answer tough IT questions.

In 2019, following a malware and encryption incident, Umerley, then a chief data protection officer at shipping-technology company Pitney Bowes, had to explain impact and root cause to stakeholders and the public—a process that he admitted felt “uncomfortable at times.”

Now a field CISO at cyber extortion and ransomware-remediation company Coveware, Umerley also saw that occasionally uneasy examination at his former employer as a positive one; the event led to additional cybersecurity resources, for example.

Umerley sees postmortems as a helpful way for companies to emerge from IT emergencies with a stronger posture: “It’s really about deconstructing this [incident] to make sure that whatever happened, we can be better the next time.”

IT postmortems reconstruct events, assess impact, find broken processes, and set an improvement plan. But when IT leaders examine root causes, they face the challenge of finding answers without crushing morale or making people afraid to speak up.

Blame game. A June 2026 report from cybersecurity software firm Bitdefender revealed that more than half (55.2%) of 1,200 surveyed global IT and security professionals said they were told to keep a breach confidential.

Regulations like the SEC’s 2023 cybersecurity disclosure laws and the European Union’s Digital Operational Resilience Act (DORA), the Bitdefender report argues, have established a positive baseline, but company culture has lagged behind policy changes.

“Regulations set the floor, but changing behavior may require making disclosure feel less punishing,” the 2026 study read.

Cybersecurity company VikingCloud’s July survey of 200 US and European security and IT professionals found that 47% of incidents went unreported because of fear of professional repercussions, like personal reputational damage or difficulty finding future employment.

John Mumford, president and chief risk officer at cybersecurity consultancy Fellsway Group, likes to set a tone of openness early on when dealing with a tense room. He lets them know he has made his share of mistakes, including clicking a phisher’s URL.

“I don’t want the organization to feel so petrified they can’t put their fingers back on the keyboard,” Mumford said.

Today’s rapidly changing technologies call for steady, reliable teams, Mumford added. He recommends companies anonymize individuals when reporting root cause, as well as present any remedial training in private.

To both understand processes and prevent a situation that looks like a cop-show interrogation, Jason Lewkowicz, global cyber resilience and defense lead at tech consultancy Accenture, likes to bring in a full team at once; the “democratic” approach often leads to colleagues playing off each other.

Hearing from people with different responsibilities provides more context and reveals additional issues to investigate, Lewkowicz told us: “Things end up working a bit faster, and you end up getting better insights.”

Good question! Blame game aside, a team performing a postmortem still needs to understand root cause and impact accurately. To get at the question of what happened, Umerley likes to ask “5 whys.”

Why, for example, did ransomware deploy? If it’s because a server got accessed: well, why? If it was because of stolen credentials via phishing message, why did those credentials provide such deep access? And so on; there’s always room for more questions.

This approach, he said, helps teams push past the superficial answer for the reason something went wrong.

“Eventually, what you end up getting to is really this thought process that none of this was inevitable,” he said. “A lot of times when you do those postmortems, it just falls on, ‘Well, we didn’t patch the system,’ or ‘somebody clicked a link.’ There’s a lot more reasoning behind it.”

Mumford likes to ask: What information were you not able to obtain or provide, so a better decision could have been made? Also: What were your out-of-band communication strategies, and did you follow them? (Mumford sees communication, and alternative communication paths, as a “critical” aspect of incident response.)

Lewkowicz has a question that hopefully eases an atmosphere of blame: What did you do right? Positive actions could include a fast response from the security operations center (SOC), or a speedy return to uptime.

“It keeps the conversation a bit balanced,” he said. “If they’re all sitting back and they’ve got their arms crossed, to me that’s a sign that the temperature in the room needs to be calmed and cooled a bit.”

Going forward. Lewkowicz also recommends that companies use a postmortem to establish measurable benchmarks of progress: quantity of internet-exposed systems, time to detect an intrusion, and completeness of a configuration management database (CMDB).

Umerley has a non-technical recommendation: lead with empathy. That tactic makes sense, given he knows what it’s like to be questioned and to now be the one asking questions.

“Having been in those shoes, it helps me now,” he said, “to just be calm, understand where they’re coming from, recognize what they need, and how can we help navigate that.”