Given the apparent proliferation of data breaches (or at least their coming to light), I doubt that I can keep up, and so in future will comment only on those cases that illustrate some aspect of the GDPR.
That aspect today is the rampant push to get sensitive PII into the hands of cloud vendors and external (outsourced) developers and testers. I just came across some recent cases:
This next one sees the leak of data go undetected for 10 months.
Unicredit is the largest bank in Italy and is considered strategically important within the European banking system.
My favorite part of the article was this:
Nick Pollard, security intelligence and analytics director at Nuix, noted that the breach took place less than a year before tougher data protection rules in the shape of the General Data Protection Regulation (GDPR) comes into force in Europe. “This latest data breach goes to show the importance of a unified regulation such as GDPR in making third parties accountable for security concerns. GDPR ensures that data is accounted for, protected and access to it is managed,” he said.
“The recent UniCredit data breach is a prime example of knowing where the data is, but not ensuring it is properly protected and managed. 400,000 customers’ data was put at risk by a third-party supplier. Whilst the fact they know this shows they are doing a better job than most, the delay in revealing this goes to show that any business with large amounts of data must have full understanding of where, how and who manages it.”
If Unicredit has not retained Mr. Pollard, they should. This was a smooth public statement whose first part praised the GDPR, crediting it with helping Unicredit to fix the problem, which is due to a third-party supplier. To summarize, it:
- praises the GDPR (and by extension, the DPAs), which can’t hurt
- reassures customers that all will be well
- indirectly asserts that Unicredit was not to blame
- implies that Unicredit is ahead of the curve because they know about the breach
I’m embarrassed to admit that, in thinking about post-breach mitigation, I never thought about the need, however bad the situation, for the data controller to put the situation in the most positive light. This effort is called ‘communication policy’ by some, and simply ‘spin’ by others.
I suggest that you collect examples of official post-incident damage control, judging for yourself (with benefit of hindsight, for once) whether they were effective in putting the organization in a sympathetic light. Hopefully you’ll never need to fashion such a statement yourself.
In other news, there have been several breaches related to placing data on cloud development and database platforms.
The stories are worth reading, if only for the large data volumes involved and the data processors’ terse statements to the effect that nothing happened, nobody saw anything (except the outsiders who told them about the vulnerability), and so forth, without specifying what makes them so certain.
In recent years I’ve seen, besides cloud apps (SaaS), a rush into cloud development. Part of this is driven by an understandable desire for speed and agility; you can have access to a full development with just a credit card. You no longer need to go through in-house IT, with its slow, cumbersome business cases, estimates, budgeting, and so forth. You can set up your own ‘guerilla’ project and show everyone how it’s done. The foregoing cases illustrate how badly wrong this can go.
A thorn in the rose comes when bypassing in-house IT also means bypassing any oversight, security analysis, or privacy vetting. Go-go development teams will consider GDPR vetting as being another tiresome chore, and I’m sure it will be, if it’s thorough.