“It wasn’t our fault! …” 10 lines unlikely to get much regulatory sympathy following a data breach

“It wasn’t our fault! …

1) Criminals are to blame – we’re the victim here!”

Criminals might have been behind the attack, but they’re not the ones responsible for failing to put in place appropriate security measures – as the data controller, you are. That failure is a breach of the GDPR and is the reason why you’re being fined – all the attack did was to expose it.

2) Just because the attack was successful doesn’t mean we’ve also breached the GDPR’s security requirements.”

It’s true that not every personal data breach will necessarily amount to a breach of a data controller’s security obligations. The success of an attack isn’t evidence that a breach of the GDPR has definitely occurred. The attack has, however, exposed the fact that you failed to secure your systems in an appropriate manner (more below on what ‘appropriate’ means).

3) It was our vendor’s fault. We did what we could by …

a) selecting a reputable / specialist / experienced provider.” 

The fact that you’ve engaged a vendor to implement, maintain or manage certain elements of an IT system doesn’t absolve you, as the data controller, of responsibility for breaches of the GDPR.

b) seeking contractual guarantees.”

These, of themselves, aren’t enough. A data controller shouldn’t place undue reliance on such guarantees, especially where other more appropriate measures exist – including technical solutions. Instead, a layered approach to security is needed. 

c) setting security standards for suppliers.”

Whilst “commendable”, relying solely on contractual agreements or policies between a data controller and its contractors regarding access and security isn’t an effective measure to secure its systems appropriately.

4) The previous owners from whom we bought the business are to blame!”

The data controller is responsible for ensuring the security of its systems, even where they were compromised prior to an acquisition being completed. Acquisition isn’t the only trigger point for due diligence. Compliance with the GDPR is an ongoing duty and, as the data controller, you’re required to ensure your compliance on a continuing basis. 

5) The IT system in question was due to be decommissioned.” 

Where IT systems continue to be used to process personal data, the data controller remains obliged to put in place appropriate security which doesn’t involve disproportionate cost or delay, even if those systems are due to be retired shortly.

6) We couldn’t have anticipated the attack.” 

Large and/or high-profile data controllers are expected to be aware that they’re likely to be targeted by attackers, sophisticated or otherwise. Sophisticated cyberattacks on global businesses are commonplace, and sophistication will not negate a data controller’s responsibilities where steps taken by an attacker are a well-known means of accessing a system and could have been anticipated and addressed.

Data controllers ought also to know that no system is fully secure, and that attackers will often target less secure third parties who supply services to them (i.e. ‘supply chain attacks’). 

Data controllers are expected to be aware of attack vectors (i.e. ways to compromise the target) where known security risks have been identified in publications by governmental agencies such as NIST (in the US), ENISA (in the EU) and the NCSC (in the UK), and/or industry professionals.

7) We had lots of security in place.” 

Perhaps, but it wasn’t the right type; i.e. it wasn’t ‘appropriate’. Data controllers are required to ensure appropriate security of personal data (A5(1)(f) GDPR) and to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk (A32 GDPR). This involves taking into account the state of technological development, the costs of implementation, the characteristics of the processing as well as the risks to individuals.

In practical terms, what’s appropriate in the context of a data controller’s operations broadly comes down to the consensus of relevant professional opinion. This is reflected in guidance published by the agencies referred to above, and in widely used industry standards such as the Payment Card Industry Data Security Standard (‘PCI-DSS’). So, although compliance with PCI-DSS isn’t necessarily equivalent to compliance with the GDPR’s security principle, where payment card data are affected by a breach the extent of compliance with measures required by that standard will be considered.

Measures that are readily available and mature solutions (i.e. solutions that have been known about in the industry for a long period of time) which can be implemented, to the extent necessary, without entailing excessive cost or technical difficulties, are more likely to be deemed appropriate. 

And if you say you’re going to do something, then do it! So if you’ve got a policy in place requiring (for example) multi-factor authentication (‘MFA’) or the regular security vetting of third party vendors, then make sure it’s being complied with. If you deviate from that policy then make sure you’ve assessed the risk (and can show that you have too). When warnings come in from partners or via social media, make sure you act promptly on them.

8) We relied on standards and external assessments of those standards.”

Depending on their scope, standards and tests based on those standards can be of limited value when it comes to providing assurance. So just because a PCI-DSS test has been conducted doesn’t provide reasonable assurance about monitoring systems where that test concerned perimeter defences instead. ISO 27001 is an information security management standard, so the fact that a software provider has that certification says little about the security of the software it’s supplying to you.

Where a data controller erroneously believes, based on reports of external assessors, that a measure such as MFA has been implemented but in fact has not been, that security failure is unlikely to be considered a breach of the data controller’s obligations under the GDPR.

Also, complying with certain industry standards (e.g. PCI-DSS) focusing on specific types of personal data (e.g. cardholder data) doesn’t reduce the data controller’s responsibility to secure all of the personal data it holds. 

9) We didn’t even know there was an issue because …” 

a) … we weren’t able to detect it.”

It’s not just about preventing attacks, it’s also about detecting them. Logging is a key detection measure, that’s why the NCSC describes it as “the foundation on which security monitoring and situational awareness are built.” Regular and close monitoring and evaluation of logs can assist in the earlier detection of attacks, their mitigation and the prevention of future attacks. Monitoring of network traffic and user activity are standard security measures.

b) … our vendor delayed in notifying us – but we still let you know within 72 hours of us becoming ‘aware’.”

As a data controller you have overall responsibility to ensure that you become aware of a breach in a timely manner. That doesn’t just mean having internal systems and procedures in place. It also means ensuring that you have an effective process in place with your data processor. Where that process fails or isn’t followed – even as a one-off – you, as data controller, have constructive awareness of the breach. That means that you can’t absolve your own delay or failure to notify within 72 hours of becoming aware on the basis of your data processor’s default.

10) No one really ended up getting harmed by it anyway.”

You can’t say that consumers won’t have been distressed on learning that their personal data were compromised, even if it’s only for an interim period until they establish the impact on them. It’s likely that some of those affected will have suffered anxiety and distress simply from their personal data being disclosed to an unknown individual or individuals. All personal data, not just financial data, is of significance to individuals.

Just because you’ve said you’ll reimburse financial losses won’t prevent some from being concerned about the potential for such loss to occur in the first place. It would also trivialise your serious failure to say that payment card breaches are “an entirely commonplace phenomenon” and an “unavoidable fact of life”. Taking up free credit monitoring or cancelling payment cards are examples precautionary steps indicative of sufficient concern among affected data subjects – as is the volume of calls to dedicated call centres set up to provide further information about a breach.

Whilst some of the steps you’ve taken will go some way to reassure affected data subjects and therefore mitigate any likely distress which might otherwise have been caused, not all concerns would have been immediately addressed. In any event, it’s not the regulator’s role to investigate and establish the extent of any damage that may have been caused to any particular data subject, or to comment on the potential for claimant law firms to “for entirely self-serving purposes, use the word “distress” very liberally, essentially with the aim of garnering thousands of potential claimants on no-win-no-fee-agreements.”

Conclusion

In all cases good incident response was a key mitigating factor and emphasises the importance of breach preparedness (see here for our interactive training on responding to an insider threat). But fines from regulators are only half the story; and despite the six to eight figure fines levied, the second half, which is marked by the launch of class actions following on from those regulatory findings, has the potential to inflict far more pain on those data controllers, with damages claimed even reaching the billions of pounds. So if those lines didn’t work on a regulator, they’re likely to get even less sympathy from a cohort of claimants.