Whether there is a ransom or not, data breaches always have financial implications. Organizations may face regulatory penalties, operational losses, and reputational damage. Careful planning can save you time and money.

The Impact of a Data Breach

Data breaches happen when there's a weakness in security leading to the exposure of private data. Sometimes it is an inside job. Staff may make a mistake, or harbor a grudge and maliciously release data, or someone might be a whistleblower. But data breaches are most commonly caused by cyberattacks. Ransomware attacks, hacktivist campaigns, doxxing attacks, and industrial espionage can all lead to data breaches.

The financial impact of a data breach can be massive. For example, ransomware attacks make organizations lose revenue from the moment they're hit. Even if some parts of a business are able to function, it might still lose revenue. In the Colonial Pipeline ransomware attack of May 2021, the fuel production depots were able to operate, but that didn't help. Colonial Pipeline had lost its billing systems. They could produce fuels, but they could neither deliver nor bill for them.

If personally identifiable information (PII) is breached it's likely local, national, or even international data protection legislation will impose a fine on you. The fines take into account factors such as the number of affected data subjects and the circumstances of the breach. Even if no data leaves your network, a ransomware attack is considered a breach because you've lost control of your data.

Lost revenue and ransoms are easy to enumerate. As is the cost of remediation and recovery. It's much harder to quantify how a drop in confidence from customers and employees will affect your organization. Damage to reputation and brand can make stocks slide, top employees jump ship, and customers leave.

Data breaches are on the rise and notable attacks are reported almost every day. For every headliner, there are numerous other small-scale breaches at smaller organizations. To minimize the financial damage, you need to be able to react quickly if a breach happens. That means you must proactively prepare for such an incident.

Understand Your IT Estate

The days of the classic on-premise IT estate are over. Very few organizations retain the entirely on-premise infrastructure of the pre-2000s. Even if it is only some off-site backup, a remote Git repository, or Microsoft 365, it's almost impossible not to have some sort of cloud component in your IT operations.

And while cloud computing can bring benefits in cost, scalability, and availability, it can also bring its own complexities. When you add containers, microservices, mobile devices, smart devices, and APIs, your attack surface becomes much larger. It makes your IT and networks difficult to defend, and it becomes more complicated to restore should disaster strike.

That's why it is imperative that you take stock and quantify exactly what your IT estate consists of. Document all the operating systems, applications, and hardware. Create hardware and software asset registers, and include the roles and functions of the assets. This will aid you in the creation of your incident response plan. This will be the playbook you follow when an incident occurs.

What Do You Restore First?

If everything is down, what do you restore first? The faster you can restore operational capability, the faster you can turn back on your revenue streams. That's why your IT asset registers need to include the roles and functions of the applications, servers, and software. That information will guide the creation of your incident response plan (IRP).

Rehearsing the incident response plan---with all the appropriate stakeholders present and engaged---will reveal the critical systems that need to be restored before anything will work. Once that has been done, you can jointly determine the order in which vital job functions or departments need to be restored.

An incident response plan will help you minimize your overall downtime. That cannot be reduced beyond certain practical limitations, dictated by the size and complexity of your IT infrastructure and the severity of the attack. The best you can do is establish the order in which financially critical teams or departments are brought back online.

If you're hemorrhaging money from one particular place, that's where you press the hot iron.

An IRP is a Business Document

Your incident response plan is not just an IT or security team document. It is a critical business policy and procedure. It is vital that when it is reviewed, signed-off on, and rehearsed that all business stakeholders are involved. As well as providing input and guidance, they will gain an understanding of the issues and challenges of a genuine incident.

That understanding will have two major benefits. The first is they'll understand in a real-life incident the security team must be allowed to get on and work the problems and deal with the incident. Standing over them won't help. The second is that the business will appreciate the need for specialized expertise. And if that expertise isn't available in-house, they should see the value in locating a competent provider and engaging with them, now, and not in the middle of an incident.

Looking for outside expertise during a crisis is too late. If you do find someone you'll pay emergency rates. From a technical standpoint, they'll be less effective coming in cold than if they have been engaged, on stand-by retainer, in advance, and been given time to familiarise themselves with your operation.

Of course, it may not be just security or other technical expertise you need to call on. Public relations, human resources, call centers, and social media functions may need bolstering with outside support.

Prepare Regulatory Documentation

When a breach strikes, a clock starts ticking. Depending on the data protection legislation that comes into play---dictated by the residency of the data subjects, not the location of your organization---you'll have a short period of time in which to perform several mandatory steps. Not performing those steps or not hitting the deadlines will increase the fines imposed on you.

For example, the time period within which you must notify the appropriate data protection body---the supervisory authority---of the breach can be as short as 72 hours. Clearly, you need to understand all the data protection legislation that applies to you, and what each one demands of you.

If you process the personal data of U.K. citizens you must satisfy the Data Protection Act 2018, which contains the U.K. version of GDPR. If you process the personal data of citizens of EU countries, you must satisfy the European version of GDPR. If you meet the qualifying criteria of the CCPA and fall under its scope, your organization must satisfy the CCPA, too. And so it goes on, for each applicable piece of legislation. Your data protection officer or CIO should have provided input to the incident response plan so that the actions and timescales required by each piece of legislation are clear.

Notifications sent to supervisory authorities and data subjects informing them of the breach must include mandatory sections, and sufficient details to satisfy the supervisory authority. That makes it infeasible to have pre-filled statements prepared ahead of time. But you can prepare documents with the mandatory information about your IT systems and the organization. With a pack of incident-ready documents for each piece of legislation, the challenge of completing the regulatory demands within the timescales is reduced to a series of data-gathering and form-filling exercises.

Perhaps you'll be fined for the data breach. Making sure the compliance aspects of the incident are squared away avoids increasing the fines needlessly.

Upstream and Downstream Responsibilities

Organizations that process data on behalf of other organizations are known as data processors. Organizations that engage with them are data controllers. Data processors and data controllers have joint responsibility for the data. If a data processor has a breach, modern data protection legislation considers both parties liable. The data controller chose the data processor, and the data processor had the breach.

Both parties can receive fines, and the data subjects can sue you both. if the data processor says the reason they had the breach was because of some omission or oversight on the part of the data controller, they can sue the data controller.

It's important to have data processor agreements in place with all of your data processors. And if you are a data processor, make sure that the terms of data processor agreements that you are bound by are not unfairly financially punitive.

Prevention is Better Than Cure

But preparation is better than pandemonium if the worst should happen. Having a holistic game plan governing the internal technical teams, external specialist help, and compliance and legal teams will guide you through a data breach in a way that'll help reduce the financial implications.