With GDPR having become as ubiquitous as any major news story, many of us are now suffering from what Deem describes as “fatigue”, which he argues has led to confusion.

“Some people will have it in their organisations that [the] whole GDPR project [is] being run by procurement; some by employment or the HR department; some from the IT department; some from the finance department,” he says. “And so we started from the position where we want to have clarity, we want to have uniform application, but we unfortunately haven't got it.” 

In order to address this, he says that organisations need to be mindful of the goals of GDPR.

“The one thing we really need to focus on, therefore, is what it is we're trying to do, and we're trying to create a culture where data subjects can have their information protected and can become aware of any incident as soon as it happens, and as soon as it might affect them,” he explains.

At the core of this are two concepts from an organisational point of view: the obligation to notify in the event of a breach of personal data, and the requirement to keep records on precisely what data has been impacted and how a company has attempted to stop it.

The first, notification, is the better known of the two, but it is extremely important organisations understand the details. 

“The new mandated notification regime that's going to be kicking in on the 25th May, that is an obligation that applies to data processes and to data controls. For the data controllers that assume there has been a breach that affects the personal data of data subjects, they're under an obligation to notify, wherever possible, within 72 hours a supervisory authority – that is the ICO in the UK – of the existence of a breach,” he explains.

“For the data processors, they don't have the 72 hours, they have to notify the data controller as soon as they possibly can. And then for the data subjects at the end, they don't have any reporting obligations, but they have the ability to be reported to, especially in circumstances where their personal freedoms and rights are going to be impacted.”

However, the second aspect, record keeping, is less well understood as it applies even if a company determines that a cybersecurity incident has not led to a breach and so does not need to report it.

“Even if you don't go down the notification requirement, there's a second feature that you have to be bearing in mind: you have to be keeping a record of all of the incidents that have affected you as an organisation,” he says. 

“You have to have something on a record somewhere where you are putting down what data subjects and what data may have been compromised and the steps you've taken to stop it. 

“That's the one that's often forgotten: the notification and also keeping track of the details.” 

The 72-hour notification requirement is a fairly tight window for companies to alert the supervisory authority, and in some cases an organisation may seek to buy more time. Naturally if this is done incorrectly a company may fall foul of the authority, but Deem argues that there are a number of ways in which the 72 hours can be stretched. 

“Control is everything, and to get control as a business, you want to have time in which to investigate any incident. I have three ways in which I can give you time to investigate this,” he says. 

“If you're not ready to call it a breach that's one,” he says. “I don't like people assuming that there is a breach. I tend to assume that there's an incident, and then the question of whether there's technically a breach from a legal perspective I would leave to a later date.” 

Another is the question of who at the organisation knows there has been a breach.
“I can say that the business or the guiding mind of the business is not aware of it - that's another - although I don't encourage you to keep it to yourself, obviously open up as quickly as you can but awareness as far as the business is concerned is important,” he explains. 

Finally, there are situations where “there is no high risk to the data subjects”.

“Those are the three bases which mean that we can keep it away from the regulator for an amount of time,” says Deem, adding that organisations should not accept liability too readily.

“I hate it when people accept liability, and so to that mind I'm always saying with communications: never say never, always avoid the word always. If people ask rhetorical questions don't even go there and double negatives are a definite no-no.”

Of course, organisations will be in a better place to deal with an incident if they have robust plans in place, something that Milton argues is essential.

“It's just another form of crisis management, and you should have a lot of that already in place, well-rehearsed,” she says. “So this might be something to focus on, but it shouldn't be inventing a new wheel.”

She advocates the development of a 16-point plan, which is designed to cover all of the basics of breach management under GDPR.

“Basically, don't forget that GDPR includes paper, don't forget unrelated legislation that's coming along pretty soon, if not already, which are complimentary and not mutually exclusive depending on who you are,” she says.

“Once you've done that, then you really need to know all about what data is personally identifiable, where it resides, where it transits, and know your supervisory authority because there's an added complication where although we have a GDPR, every country in the EU can cherry pick and fine-tune some of that legislation.”

Of particular importance is having a clear sense of who will be handling what should a breach occur.

“You've got to know who your response team is.  And then you can actually think about who am I going to respond to,” adds Milton. “Prepare those templates, and now you can start filling them in as you are investigating what's going on. Think about communication you need to do, start completing those templates as it will act as the information you are going to be sharing with the supervisory authority, with your customers and clients, with the media. 

“And once you've got enough information, you have to take the decision about who you have to actually communicate with now at this moment in time, versus those that can wait until a bit later on.”

For some businesses, this team will be different from incidents where GDPR does not come into play.

“A lot of that is preparation based on who you think needs to be in your crisis response team for a breach relating to GDPR. It might be the same as response teams for other crises, or maybe it will be slightly different,” she says. 

“Know who can speak on behalf of your organisation. Is it just the CEO? Is it the chief information officer? Is it another person? They are going to be part of your response team.

 
“And then be aware also of the impact: are we actually now at risk of breaking into other legislation that needs to be managed as well? Because as it affects your supply chain and your client base and your jurisdiction, your operations may also be affected.” 

One of the key people dealing with such a breach is likely to be the chief security officer (CSO), but Deem is keen to differentiate between this role and a chief technology officer (CTO) when it comes to a breach, particularly given these can in some cases be shared by the same person. 

