Public Communications for Cyber Security Incidents

A framework for organizations

Created and published by the FIRST Cybersecurity Communications Special Interest Group.
PDF Version

Acknowledgements

The original version of this framework was based on the work of Richard Knight (University of Warwick) and Jason Nurse (University of Kent) ¹.

It was refined by CERT NZ using information from interviews conducted with New Zealand-based organizations that had been the target of cyber security incidents. I would like to thank them again for sharing their experiences.

The report was internationalized for FIRST using examples taken from various national CSIRTs. It was then edited and refined by the FIRST Cybersecurity Communications Special Interest Group (SIG).

About this Framework

This is a guide for an organization to create a plan for public-facing communications in the event of a cyber incident.

The Framework gives a way of formalising and constructing decision-making on when to communicate, with whom and at what level, as part of an overall incident response plan.

International version

The first version of this framework was created for New Zealand as part of CERT NZ’s advice for organizations. Subsequently it has been adopted by many international organizations and, as such, an internationalized version was required.

This is a living document, which means it will be updated and adapted as required for various audiences. Each major revision will be given a new version number. (See Appendices for revision changes.)

This document is written in US English.

Basic structure

The framework follows this construction.

• Roles and responsibilities of responders.
• Decisions on the type of incident and how to respond.
• How to create and disseminate communications for greatest effect.
• Post-incident work.

• Examples are given throughout and supplementary materials – such as templates and exercises – can be found in the Appendices.

Roles and Responsibilities

This section covers the steps to take when an incident has started or you receive a report of an incident ² that you are in control of. The roles and responsibilities of team members should be determined well ahead of time and listed in your overall incident response plan.

Communications lead

The Communications Lead (Comms Lead) will be aware of all communications between internal teams or out to external stakeholders. This includes executive teams, government officials, media, the public and any other stakeholders.

This role is essential to ensure a clear understanding of which groups have which pieces of information.

Choosing a Comms Lead

• The Comms Lead does not have to be a communications expert.
• You can have two leads for internal and external communications.

While it is preferable for the Comms Lead to have some communications skills, it is not a necessity. However, the creation of clear, pre-agreed response plans means the Comms Lead can be from any area. External incident response teams (including national CSIRTs) should be able to offer communications assistance for the creation of messages.

The Comms Lead does not necessarily need to be making decisions about the content of the communications or see every email or text message but they will need to know the communication has happened.

Depending on organizational structure, the Comms Lead may not be the final sign-off for certain communications. For example, a formal letter to a government Minister may require CEO or executive level sign-off. However, the Comms Lead will ensure all required edits and changes are made before sending to that final level.

Similarly the role can be split across functions. For example, external communications could be run by a communications expert while internal communications could be run by HR.

In terms of incident response chain of command, the Comms Lead usually sits at the same level as technical response and logistics leads, reporting directly to the Incident Response Coordinator.

Comms Lead responsibilities before the incident

• Understanding all of the formally required communications should an incident occur ³.
• Managing a list of known stakeholders and the preferred method of contact.
• Managing a secondary mode of wide-band communication for internal staff should normal communications be unavailable (such as a Signal group or text messages).
• Maintaining a set of ‘standing lines’ that can be sent to stakeholders and internal staff, if required ⁴.
• Managing the members of the organization who will be spokespeople, should the need arise – this includes ensuring they have adequate training and support for that responsibility.

Comms Lead responsibilities during the incident

• Clear knowledge of which stakeholders have which pieces of information.
• Altering the communications approach as the incident changes over time.
• Sign off on wide communications to stakeholders (for example, an email to all customers).
• Reporting to Incident Response Coordinator.
• Managing incoming communications.
• Monitoring media and social media (if required).

Who are your stakeholders?

Stakeholders is the term we use to refer to anyone with a connection to the organization.

The list of stakeholders will be determined what type of incident has occurred. It can be as broad as everyone who has contact with the organization or as few as internal staff.

As part of creating your communications response framework we recommend doing an audience mapping exercise to determine who your audiences are on a normal basis and the best ways to communicate with them.

A guide for this exercise can be found in the appendices.

Decisions

The Comms Lead needs to make the following decisions throughout the incident.

• What information needs to be communicated and when?
• What regulatory disclosures need to be made?
• Which audiences need which pieces of information?

They may not be able to answer these immediately and as such will require information updates during the incident.

Info gathering

