¿Cómo comunica la gravedad y el impacto del incidente a la alta gerencia?

You may end up with a final classification on a standard scale, such as low, medium, high, or critical but before you get to that there are a considerable number of factors to consider that will depend on the size and nature of the business. It is a good idea to prepare by considering the types of incident you are likely to encounter and also consider how those incidents can escalate depending on how and when they are discovered and dealt with.

Effectively communicating security incident severity and impact to senior management is crucial for ensuring they understand the significance of the incident and can make informed decisions about response and mitigation efforts. Here are some steps to help you communicate security incident severity and impact to your management: - Understand the Incident before communicating it - Assess Severity and Impact - Use a Standardized Framework - Prepare a Briefing Document - Tailor the Message and focus on the releveant information - Provide Context and Analysis - Present Options and Recommendations - Highlight Follow-Up Actions - Address and be prepared for Questions and Concerns - Follow-Up Communication

Incident Communication to Senior Management involves the following steps: • Define roles and responsibilities in incident reporting. • Collect information about the incident, its impact, and containment efforts. • Emphasize business impacts like financial losses, reputation, or operational disruption. • Keep language clear, concise, and quantify the impact. • Maintain transparency and honesty. • Structure communication into a sequence: brief description of incident, severity, immediate actions, technical details, impact, containment measures, and next steps. • Maintain regular updates and post-mortem analysis.

Incident assessment is crucial, whether in a post-sales, technical support situation or a pre-sales - trial/demo support situation. In the technical support case, it may make the difference between engaging the right SMEs )subject matter experts) and solving the problem before is being escalated to next management level on the customer side. In the pre-sales case, it makes the difference between continuing to stay in the game in a bake-off or parallel trial scenario - or not. In my experience, the customer is not looking for a fix on the spot (although that is welcome): is evaluating the pre-sales response, based on which is evaluating the vendor culture and post-sales response.

In Banking services, one method of incident classification is basis Priority- Critical, High Priority, Moderate and Low. Ultimately the Priority decision is the outcome of the severity of the incident through the measure of three primary parameters - Financial loss, Reputational damage and Safety risk. Basis the mix of the 3 parameters, the prioritization is determined and then the response time is allocated. Response time for critical incidents are immediate i.e, within minutes; few hours for High priority cases; few days for Moderate cases and so on. So proper assessment of the incident plays a major part in a smooth closure of the incident.

Assessing the severity and impact of an incident is paramount before initiating any communication. This evaluation allows organizations to gauge the level of harm and disruption caused, enabling them to tailor their response accordingly. By using standardized scales and predefined criteria, such as low, medium, high, or critical, organizations can classify incidents effectively. Additionally, considering the urgency and priority of the incident ensures that response efforts are timely and focused on mitigating the most critical risks. Effective incident assessment sets the foundation for clear and informed communication, guiding stakeholders through the incident response process with transparency and efficiency.

In my experience in several tier 1 telecom vendor companies, for technical support incidents there are well established practices on when and how issues are communicated to upper management, both informally - as "heads-up - this may hit the fan but not there yet" as well as formally - when specific management layers are involved. In these cases, outages most often imply liquidated damages with nominal monetary values. The more interesting part is in pre-sales situations or even internal situations where issues are being seen and not treated with utmost urgency, because there is no perceived revenue "loss", as in the case above. My personal experience has been mixed, from: "the pond is full of fish" in NORTEL days- to focus on improvements.

Respecting the chain of command and authority is the one of the important steps while communicating any incident. In my years of experience in service industry, I have seen many employees who out of nervousness, frenzy, fear etc. tend to forget this basic courtesy of respecting the chain of command and this leads to lot of friction within the team which adds more salt to the wound in the overall process.

After assessing the incident, selecting the right communication channel for senior management is crucial. Factors such as urgency, sensitivity, and complexity play a role in determining the most suitable method. While urgent matters may necessitate a direct phone call or text message, detailed reports or emails could be more appropriate for less pressing issues. It's essential to consider the preferences and availability of senior management, ensuring effective communication and timely response. Adhering to established escalation procedures and respecting the chain of command maintains clarity and accountability throughout the incident response process.

Knowing your audience is crucial. For a Post-sales, tech support incident an Operations manager will look for different, more technical info than an SVP that looks at the business outcome. For pre-sales, for any incident IMHO is good to project the same info you would provide in a post-sales tech support incident, even though there is no formal contract with that customer. Running them through the issue solving (even in a lab trial) the same way you would do with a paying tech support customer is the difference between buying or not.

Honesty is the best policy here. Only facts to be presented supported by evidence. Suggested action plan should naturally follow the S.M.A.R.T way. S=Specific Action; M= Measurable; A= Achievable; R=Realistic and T= Timeliness.

As an Australian Incident Manager fresh to working in an American company, i find huge value in asking for feedback on comms, not necessarily related to the technicalities of the incident, but language and tone. Small differences in phrasing and even spelling, can make a lot of difference.

As a vendor, LISTEN. It is amazing the amount of information our customer volunteer to us, to make both their life (as operators) and our life (as vendors) better. Do not cut off socializing time. It is amazing how much you find out over a burger and a pint. Operations folks are a the salt of the earth and a fountain of wisdom. Ask as many questions you can think of, and be prepared to answer the same. That what make the vendor representative a trusted advisor. Do not be afraid to recommend a 3rd party for capabilities your company does not offer. Who knows - that may become a solution alliance partner once the solution is being forged out.