Why Protect Data?

This may seem like an obvious question, why do we need to protect data on IT systems – isn’t there enough resiliency built into modern hardware and software to ensure data loss doesn’t occur? Before getting to a discussion on technology specifics, there are two important business-related aspects to consider.

Data is an asset. Data has always been a business asset, but was generally locked up in sales information, marketing campaign metrics and other traditional forms within structured databases. In the modern enterprise, most (if not all) data assets are digital and cover a wide aspect of business functions, including sales, marketing, customer engagement, product information and research. Much of this data may not be in customer-owned infrastructure. For example, many businesses use Salesforce for customer relationship management, without any understanding on how the data within the platform is stored and protected.

Much of newly created data is now coming from automated sources, including interactions with customers, the way products operate and, probably less obviously, third party data types that can be combined with internal data to create new business insights. This includes, for example, the way customers interact within mobile apps or online websites. A large proportion of this data cannot be recreated if lost, as it represents interactions in the real world. Additional examples could include social media reactions to a launch event, sensor measurements on production systems, or user website interactions during a sale event.

Like any physical asset, data assets need protection from a range of loss scenarios we’ll discuss in a moment. How businesses account for data assets on the balance sheet is outside the scope of this book, but we expect to see increasingly visible statements on data assets within company accounts.

Data has responsibility. While a significant volume of data is anonymous content, a large part of the most critical assets of a business relate to interactions with customers. Some businesses are specifically focused on individuals, such as healthcare or finance. For others selling products, customer data represents personal information including addresses, credit card details and non-fungible data such as social security numbers and dates of birth.

Businesses are under legal responsibility to protect and manage PII (personally identifiable information), with hefty fines in place for companies that negligently lose data to exfiltration or deletion. In the EU, GDPR provides for fines of up to 10% of turnover[CME8].. In specific industries, there are regulations in place on managing personal information, such as HIPPA[CME9] in the US and xxxx. These require businesses to reatain data for specific periods of time, for example, in healthcare the lifetime of the patient plus XX years[CE10].

With the risk of significant financial penalties for businesses that fail to adequately protect data, data protection becomes a risk mitigation process and part of the cost of doing business, rather than some unwanted overhead. As another observation, we expect that in the future, businesses will highlight their credentials on data protection practices, enabling customers to make informed choices not just on the products and services sold by the business, but the way in which they are transparent on data governance processes.

Data Loss Scenarios

As we now know, our data assets are valuable, but what risks are there that may cause data to be lost? We can divide the possible risks into the following scenarios:

• User Error – a non-malicious mistake made by an internal employee or system administrator (sometimes colloquially known as “fat fingers”) that results in data loss. For example, deletion of a file or directory. In terms of risk, user errors are quite low on impact but can occur frequently. Some user errors can be much more significant and impactful, depending on the degree of controls in place.
• Malicious destruction – scenarios where data is deliberately destroyed or corrupted. The cause of the malicious nature can include internal staff (for example disgruntled employees), data “vandalism” where external actors damage data for no reason (malware), or as a part of a ransomware attack. Ransomware is an area we will discuss in more detail later.
• Software failure – all software has inherent bugs that can lead to data corruption. The specific area of failure could be in application code, platform code (such as a database) or in the operating system or storage platform. As software continually changes over time, new bugs can always arise, even if existing software issues are corrected.
• Infrastructure failure – hardware is always at risk of failing, either at the component or system level. Hard drives and SSDs fail, sometimes unpredictably. Servers crash and can corrupt data. While we design infrastructure to be resilient, there can always be unforeseen issues with computer hardware that result in system outages and data loss.
• Ecosystem failure – more widespread issues can occur at the data centre level. Earthquakes, fire and flood can result in data loss and the inability to access systems. A recent example is the fire at the OVH Strasbourg data centre in 2021. An ecosystem failure could be localised to a rack, a data centre hall or even an entire data centre location. Sadly, as we saw from the September 2001 terror attacks on the USA, having data in a single secondary location such as the alternative twin tower of the World Trade Centre, may not be enough to sufficiently protect data assets.

Although modern hardware is more reliable than ever, hardware does fail. Systems are designed for the most part to be fault tolerant, but there’s no way to guarantee that any single piece of computing hardware will have 100% reliability. Software is never perfect and always has bugs, which occasionally lead to data corruption or loss. Some bugs can cause silent corruption of data which might not become apparent until weeks or months later.

