Impediment Removal Team (part II)

This is continued from Thoughts of an Agile Coach (Part I). 

Here's what happened two days ago:

First, let me start with some background. At the most recent Impediment Removal Team (IRT) meeting, one of our strongest scrum masters raised an impediment that the QA environment her team uses is unstable, to such an extent that it crushed in a middle of her team's demo. She circulated a list of 7 distinct instances related to management/stability of  this environment that happened within 2 weeks prior to IRT meeting. In the instance of ruined demo, for example, the team found out that URL was changed to this environment by some other team without notifying them. It was an obvious communication issue, so at the IRT meeting, we decided on two action items:

1. Streamline communication related to environments management. Update the environments ownership list on wiki and communicate to all teams. Keep updating the list at least 24 hours to every change.

2. Notifications on any work in QA or staging environments have to go as e-mails to the team's distribution list, not just the dev lead who may be on vacation or unavailable.

This was straightforward, we got the list updated, provisioning policy re-circulated, and I thought this closed communications part of this item.

What is my concern though is that I was unaware of what happen after IRT meeting. I thought we came up with action items to improve communication and streamline environment ownership. I made sure these action items were completed and felt good about the work done. 

Here's what I came to know. After the IRT, the scrum master was accused of escalated unnecessarily before talking to the right person. She felt horrible and told me that her IRT experience was totally negative and she will never bring any item to IRT attention again because it ends with her being accused of escalating without reason. 

 I could not believe it - I pride IRT for being aimed at resolving impediments while keeping root cause analysis out of scope (it gets frequently implied in the action items, but this is not the goal) - we are targeting impediment removal and we are good about it. This was my principle.

Anyway, I am facing a dilemma now:

1. Ignore this case, too late anyway (has been a week already), one party undercommunicated, another party did not pay attention. Going forward, I will make sure that at the meeting, I explicitly make a statement of the goal and ask for any cases of finger pointing rather than productive issue resolution be reported to me directly.

2. Do the root cause analysis and find who is in fact responsible. There are a lot of things that sound wrong in the "communicated but ignored by the team" theory. However, I won't understand better until I dig deeper. If I do, it will be about finding who made the mistake and blame for the wrongdoing. This would mean be contrary to what I believe in, but it would help the scrum master who has been accused of miscommunication. Should I?