[BreachExchange] Incident response plans must be tested, privacy conference warned
audrey at riskbasedsecurity.com
Wed Jan 31 20:41:16 EST 2018
A cyber incident response plan isn’t worth the paper it’s written on if it
hasn’t been tested, a Canadian lawyer has told a privacy conference.
“The significance of [having] a response plan clearly can’t be overstated,”
Adam Kardash, chair of the privacy and data management practice at Toronto
law firm of Osler, Hoskin & Harcourt, told the Canadian Institute’s annual
Privacy and Data Security Compliance Forum in Toronto on Tuesday.
But, he warned, if the response team hasn’t practiced what it will do –
either through a tabletop exercise or a real test – it isn’t worth much.
Many security and privacy pros know it, he suggested.
His firm has held incident response seminars with chief privacy officers
and regulators in the same room as a resource, working through potential
cases. Today over 90 per cent of privacy officers say they have a plan. But
when asked if they are confident the plan will work if there was a
catastrophic attack, “about half say they’d be confident — but we know
they’re lying because regulatory authorities are in the room, or it’s only
a discussion, or they’re rationalizing to themselves,” said Kardash.
“But if you talk to the top CEOs, CISOs they’re seriously going to question
if it’s going to work” unless the plan has been tested.
An exercise will help the IR team find out “tiny little things,” such as
managers who aren’t designated to be at the table but who should be. It
will also find major things: One test with a multinational company
Kardash’s law firm sat in on for saw that for the first hour it couldn’t
get the conference phone running – and once it was, people discovered it
wasn’t a secure line.
“There’s room for significant improvement for organizations in terms of the
operationalizing of these plans and testing these plans,” he said in an
He also told the conference that a key part of the IR plan is the
composition of the tea. “If there’s a good group around the table and they
buy in, it’s cross-functional and you really trust they’re not going to
cover their behinds in the wake of an incident, that they’re constructive
and engaged, you’re going to get good results most of the time.”
During his presentation he also talked at length about the coming final
version of the federal government of mandatory data breach notification
regulations. A draft version was released last September. Ottawa hasn’t set
a date but Karadash is betting later this year.
“We’re expecting it to have a pretty massive impact on the Canadian privacy
arena,” he said.
Organizations covered by the federal Personal Information Protection and
Electronic Documents Act (PIPEDA) will have to report all breaches of
security safeguards to the federal privacy commissioner, and, if they
involve the leak of personal information that could cause real risk of
significant harm also notify persons directly affected as well as possibly
Karadash noted that the definition of “significant harm” is open to
interpretation. The Office of the Privacy Commissioner has promised to
Regardless, Karadash predicted regulators will have a low threshold.
“Sooner is better,” he advised.
However, in an interview he dismissed a suggestion that “when in doubt,
report” is the best advice. “When in doubt ensure you have the appropriate
resources internally or externally [meaning consultants and/or lawyers] to
give yourself more comfort and then make a determination. Once you start a
reporting process there’s a whole bunch of consequences, from establishing
a precedent from what you’re going to do in the future to managing the
whole impact of a potentially very public incident.”
Keeping records of breaches “is going to cause a lot of indigestion,” he
predicted. The final version of the regulations will spell out how long —
the draft regs suggested two years.
Finally, he said a timely and sensitive response to victims after a data
breach will be seen favourably by a regulator, and, if there’s legal
action, by a judge.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BreachExchange