“When I see something go well, it's always involved the CSOs taking a very important role in setting strategy of technology and how they're going to respond to the technological issue,” he says. “A CSO in my mind is very different from a CTO, and in some companies the two things can get blended.  

“A CSO in my mind is like the Joint Chiefs of Staff in the US Army or the head of the Navy, whereas the CTO will be like your Secretary of State for Defense or your head of defense.”

This differentiation is important because in a breach situation, one role needs to focus on incident response, while the other will be more budget-conscious. 

“The CTO will be constrained by the budgets, whereas the CSO will be focusing purely on where the threat vectors are, and where the threat profile is for business,” he says. 

“If in your organisation you actually have those two roles merged in some way, as soon as you get into an incident response situation it works best if you remove those budgetary constraint considerations from the CSO. So the CSO's role then becomes focused entirely on the threat actors and threat solution and how you're going to recover the situation.” 

This lifting of budget concerns is important so that an effective response can be made, otherwise an overconcern with budgets could leader to greater financial issues in the long run.

“If you're worried too much about the financial situation then you're going to end up with a very skewed result,” Deem says. 

“You need to have that dialogue in advance to make sure those budgetary constraints can be offloaded, maybe to the chief financial officer or someone else who can be dealing with that, so that you can concentrate on what is absolutely critical from a security point of view.”

Prior to an incident, one of the most important tasks a CSO must oversee is keeping track of where all a company’s data is kept as this will prove vital in demonstrating to the supervisory authority that adequate steps have been taken if there is a breach. 

“The CSO must know where the data is, and the categories of data, and whether it's held in-house globally, or just in one country, or whether it's under the cloud or the third-party provider, because in the end your organisation is going to need to know what happened where, and if you don't know where your data is then you really don't have a clue,” says Milton. 

While this may sound obvious, in reality it is easier said than done.

“This is a huge challenge, and I think one of the most difficult things for a CSO anyway, regardless of a potential crisis or not, is just keeping track of the data,” she says. “And associated with that is a good dialogue with the CTO to make sure you know the technology that is being used to transfer all this data and to hold it at rest.” 

Related to this is the age-old challenge of keeping staff educated, not only so they don’t become a liability, but so that they can assist in the management and monitoring of company data.

“I think in many ways speaking with HR, whoever runs your education for your staff, is actually linking with them so there's a joined up story about the education, so that each person in the organisation understands their prime role and the obvious related responsibilities in managing, protecting, using that data,” she says. 

“But also recognising the broader concept, so that they can actually begin to say to themselves, ‘well I as an end user noticed that there seems to be a mishmash of information in records that I generally look at, and it looks like something has gone wrong, I know how to escalate that’ and give them a context that says 'oh I believe we have some sort of update or I'm aware that somebody reported a bit of malware in the company and now the records that I know should look like this look slightly odd', and being able to flag it.

“So they're coming with a bit of knowledge that other people can trust and therefore use and build a big picture, and the more we do that, the quicker and better we are going to be getting to it, which then means we're much more likely to be able to identify what is an incident that does not need to be reported, and when we have to fit the terminology to say this is a real breach and we need to actually respond now to the supervising authority.”

One important aspect of any cybersecurity incident is, of course, dealing with the media. Data breaches have become major news stories in recent years, and poor communication can have devastating effects on a business. However, handling this well can have the opposite effect, boosting confidence in a company and ultimately improving their public profile. But for this to happen, companies need to have an appropriate plan in place.

“First of all you need to think about reach, what your message is going to be, what type of breach you anticipate – you should probably call it an incident, not a breach,” explains Neil Stinchcombe, director of Eskenzi PR, in reference to Deem’s earlier point about admitting liability. “Think about the language you use around the incident, and then how are you going to deal with the various audiences that need to be informed?

“First of all you need to make sure you know who the team is that's going to do that, so it's going to involve external sources like lawyers and PR professionals, and particularly [those] who know how to handle a breach. Get your facts straight and put the appropriate spokesperson in front of the media.”

When it comes to facts, it is important the message is clear and concise, with Milton recommending that the questions a company needs to answer are essentially the same for all parties – whether it’s journalists, customers or the supervisory authority.

“Here are three questions you need to consider: Why did the incident occur and when? What information was breached? And how are you going to rectify things? And they will answer big questions for the supervisory authorities that you have to inform, the media who are going to ask you some of those questions, and your clients and customers, when they are notified of a breach,” she says.

Given that companies generally will be able to anticipate the types of breach they are likely to be hit with, Stinchcombe recommends companies rehearse this so that they are prepared if and when something happens. 

“You probably would have worked out what is the most likely incident that's going to happen to your organisation, so then you anticipate roughly what it's going to be, so you can anticipate a response to it,” he says. “The severity of it is what you're going to be taking account of in your messaging and then you work out exactly what you're going to say to people. If you're dealing with the media you want to be as open as possible, so it may be that you are in control of the story. It's happened, you know about it and you can manage that process. 

“The worst case is where something has happened and a journalist has called you up to find out: 'I hear you've had an incident - is it true?' and that's one of the worst places to be in, because you're on the back foot. What you need to do is buy yourself some time and say 'I'll come back to you' and give them a deadline: two hours, three hours, four hours. And you need to get that information back to the journalist on time.”