Communicating after a data breach

As the recent issues around the pre-release of Budget 2019 details have shown, good communication after a security incident is crucial. Poor communication will make the situation much worse.

Treasury appears to have made a few mistakes:

  • They rushed to explain how the data breach happened. They would have been under pressure, with far more media focus than most organisations who suffer a breach. However, it would have been better to say that they were still investigating how the breach happened, rather than jumping to a conclusion that was proved to be wrong
  • They stated that they had seen 2000 attacks on their website. Unfortunately this made them sound naive. Websites and servers connected to the Internet are under constant attack from automated scripts as well as more targeted attacks. Once again  waiting for clearer details before communicating would have been better. It was in fact 2000 searches via the publicly available search function on their website
  • They stated that they had been hacked, and that they had referred the matter to the police. Once again, this was premature. They had not been hacked, the data breach was caused by misconfiguration of IT systems by Treasury, and the police have confirmed that no crime has been committed and they have closed their investigation
  • They provided inaccurate information to government ministers who then relied on it when communicating to the NZ public

The above are additional to the mistake that caused the breach – a misconfiguration of their website (which indexed the cloned website containing the Budget details).

So how can your organisation avoid making these mistakes?

  • Make sure you have an incident response plan. This sets out how to respond to various security incidents (including a data breach), who to communicate to, when to communicate, and issues to watch out for
  • Test your incident response plan using a table top exercise. This involves running through an example incident with the management team, making decisions on actions and communication. It’s best to get an external party to run this exercise for you. It will highlight any gaps in the plan, and ensure that when a security incident does happen, the organisation has practised it’s response and will be more likely to minimise the impact
  • Ensure that there is a focus on securing any confidential or personal data that could be accessed via the Internet. This includes development and test versions of websites and systems, that often have a lower level of security than production or “live” systems. Security review and testing should form part of any major changes, rather than being an annual event


If you’d like any help with creating or reviewing an incident response plan,  running a table top exercise, or reviewing the security of your organisation’s systems then please get in touch.

%d bloggers like this: