Document all communications and actions during the incident. Use this documentation to generate a post-mortem report for stakeholders. Meet with stakeholders to review the incident, its resolution, and preventive measures. Assure steps are taken to prevent recurrence. Impact: What systems, users, or business functions are affected? Timeline: Estimated resolution time, if known. Progress: Actions taken and next steps. Mitigation: Workarounds or temporary fixes, if available.

Organizational communication should be centralized and categorized based on key areas such as HR, executive strategy (CEO), team-specific matters,... and technical system issues. This centralization should align with the company's culture, ensuring that designated (online) platforms/pages are regularly checked before engaging support services. Technical issue-related communication should be consolidated within this central platform, with functionality to filter by impacted business applications. Achieving this requires a well-documented and mature enterprise architecture to support streamlined communication. Updates are to be supplied by the incident manager.

The first and most important thing to do is to inform your stakeholder of system downtime, now depending on your SLA with your stakeholders would you be able to determine the nature of information you give to them about your critical crash as not all information can be divulge to certain stakeholders, while you have to offer full disclosure to other stakeholders. Most importantly is to protect your Organization, by divulging only necessary information to specific stakeholders , while you rectify the issues.