The Comms Lead needs the following information as soon as possible. This can come from the wider Incident Response (IR) team or as part of the Comms Lead’s monitoring role.

• What type of incident is it?
• Who is affected? (Clients, public, specific agencies etc)
• How widespread is the incident? (Localized, industry specific, regional, national, international etc)
• Is there an immediate impact on clients, agencies or the public?
• Is the risk level increasing over time? / Has the incident been contained?
• Is the incident being reported by the public/journalists/experts in media/social media?
• Are reports being made from clients/users to your organization?
• Has the organization been contacted by the attacker? / Has the attacker made themselves known publicly?

What you don’t know is sometimes as important as what you do.

At the start of an incident, it is likely some of these pieces of information will be unknown, and that should be noted as well. As the incident progresses more information may be added that will affect your decisions.

What information needs to be communicated and when?

The matrix below is used to determine a communications response to an incident. Each of the four quadrants – based on risk to stakeholders vs visibility – has a different communications approach. These quadrants and how best to approach each one, are outlined in the Order of communications section below.

Figure 1: Stakeholder risk vs visibility matrix for cyber incidents with example incidents

The information gathered by the Comms Lead in the initial stages of incident response allows them to place the incident into the matrix. This is not an exact science and it’s a good idea for the Comms Lead to agree on the placement with other response team leads.

Responsibilities

Disclosures to Police, financial organizations, government agencies, and oversight groups may need to be done immediately.

These steps could already be part of the standard incident response plan and may not require your communications team. However, the Comms Lead should be aware of what has been reported and where. This information may be used in communications with stakeholders.

Applicable laws

There will be laws and policies that your organization or the affected organization will have to comply with during an incident. This may include mandatory reporting to government or law enforcement.

The Comms Lead should have contacts at all of the organizations with applicable laws.

Privacy:

Many countries have laws covering data protection and information privacy. If you are involved in a data breach or other incident where data has been exposed, then you need to be aware of the exact wording of these.

Some considerations need to be taken as transmitting any sensitive information to an external party can lead to this information being made public – either inadvertently or as part of the legal process.

However, it is good practice to report any breach or potential breach, regardless of the level of severity, even if you are not sure if it meets the criteria of the law. Doing so, gives greater reassurance to your stakeholders. You can work with your contacts at the relevant agency to discuss the details of formal reporting.

Financial laws:

Your organization may be legally obligated to report to the stock exchange, shareholders or other authorities depending on the incident type.

Criminal and anti-terrorism laws:

You may be based in a country that has laws about funding criminal or terrorist activities. As such, advice about paying ransoms need to take this into consideration.

Applicable international laws and agreements

It’s rare, but possible, that your organization may be bound by international agreements or laws. This can include information sharing agreements between organizations. It’s a good idea to be proactively aware of these.

Internal policies

Your organization may have agreements in place regarding communications about significant incidents with suppliers, distributors, unions, etc. These can be helpful in framing your message, as you should have clear parameters of disclosure.

Voluntary disclosure:

There is a growing practice of organizations choosing to communicate beyond what's required by law. This can be a good way to build credibility and trust with your stakeholders.

The core argument behind this idea is that voluntary transparency is harder to fake and therefore more persuasive. Organizations that communicate proactively, consistently – and before they're forced to by legal requirements – build a different kind of stakeholder relationship than those that don't. This also follows an operating principle of "communicating by default".

This can be a difficult practice to implement as the response is usually “why say something if I don’t have to?” The answer, as with most communications, is that it raises trust levels. Again, the communications need to be balanced to ensure no personal information is given out or anything that could hinder the response, however, “getting out in front of the story” is a well-known communications tactic.

Note: this does not mean to immediately report an incident to the public when affected parties are still unaware, but to be proactive and open with your disclosures.

Cyber Insurance

If you have cyber insurance, you will have reporting responsibilities to your insurer. They may also offer specific help with external communications and reporting.

How to create a message

“organizations that take responsibility and are seen to be proactively trying to address the problem are perceived in a positive light.” – Richard Knight and Jason Nurse ⁶

This is the part of the process that can be intimidating to those without a background in communications. However, by following the steps outlined in this framework and preparing standing lines and mapping your audiences, this can be a smooth process with few worries and you will see the preparation pay off.

These messages are a chance for your organization to demonstrate competence, reinforce stakeholder trust, and shape the narrative via well-crafted disclosures.

Things to consider

Internal and external stakeholders will get different messages, simply because they need to know different pieces of information.

When creating the messaging for external communications, you need to cover a lot of points while also being easy to understand and clear about what the next steps are.

• Create a balance between clear information that stakeholders need to know, while also keeping specific information confidential to not entice further attacks.
• Do not say anything you may have to retract later.
• Anything you say to stakeholders has a chance to be reported in the media, consider everything to be public messaging.
• Media may come to you with queries before you have a chance to communicate with stakeholders.
• If your external stakeholders receive information about the incident via third parties, such as the media, before hearing from you, they are more likely to be negative towards your message.
• In certain cases your organisation may be obliged to provide up to date information about the availability of your services (see example below).

AI use

Just like learning any new skill, creating messages will take practice. Resist the urge to use AI if possible, especially if you’re starting out. While AI can be a helpful tool in incident response, learning with AI or giving it full control over your messaging can lead to an overly generic tone and voice from your organization.

People are getting better at recognizing AI-generated text, and it can come across as less personal and even potentially uncaring or insensitive. For example if you are a stakeholder who has had information stolen, you might take exception to a message generated by a computer.

For more generic communications, such as warnings of new threats or vulnerabilities, AI generated messages can speed up your processes.

Availability heuristic

The availability heuristic is people’s tendency to act off information that easily comes to mind. In this context, we know that people start taking cyber security more seriously when they hear of an incident ⁸.

This can impact your communications as recipients are:

• more likely to take actions on cyber security
• less likely to click links
• more suspicious if the email doesn’t come from a usual source
• likely to try to corroborate via another source.

Resist the urge to create a bespoke email address for the incident. While the message can come from your CEO (or similar), it should be sent out via usual channels.

Balancing the message

While you need to communicate clearly about what happened and will be happening, there is a very real risk that the attacker may use your communications as a signal to start a new phase of the attack or double down on their efforts.

This is where being linked into the technical side of the incident response becomes incredibly important. Early information gathering allows you to craft the proper messages for the situation.

• What type of incident has occurred.
• Gives you a good idea on what the future timeline will look like in terms of resolution and impact on stakeholders. Also you can decide what level of information to release about the incident.
• If the incident is ongoing ⁹.
• You may not be able to say much, and what you can say will need to be more cautious.
• What steps have been taken to mitigate or solve the incident.
• Giving clear examples to stakeholders of what has happened gives them greater trust in you. However, revealing too much information will tip off the attacker.
• What other organizations are involved in the response.
• Explaining that other experts are involved, especially government, gives higher levels of trust to your communications. In general a National CSIRT will not say publicly if it is involved, however, asking them to do so can help take pressure off your organization.

Keeping control of the message

You are not required to respond to any media queries, however, while it can seem like a good idea to decline them or otherwise downplay an incident, you run the real risk of losing the message to other commentators.

Having a set of pre-prepared statements for media queries is a good start. Even placeholder statements are better than silence.

While these seem cliché, they show that you are aware of the problem. They are a temporary solution; you won’t get away with these a few days into the incident. Resist the temptation to describe a cyber attack as an unexpected technology failure or glitch, or something easily fixed.

Any update on the situation is better than nothing. With no official comment journalists will go to other sources; this can lead to speculation and incorrect statements about the situation. Updates can be sent either as a full press release or via social media.

Order of communications

The type of incident will direct who you communicate with and when. The more serious and public facing the incident is, the sooner you will need to go out with some kind of message.

Using the diagram of risk vs visibility, you can sort incidents into four categories, which are listed in increasing risk and urgency for communications.

Figure 2: Stakeholder risk vs visibility matrix putting cyber incidents into quadrants

1. Low risk and less visible to the public. Direct communications may not be needed. Can be addressed via social media or website.

2. Low risk but visible to the public. These can usually be communicated via a written statement or media release. The scale of the outage may determine the timing, but these can usually go out without needing to delay.

3. High risk but low visibility to public. Initial communication directly to stakeholders should occur as soon as possible after discovery. A public disclosure must follow but can be done at a later date. Monitoring should be kept up to measure public visibility.

4. High risk and visible to the public. You will need to communicate quickly but cautiously. This can mean a short message to stakeholders to start, followed by messages over a longer timeframe. Media releases/responses will need to be short on details. Standing lines should be a priority.

