Day 32 - What Should I Make Public?
Last Updated: 2008-11-03 15:34:20 UTC
by Koon Yaw Tan (Version: 1)
We have now completed the recovery phase. What's next? Before we call it a day, we should look back to what has really happened. Is there anything that can or should be improved? This is not meant to be finger pointing phase but rather what can be done better to prevent incidents from happening again.
For the next three days, we will cover the lesson learned. For a start, we talk about what should make public. Incidents could be caused by human mistakes. It is also never a good pleasant experience to disclose what has happened too. Sometimes you also have no choice as the incident could already make public. It is therefore important to be prepared what information should make public.
What would you want to make public? Have you ever over disclose or under disclose information? How much is consider good enough? Do you have any experiences to share? Please send your suggestions to us.
From one reader:
The public message that you give out in the event of a data breach or other IT disaster is extremely important and is often overlooked. If you have a marketing/communications department, then they need to take the lead in conjunction with IT and legal. I think these basic rules are important:
1) Do not lie. Note that this is not the same as disclosing 100% of what happened, but what you do choose to disclose must be the truth.
2) Be consistent. Do not say one thing then another. If in doubt, say nothing and get back to them.
3) Inform everyone. If the nature of the problem has become public, you should tell all staff how they should respond to inquiries, and who they should pass queries to.
4) Come up with an action plan. If there are potential ID theft victims, then determine how you will deal with that and make it public. If other sensitive data has been lost, explain how you are going to prevent it from happening again. You need to convince people that it is not going to happen again.
Did I mention "do not lie"? That's the #1 rule for a reason.
From another reader:
From the standpoint of someone not in the Incident Response field (right now), I would hope that the team makes the basic facts of the case public. They don't need to go overboard, but they should at least hit the highlights.
Things like a general description of what happened, amount of records (or files) that were compromised, how long were the records exposed, and that everything is back up and running.
During the incident, they should just make a blanket statement about upgrading systems, and then release the facts after it's fixed.
One thing that should be emphasized is this: Make sure that EVERYONE who is going to have public access to media, blogs, or web sites has their ducks in a row. The Best Western Incident this year is an example of not following this advice. One person said it's millions of records, while someone else says it's 120 records at the most. Everyone needs the same story, so things don't get confused.