Even when data centre equipment is running smoothly, outside factors can cause problems. We’ve categorised these as natural disasters, including fire, flooding, or earthquakes. Not all of these are truly natural, of course, such as the explosion and fire at Buncefield[CME11] in the UK or the commercial airliners that crashed into the World Trade[CME12] Centre towers in New York. Some incidents occur internally, but have data centre-wide impacts, such as the fire in the OVH data centre in Strasbourg, France.

In the best run systems that have protection from natural disasters, the operational aspects of system operation could also cause data loss. Many users have “fat fingered” their typing, hitting “enter” before realising the mistake. It’s easy to accidentally drop the wrong database when there are thousands in operation or delete an entire folder of files when meaning to delete a single document. Sometimes data is deleted in good faith, when it’s assumed a spreadsheet, or Word document is no longer needed. It’s only when (for example) a few months’ later that the deleted data is identified as critical for another process that backups become so important.

Finally, there’s the issue of malicious damage, which could be from a disgruntled employee or via hacking, either for fun or commercial gain (for example, ransomware). Each of these scenarios can be a challenge to mitigate, as the perpetrators may also target backup systems at the same time. We will cover mitigation strategies for all these scenarios later in this book.

Scope

What’s clear is that the impacts of data loss can be as small as a minor irritation or as big as an existential crisis for a business. However, do we need to protect all of our data? We will cover service levels in a later chapter, but for now, we would recommend a general rule that by default, all data should be protected, irrespective of how it was created or where it is located. This means being aware of the use of data within every type of business application, including SaaS (software-as-a-service) platforms.

Businesses may choose to establish requirements that exclude certain data types from being protected. For example, if a data source is transient and the summarised version is the only copy used for businesses purposes, then it may make sense not to protect the entire data set. If some data is generated from other data (such as reports generated from live customer records), then it may be acceptable not to protect that data if the regeneration time is within the recovery SLA.

These are business decisions to make and not the responsibility of IT teams, who only implement the requirements of the data owner. Only the business has insight into the true value of data in the enterprise and what service levels should be applied[CME13] to it. We will discuss this topic further when we look at service levels.

What Types of Data Need Protection?

What types of data should we be protecting? This question may seem like an obvious one, but the scope of electronic business systems in use today spans much more than the on-premises data centre. If we look back over time, in the 1960s through to the 1980s, almost all data was stored in large and expensive data centres. Most data was also created in the systems that ran in these data centres, either manually entered or through customer portals.

The widespread adoption of the Internet in the early 1990s, driven by the development of the World Wide Web, introduced low-cost and ubiquitous networks that facilitated business-to-business (B2B) and business-to-customer (B2C) transactions. Up to this point, proprietary networks, provided expensive communications capabilities, whereas the Internet enabled anyone with a dial-up modem to shop online and businesses with fixed line connections to host websites.

From the early 1990s, we saw the widespread use of personal computing, starting with the IBM PC, first released in 1981. Today’s endpoint devices (which can be classified as part of edge computing) include desktops, laptops, tablets and smartphones.

In the mid-2000s, cloud computing[CME14] was pioneered by Amazon Web Services, although some online services had existed before then (I personally worked on an online backup service in the mid-1990s that used dial-up connectivity). The capabilities of cloud computing have matured into a multi-billion-dollar industry, with multiple tiers of service providers. All of these systems have data that must be protected.

In the last decade, software-as-a-service has become a practical reality, with websites offering IT-based capabilities (data protection being one), but also other business functions such as customer relationship management (CRM), project planning and project management. Collaboration tools (word processing and spreadsheets) are delivered online by Google and Microsoft, while SaaS has also been developed for HR and personnel tasks.

Business data now sits across four main areas – on-premises systems, public cloud systems, SaaS platforms and Edge. Data can be created uniquely in each location, so data protection must encompass them all.

There is one key factor that is consistent across all of these deployment models. Data protection is the responsibility of the business and IT department, even where the IT systems storing the data are not directly owned by the business itself. This is particularly important for SaaS and public cloud use cases, where the service levels offered by the platform provider will only cover the restoration of data to the point of a system failure.