Remembering that every message you send has the chance to be made public, so even internal communications should be cautious with details.

Internal communications

Internal stakeholders will need to know what is happening. This will usually occur directly after the Incident Response team is stood up.

Depending on the event, this message will need to explain:

• what internal systems have changed (eg. email),
• how to engage with external stakeholders,
• what staff data may be at risk, and
• what systems are in place to support affected staff.

External stakeholders

If external stakeholders are affected, they should be contacted as soon as possible, determined by the scale of the incident.

Depending on the event, this message will need to explain:

• what external facing systems are available,
• what data may be at risk,
• what systems are in place to support stakeholders and where they can go for more information.

The messaging will be pared back, however, as mentioned above in the section on balance. As part of this process, it may be necessary to stand up a call centre or provide extra staffing for your existing contact portal.

This communication is usually done in the form of email, however, physical letters can be sent as well, depending on the audience.

Media release/queries

The more public facing the incident, the more likely you will need to put out a press release or respond to inquiries from media.

Any direct communication with media should always be done at least a day after communications have been sent to any affected stakeholder groups, to allow for delays in delivery. While it can be difficult, direct media queries should be put off with prepared statements.

It is totally acceptable to not do a press release. If the story hasn’t already been picked up, then there is no need to further spread the message.

Social media/website

These can go out at the same time as press releases or in lieu of one. For incidents with lower risk to stakeholders these can be used as a vehicle for your main message.

What should the message say?

This is the crucial part. Your message needs to be clear and concise but also empathetic. Some of this section may seem basic but others have fallen into these traps.

A good message will provide the information stakeholders need to protect themselves and will demonstrate that you are doing your best to address the situation.

The subject line

If you are contacting stakeholders directly via email, you need to ensure they read your message. This is tough because you need to create a subject line that sounds urgent without scaremongering or sounding generic.

Remember that people can receive dozens of emails every day from various organizations, yours may get lost.

There is no easy solution for this, sadly. There will always be those that ignore the message in their inbox. For this reason you should consider other paths for your message, such as social media.

Accept responsibility

You are the caretaker of your stakeholders’ data. This means you will need to offer an apology. The form of the apology will differ from country to country and with different audiences.

While it feels like you have been attacked by an external party or let down by a flaw in a piece of software, your stakeholders will want to hear an apology from you.

Even when stakeholder or customer is at fault (for example through password reuse) you will be expected to have mitigated through monitoring or another control.

Avoid downplaying

This may be perceived as not taking the incident seriously. While you do not need to give the exact extent of the incident, it is unwise to use words like “only” or “just”.

This will also help you if the incident is larger than initially thought.

Address feelings of vulnerability

Depending on the type of incident your stakeholders may feel vulnerable and worried for their security. This is especially so in cases where they could be individually identified.

It is a good idea to list steps that stakeholders can take to protect themselves in the wake of the incident, the more people can do for themselves the more they feel secure. This can include:

• contacting other agencies (such as the national CSIRT, their banks, or the government’s Privacy agency),
• changing passwords on their accounts, or
• enabling two-factor authentication.

If the incident involves finances, you can offer credit monitoring or other services for free.

Remember that the recipients may be reluctant to click links.

Avoid blaming others

Blaming other parties can be seen as an attempt to dodge accountability. This includes cases of employee error. While a single person may be the cause of the incident, blaming them will be seen as poor organizational culture.

If the incident was caused by a known hacking group, do not name them or mention this at all. Doing so gives the group media coverage that they will use to gain notoriety and advertise their abilities.

If the incident was due to a service partner, refrain from apportioning blame to them publicly. You can sort out issues behind the scenes, as any public disagreements will result in damaged reputation for both parties.

Keep the message clear and easy to understand

Chunking the information into smaller pieces makes it easier to understand but also lessens the chances that the recipient becomes overwhelmed with the information. ¹¹

Avoid jargon and keep everything simple. Don’t use a multi-syllabic word when a shorter one will do (for example, “utilize” instead of “use”). Longer, and more formal words can seem like you are trying to hide something.

For explaining aspects of the incident, you may need to dip into technical terms, however, keep these to a minimum and instead refer to other spaces (such as an explainer on your main website).

Avoid the message damaging your credibility

While this may seem obvious, too many times a message can inadvertently cause damage to your reputation down the track.

Often this is due to an underselling of the severity of the issue, an omission of key information or a falsehood that must be retracted.

