Thursday 29 March 2012

The hidden cost of breach notification

How many more staff might the Information Commissioner’s Office have to employ if the breach notification rules in that Regulation are actually implemented?

I’ve been doing some sums, and my calculations are pretty horrific. In fact, they’re so horrific that I’m looking forward to consulting the academic community to work out just what’s wrong with them. We’ve all known that the proposed rules are to place pretty onerous burdens on data controllers – but I hadn’t quite realised what the consequences might also be for regulators.

According to my calculations, the ICO might need to increase the volume of staff reviewing breach notifications by a factor of 15. So, they might need to increase a team of 10 to a division of 150. That means adding another floor to the ICO’s only recently extended office in Wilmslow. So much for efficiency savings by not needing so many staff for the Data Protection Notification Division. They’ll simply have to transfer them all to a Data Protection Breach Notification Division.

Let me explain.

What I’ve actually done is that I've taken another look at the incidents that I’ve personally dealt with as a Data Protection Officer over the past 9 months, and I’ve tried to work out whether they could have been classified as data breaches that were sufficiently serious to merit notifying the ICO using different sets of reporting conditions. Yes, this research uses real data.

Having reviewed all the circumstances of the incident. I’ve sorted them into three categories. The first (blue) category is the criteria that a responsible data protection officer would use when they apply the current ICO “best practice” guidelines on breach notification. In very general terms, this is where a threshold of 1,000 victims applies, with lower thresholds if the information breached is particularly confidential.

The second (red) category is the criteria that a responsible data protection officer would use when they apply the current breach notification rules in the ePrivacy Directive, as interpreted by the ICO. This category obviously includes the first category, but also contains less significant incidents. Remember, under the ePrivacy Directive, notifications have to be made when even where no harm has been caused to a victim, the only stuff that’s been lost is encrypted, there has only been one victim, and where there has been unauthorised access and alteration to the information, however minor. But, breach reports only need to be submitted once a month.

The third (green) category is the criteria that a responsible data protection officer would use when they apply the proposed breach notification rules in that Regulation. Naturally, it includes the stuff that would have been reported under the ePrivacy Directive, but it also contains a host of more trivial incidents. Remember, under these proposed rules, breach reports should be made within 24 hours, and huge fines can be imposed on those who fail to notify the right stuff. So, the cautious compliers will probably feel encouraged to over-notify, as there aren’t any penalties for over notification. It’s a bit like the old Data Protection Registration days, when data controllers ticked every box they could find on an ICO Registration form, just to be on the safe side. It still cost £35 to register, regardless of the number of boxes that were ticked.

I presented these figures yesterday at an ICO workshop on data breach management in Central London. I also made a number of other comments, and displayed the stats in a slightly different way yesterday – but the results are the same, however you cut and dice the figures.

Getting to the hard stats (pictured), if I were a responsible data controller, over the last 9 months I would have submitted 4 breach notification reports to the ICO if I were adhering to the ICO’s “best practice” guidelines, 27 reports if I were adhering to the ePrivacy rules, and a whopping 88 reports if I were doing my best to comply with the proposed rules in that Regulation.

It’s my contention, that of the 88 reports sent to the ICO, in truth they could throw away 84 of them and just concentrate on the 4 reports that I would have sent using the ICO’s current ”best practice” guidelines. And, they would find that there was no need to take any regulatory action against the data controller in respect of these 4 reports, given the nature of the reports – which I won’t discuss in this blog.

But what happens when the other 330,000 large data controllers in the UK start to follow my lead, and increase the volume of reports by so much? Especially when, frankly, all that’s new that's being sent is the inconsequential and the trivial? Remember, we are all probably going to be reporting a couple of incidents each week.

And, being a responsible data controller, I’ll be demanding that the ICO promptly marks my homework, and gives me feedback on each report, so I can better calibrate the next incident that comes along and decide whether it needs to be reported.

The faster the regulators realise the consequences of having to deal with the huge additional workload, the better. I don’t mind keeping regulators busy. But if they can’t cope with what they are being sent, then data controllers are going to be mightily unhappy if they are to be fined for not keeping up with their obligations to promptly report the incidents in the first place.


Note to academic researchers:
Please get in touch if you are seriously interested in helping out by sanity checking my calculations. And if you want to help prevent regulators from being swamped with a daily tsunami of trivial breach notification reports.

.