You can omit incident response steps in your message in order to simplify the message and keep information out of the hands of threat actors. But conversely it can make it sound as though your organization is not doing a thorough job or has an incomplete plan. If you can say everything without compromising the message’s balance, then it is better to do so.

Consider stakeholder characteristics

Depending on who your stakeholders are, you may need to alter your message, both in content and format. For example, some people are less likely to read emails and may prefer receiving a text message (from a legitimate source).

Similarly different groups of people may ignore calls to change passwords or take other steps to boost their own security. They may see it as a hassle or even as your responsibility.

Adding a “why” element to the steps can help this.

Other organizations

It may be that many organizations in your area are being affected by the same incident. You may consider doing a joint statement with them to show that you are not the sole target. This also allows you to pool resources.

Beyond the message

Remember that the message will likely generate questions from stakeholders – even if you think you’ve covered them all, they will still come up with new ones.

Ensure your staff, especially those who deal with external stakeholders, are across the message and know what to say. This can include a list of key messages and answers for obvious questions that can be quickly responded to.

Updates

Depending on the incident, “after the event” may not be after a month or two, it may, in some instances, be ongoing. This means you may need to send updates for a long time. These should be short and kept to essential communications only. If an investigation is continuing, then stakeholders can expect to be updated.

There is also a chance the incident could flare up again (for example, a DDoS attack) or another incident could happen if attackers think you may be vulnerable. So be prepared to cover that scenario.

After the event

This is the section of your communications planning that can be the most important. The goal is to help your organization use the incident as a capability-building event, not just something to close out and forget about. This is a chance to review and evaluate your previous preparations and to improve your ability to respond in the future.

Debrief and review

As with any part of an incident response, a debrief on how the communications went is essential. Part of this is to review your process, updating as required and pinpointing areas that can be improved on.

Some questions to consider as part of the review:

• Was your stakeholder or audience mapping accurate?
• Did your standing lines work?
• Which lines did you use and do you need to take them out of the rotation or change them?
• Did your Comms Lead have all the information they needed?
• Did the sequence of communications match the incident or how you planned it?

In some cases this may mean re-running some of the exercises, such as audience mapping, with any new information or lessons you have learned. This can also be a chance to refocus efforts, for example, if you spent a lot of time checking FAQs for the helpdesk but noone called through, then you can deprioritize that in the future.

You may want to talk to stakeholders, internal and external, to see how the message was received and what could be done better next time. If you use analytics on your emails you could look to see how many emails were opened, you can look at traffic statistics for any webpages you may have set up for the response. We would not recommend using social media comments as a reliable measure for feedback.

Admin tasks

After an incident a lot of things need updating. For communications we recommend checking this list and making changes as necessary.

• Stakeholder contact details: update with current information, including changes of staff and notes about if and how they may have been affected during the incident.
• Standing lines: change to be better aligned to any audience changes, and refresh any you have used so you don’t repeat the same messages for every incident.
• Website: update your website as necessary with relevant information. If you have added information regarding the incident, review and decide if it needs to stay up.
• Processes: ensure any changes made as part of the review are reflected in internal policy documents, especially reporting lines and responsibilities. This allows for better business continuity should there be staff turnover.

You may wish to create reminders to check these periodically or to update them when you do the regular review of your overall incident response plan.

Appendices

1. Version history.
2. Audience mapping exercise.
3. Standing lines.
4. Real examples.

Version history:

Version	Date	Notes on changes
1.0	02/2024	First finalized version of the template.
1.5	01/2025	First draft with international content.
2.0	05/2026	Finalized international version with full appendices and examples. Changed to US English.

Audience mapping exercise

This can be used to create a greater understanding of your audiences. We have added examples into the template.

1. Use the Audience column to list every audience you communicate with. Resist the idea of condensing groups, in the initial steps it’s best to have more entries. You can sort them by categories to help organize and summarize especially for the final step.
2. The Medium column lists all the way your organization communicates with those audiences.
3. Voice and Tone are the ways you write or construct your messages and are descriptive of the type of language you use.
   a. Voice is how you always communicate. This means you will likely want to use words such as “professional” or possibly “official”. This is also where you list the ways you should avoid. This likely includes being rude or blunt, but depending on your organization may also include things like “humorous” or “condescending”.
   b. Tone is how you sometimes communicate. For example, you might always be professional, however, in some cases you might be friendly, in others you might be technical. Think about the difference in talking to teachers and students – your voice and message will be the same to both parties but your tone will be very different.
4. The final step is to map across the columns. Linking each audience to the mediums and tones you will use.

Audience	Medium	Voice (always)	Tone (varies)
Board Regulators Government Financial Shareholders Customers Vendors Contractors	Email In-person Text messages Website Social Reports	Professional (but not formal) Expert (intelligence) Knowledgeable (wisdom) NEVER Condescending Overly technical Distant Scary	Friendly Technical Succinct Human – talking to a real person Informal Simplistic Empathetic

These are examples only and it is a good idea to fill out this table with as many team members as possible.

Standing lines

The following are examples to use to answer certain questions. We do not recommend using these exactly as written but change them to suit your own style, tone and language.

In general it is best to avoid using words like “hacker” or “attack” as they can cause some audiences to panic or raise further questions you may not be able to answer at the time.

What is happening? (if you do not have any information)
Note: the use of “attack” is fine, but can cause some audiences to panic unnecessarily.

• We are currently experiencing an outage and are investigating the cause.
• We are aware that there has been a technical incident and our response team is working on it.
• At this time we are unsure of what is affecting our systems, however, our teams are working hard to resolve the issue and we will update you when we know more.
• We are aware that there has been a cybersecurity incident and we are working on resolving it as soon as we can. We are aware of a disruption to our systems, we believe it may be a cybersecurity incident. We have contacted the [national CSIRT] are currently working to resolve the issue and will update you as soon as we know more.
• [specific example] Our systems are currently experiencing a DDoS attack. While this is keeping our [website/app/etc] offline, we are working to ascertain if any client data has been affected.

When did this happen?
Note: the exact time of the incident doesn’t need to be shared, you can simply use the day or month if it occurred a long time before discovery.

• We believe the incident began on [day]. Our security team began investigating and restoring services from back-ups. We are reaching out to you now as we have a greater understanding of what has occurred.
• [specific example] A data breach of our systems was discovered on [day], we are currently investigating and determining what data has been compromised. We will advise you as soon as we know more. In the meantime we recommend you… [information from national CSIRT or other trusted source].

What kind of attack is it? (if known)
Explain the type of attack broadly speaking without specifics and link to a trusted official site for more information.

Who did this?
Your audience will, in general, not get any useful information from knowing who is behind an incident. Moreover, naming a threat actor can make them more likely to continue their attack for future influence.

• At this time we are solely focussed on restoring your data and protecting it for the future. We are working with law enforcement and they will deal with attribution of the attack.

How did the attackers gain access?
Note: again do not give too much away.

• The investigation into the attack is ongoing and we will be conducting a thorough assessment of the potential access points for the attackers.

What data was accessed? (in the case of a data breach)
Remember the rule to not say anything you may need to retract.

• At this time we are working through our systems to determine what information the attackers may have been able to access. We will notify affected people when we learn more.
• We know the attackers were able to access [list of data types]. Because of this we recommend affected users take the following steps…

Real Examples:

Communications strategy

This was created for an international company that suffered a ransomware attack. It has been anonymized.

Message to affected parties (1).

This example is taken from a data breach involving a tertiary education provider. It has been anonymized for this document. The audience is the students whose records were stolen.

Message to affected parties (2).

This is the text of a message sent to users of Ticketek in Australia following a data breach. This is an excellently constructed message often used as an example of best practice.

• First paragraph explains the situation. It’s a bit long but it gives a good summary.
• Second paragraph explains that your payment information is safe, giving reassurance and setting expectations. Remember that to say this, you must be certain about what data is affected.
• Third paragraph explains what happened but does not blame the provider. Also sets out why you are being contacted.
• Fourth paragraph discusses who the team are working with giving further reassurance.
• Fifth paragraph is placed inside a separated section to show it is important. This gives a clear description what data has been impacted.
• Sixth paragraph also starts with a new section which is what users should be doing. It begins with a clear apology for the incident.
• Seventh paragraph does make one small mistake of linking to a pdf file. The file contained no new information, and asking users to open a pdf is not a good idea if you can simply add more text to your message.
• The final paragraph is important because this is where Ticketek funnels all the queries. They had set up a dedicated phone line and email address for the affected customers. Note: if you do decide to do this your helpdesk operators will need a set of lines to use.

---