And why a lean, purpose-built tech stack is the way to do it

Immutability is a key feature that plays a pivotal role in safeguarding data integrity, boosting data resilience, and protecting data against threats, including ransomware, but certain considerations need to be addressed when evaluating backup solutions. Let’s look into the concept of data immutability, its significance, and what it means for Keepit’s SaaS data protection platform.

Data immutability definition: Why it’s important

Immutable storage operates on a simple principle: Data can only be added. Once data is written, it can’t be changed, effectively locking it and preventing any unauthorized tampering or deletion. In the context of data protection, this means that once data is stored immutably, it remains unchanged and is safeguarded against unauthorized modifications or deletions, ensuring data integrity at all times.

How an immutable backup solution will enhance your overall security posture

The importance of data immutability in data protection is multifaceted. Here’s a quick rundown of some of the main drivers for deploying a solution leveraging data immutable technology:

• Data integrity: First, immutability ensures that data remains in its original, unaltered state, preserving its integrity. This is critical for basically all industries.
• Ransomware defense: In the battle against ransomware, data immutability offers a robust defense. Here’s why: Even if ransomware infiltrates a system, it cannot manipulate or delete immutable data. Because of this, it’s providing a secure fallback option for data recovery.
• Compliance and legal requirements: Since regulatory bodies require organizations to maintain unaltered records for a specified period of time, having a backup solution that guarantees this is vital. In this way, immutability helps organizations meet these compliance requirements.
• Historical data preservation: Immutability enables organizations to keep historical data records that are unchangeable. This is valuable for auditing, investigations, and analysis of past data.

So, which features should you look for when evaluating backup options that all offer immutability? First, I’d say simplicity, because it’s not always simple.

“Simplicity as a shield”

Who doesn’t like a good acronym hijacking: Software as a service (SaaS) meets “simplicity as a shield.” Our solution distinguishes itself in data backup and recovery by having the most efficient tech stack. It’s cloud native and purpose built for SaaS data storage with the clear security goal of keeping data tamper proof and always immutable.

But what does simplicity mean for defining immutability and how it impacts a data protection strategy? Or alternatively, what does complexity mean for immutability? Let’s look at both, starting with the latter.

Vulnerabilities for backup providers with complex adaptations

Many backup providers have legacy systems that were initially designed for on-premises environments. In order to adapt to storing cloud data, these providers had to implement bolt-on solutions via additional layers to their old, on-prem tech stack, resulting in a much more complex architecture.

There are two main considerations that I want to discuss, from a security standpoint, with cloud adaptions to on-premises solutions: First, the complexity is significantly increased with the added layers required to retrofit an on-premises deployment for the cloud, thereby increasing the attack surface and potential attacker entry points; Second, these bolted-on layers often have immutability as a configuration, not baked into the architecture.

While these top layers often offer options for manual configuration to achieve immutability, this configurability and added complexity create potential entry points for attackers. Effectively, this results in more entry points — more “doors” that bad actors will come knocking on to see if someone forgot to lock up. (Read about why backups are key ransomware targets.)

To make matters worse, the complexity added by having those extra layers makes comprehensive testing challenging. More potential entry points with less comprehensive testing means a larger attack surface to protect and test to ensure that they’re secured. That’s not great for data integrity, ransomware defense, or historical data preservation.

In solutions deploying these bolt-on cloud adaptations to “modernize” legacy systems, attackers can exploit these optional higher levels (I say optional since these levels only exist because they’re modifying an on-prem solution for the cloud). These retrofitted legacy systems can be (and should be) thought of as having more potential access points for threats.

Retrofitted complexity: The Achilles’ Heel of many backup solutions? 

“Defenders need to be perfect all of the time, while the attacker only needs to succeed once.” 

-Popular security axiom 

So, where does all this lead to? As a result of these legacy on-premises systems being retrofitted for cloud data, cybercriminals are finding easier entry points into the targeted environment, gaining access (Think: social engineering like phishing) into the ecosystem at these more vulnerable higher levels (where the stakes perhaps don’t seem so severe) before drilling down through the layers to lower-level access with their highjacked rights. 

Here they can then gain entry to the lowest, most-important (and secure) levels to corrupt, encrypt, or otherwise destroy backup data — attackers typically assume access at a higher level, but the main concern here is that if the assumption that the higher the level you go, the easier entry is, then those solutions with the highest complexity would also be the most vulnerable. 

To say it another way: The deeper the layer of attempted entry, the fewer chances for access and exploitation. Therefore, less complex solutions — “less complex” meaning something good because you’re more deliberate on the design — have fewer options to exploit and can be tested much more holistically. That’s a win win. 

There are three notions I want to keep top of mind:

• Typically, higher levels can be immutable, but sometimes these must be configured manually. 
• Attackers use these “immutable optional” higher levels as easier entry points and then drill down to the immutable, lower-level access points with assumed access rights they acquired. 
• Having fewer layers means a smaller attack surface for exploitation. Simple is a good thing because it means you’re more deliberate on the design (and can test more holistically). 

What an efficient tech stack means for cyberattack defense 

Unlike legacy systems with bloated, bolted-on complexities, Keepit’s purpose-built and streamlined architecture minimizes potential access points for threats. The leanness of our software means having fewer layers of complexity and therefore having fewer points of entry for threat actors. Not only that, but since it’s simpler, we can test holistically (and testing is key). 

Put simply, Keepit has fewer layers since our tech stack is purpose built for cloud data storage. In this way, it avoids a lot of the complexity other backup providers “need” to have but only because they’re running legacy systems from the on-premises days with bolt-on cloud modifications. 

The level of leanness, efficiency, and simplicity we’ve achieved directly adds to the strength of immutability in our solution. 

We’re able to achieve this because we designed our solution for the cloud, in the cloud, and to do “one thing” extremely well, and that’s to protect and store cloud SaaS data securely on an independent cloud, air gapped, so customers can always have access to clean backup copies of their data. 

Simplicity is key: Fewer layers are much more secure 

SpaceX, the company that revolutionized commercial spaceflight, has a philosophy that states “the best part is no part,” which resonates here. By embracing simplicity and efficiency in design, Keepit aligns with a principle that’s also reaching for the sky (well, the cloud at least) — it’s a design choice that enhances security, boosts efficiency and agility, and integrates seamlessly with a multitude of SaaS applications due to its API-only design. 

Software can be infinitely complex, with no way to test everything (among other issues, like development and maintenance). From a security standpoint, if your solution is too complex, there’s just no way you could test sufficiently. And so, simplicity is key. That’s my philosophy and the philosophy behind Keepit. 

Immutable by default 

Deep at the core of the Keepit platform, there’s simply no way to overwrite data in storage: It’s just not possible. Like the backup tapes of the past, our disk-based storage systems do not offer a mechanism for modifying backup data. Hypothetically, even if an attacker — or a malicious insider — were to gain access, they just couldn’t do anything there. That’s immutability. 

So, our approach disrupts the pattern ransomware attackers are exploiting in other backup solutions. By providing a more secure foundation through not only avoiding these superfluous layers, but by being designed specifically for cloud backup data storage, we leverage immutability through simplicity. 

In addition to immutability, we leverage a number of other data protection best-practice security methods. 

Adding to immutability: Data protection best practices 

Some of our other security methods deployed for data resilience and data immutability are the immediate encryption of backup data, incremental backup, and data deduplication.

The Keepit solution is running on a vendor-independent, tamper-proof and air-gapped cloud infrastructure. Our cloud offers true backup, where data is stored separately from the primary production data set, regardless of if the data is in Microsoft Azure storage, AWS, Gcloud, or otherwise. 

“True backup” is air gapped in line with the 321 backup rule, meaning your ability to recover clean backup copies is always there, regardless of the status of your SaaS vendor.

To sum up what makes Keepit’s approach to data immutability uniquely strong against ransomware and other cyberthreats:

• Cloud native: Our tech stack is purpose-built for cloud data storage, so we avoid unnecessary layers of complexity and the associated vulnerabilities with legacy systems. 
• Efficient tech stack: Our efficient tech stack minimizes potential access points and reduces the overall attack surface. 
• Holistic testing: The simplicity of our solution (remember, simple is good) allows for more holistic testing, ensuring a robust and secure environment. 
• Immutability: Administrative access cannot overrule or unconfigure the immutability as it is baked into the solution from the ground up, so even if a customer account is fully compromised, the immutable data storage will retain the historical backup data in pristine condition.

Where to go next

This post is part three of a five-part series on ransomware resilience. Read part one “Why backups are key ransomware targets” and part two “Why air gapping is your best defense.” Check back soon to catch the fourth installment of the series, where we’ll discuss the importance of SaaS data protection for identity systems like Microsoft Entra ID. 

Want to keep learning? Watch our on-demand webinar co-hosted with Enterprise Strategy Group (ESG) entitled “Surviving ransomware: 2023 data protection insights and strategies.” Learn how to be data resilient in the face of cyberattacks. 

Keepit’s holistic approach to sustainability pushes beyond only using green energy options: it’s about maximized efficiencies from our purpose-built architecture perfected for protecting and storing SaaS application data in the fastest, most efficient way possible. 

So, let’s look into how we consider sustainability in the data protection and backup industry, the design choices Keepit has made to be fast and efficient (like deduplication and incremental backup), as well as the challenges legacy systems face in regard to sustainability.

Introduction 

What is sustainability in a context where energy consumption must happen? And by “must happen” I mean — in our very real example — for critical services like data protection and backup that’s required by law (think compliance with NIS2, HIPAA, GDPR) and crucial for businesses ensuring operations and continuity. 

Keepit, the only vendor-independent cloud data protection specialist (think air gapping with a separate logical infrastructure, in line with the 321 backup rule), not only leads the way for greener solutions by way of substantially better efficiency, but also demonstrates that performance and profitability don’t have to take a backseat to environmental stewardship.

This article explores Keepit’s comprehensive approach to sustainability, focusing on its commitment to minimizing resource consumption while delivering industry-leading data protection of essential services and critical infrastructure. 

From efficient technology stack design to innovative data management practices, Keepit exemplifies how sustainability can be integrated into every aspect of operations, often leading to some beneficial “side effects” I’ll talk about below. 

This article sheds light on the importance of responsible resource utilization in the tech industry and offers insights into practical strategies for achieving unmatched environmental sustainability and performance capabilities.

Let’s look into how we integrate sustainability considerations into our data protection and backup services operations.

Sustainability in data protection: Maximize performance and efficiency to minimize use

Delivering any service, including this one, will consume resources and there’s just no way around that. So, what we try to do here at Keepit is to make as much positive impact with our customers as we can by not only delivering a great service (that they’re often obligated by law to have) but delivering that same high level of service with the least negative impact for the world and future generations, in regards to energy use and energy origin. 

Sustainability for us, as I see it anyway, means being responsible in our consumption of resources because there’s absolutely no way around consuming resources. So, for us at Keepit, we built our technology stack from the ground up specifically for solving these exact problems that we’re solving in the most efficient way possible. 

And with efficiency here, I mean broadly, so it’s in terms of how much physical equipment we need, how much space do we need to consume, how much power we consume, and how many people we need to run this business. In that light, you can say that a sustainable business is also going to be a more profitable business because minimizing resource consumption not only reduces environmental impact but also lowers operational costs, ultimately leading to increased profitability. 

Let’s look into the keys of consumption and sustainability.

Sustainable resource consumption

To us at Keepit, there’s an emphasis on the understanding that every action leaves an impact, and because of this, we define sustainability as being responsible for resource consumption. This includes a commitment to minimizing the footprint left by the company’s operations. 

The company acknowledges that, given the nature of its services, resource consumption is inevitable, and therefore sustainability, in the context of Keepit, means making conscious and responsible choices to mitigate the environmental impact associated with its operations. So, what do we do to make a difference and to limit our impact? 

What makes Keepit green: Technology stack and efficiency 

Beyond running data centers with 100% renewable energy, we take pride in having constructed our technology stack from the ground up, specifically designed to efficiently address data storage challenges. This approach reflects a commitment to optimizing resource utilization and delivering a service that is not only effective but also resource efficient. 

Efficiency, in Keepit’s view, extends beyond environmental considerations to include broader aspects such as the physical equipment required, space utilization, power consumption, and the personnel needed to operate the business. This holistic approach ensures a sustainable business model — and a profitable one, like mentioned above. 

Now, how do we take on the tough task of being sustainable and high performing? 

By starting from a clean slate. We built this system specifically for storage, protection, and management of cloud SaaS data. So, we built up this entire technology stack specifically for the purpose of delivering exactly the service we’re delivering — cloud backup in the cloud, for the cloud, and so it does this “one thing” extremely well and efficiently. 

And one of the things we did is that, well, we did what Amazon, Microsoft, and Google do: We built up this whole cloud infrastructure. We have full ownership of our technology stack instead of building on top of middleware that runs on top of middleware that runs on top of abstractions and virtualizations and other layers that all add overhead. 

We avoid unnecessary complexity by being purpose built, and therefore we use less storage space, need less processing power due to fewer operations, and use fewer human resources to run it all. 

Predictable costs as a wonderful “side effect” 

With full ownership of our technology stack, we have precise insights into the costs associated with running our operations. When a developer writes a piece of code that inefficiently utilizes resources, it’s something the operations team will see, and it directly impacts them. Efficiency and sustainability are integral parts of our culture, so we address these inefficiencies by writing “better” code. 

We don’t just elastically spin up some additional set of servers and try to solve the problem with a credit card. But that’s exactly how a lot of people approach this — that’s how a lot of competitors approach this. It may offer immediate relief, but that type of short-sighted solution fails to align with our company culture and long-term goals. 

It’s enormously inefficient both from a bottom-line perspective and from a sustainability perspective. And it doesn’t fix the problem. It just kind of scribes it further in the future — kicking the can down the road. So, whatever you’re paying for with your credit card now are inefficiencies that you’ll be paying for again and again into the future. 

They fix the problem with money, but in terms of efficiency, it’s not an action done for the betterment of future generations. They waste energy every single CPU cycle — and they’re also paying for that bigger bill every billing cycle thereafter. 

Not only does that power need to come from somewhere, but so does the money to pay for it, which is either passed on to their customers or covered with venture capital. 

What these companies are left with is a band-aid solution that’s going to consume more energy and cost more month after month after month — basically for as long as they exist. And on any consumption-based model, the costs will be continually growing with datasets. 

Lean, green, backup machine: 99% power saving 

Like I mentioned, when we started, we weren’t bound to use any specific technology, so we started with a clean slate. The programming language we chose for the majority of our technology stack is a very efficiently compiled language (you can read my blog post about it.) And if you compare that to common languages, you know, if you go online and say, “hey, I’m building this upstart company on the net, what technology stack should I use,” the advice you will get there is very different from what we chose to go with. 

And because of that decision, it means that we’re something like 30 to 100 times more efficient. So, for doing one specific operation, if I program that in the technology that we’re using versus if I program that in one of these most common, most hyped technologies, we have a 30 to 100 times change in CPU resource utilization, which also translates directly to power consumption. 

So, if we had done what everyone else was doing, we would’ve consumed something like 100 times more power than we do today and that’s huge. Can you imagine achieving a 99% power saving? That’s basically what we started out doing. 

From that perspective, it’s now more difficult for us to make additional power savings since we’re already so efficient. Sure, it looks good when companies boast “15% energy savings,” but another way of looking at that — and we do from our perspective — is that their waste was high, their tech stack wasn’t lean. Of course, it’s good that they improve, but they’re still not even close from an efficiency standpoint. 

Reducing consumption with incremental backup and deduplication 

If you look at the core service that we provide, we make a copy of your data set a couple of times a day. We keep that copy for as long as you want as a customer company. Some companies need seven years of retention, some need 20 years of retention, and some even pay for 100 years of retention. Data retention really depends on the industry you’re in and and where you operate and all that. 

In theory, we keep complete copies of your entire data across two separate, mirrored locations for, let’s say, 100 years. In theory. In reality, we’re smart about this, because it wouldn’t be feasible to transport your entire data set every day. 

Not only would it not be feasible, there’s also no need to do that because of incremental backup. TechTarget defines incremental backup as “a backup type that only copies data that has been changed or created since the previous backup activity was conducted. By only backing up changed data, incremental backups save restore time and disk space. Incremental is a common method for cloud backup as it tends to use fewer resources.” 

At Keepit, we utilize incremental backups. We transport only the differences, such as edits, that have happened since the original backup was completed. And this also means that we don’t duplicate your entire data set multiple times every day, we just transfer the changes. How does this reduce consumption? Let’s consider an example: 

If you have one unchanging file and we hold that in our backup set for, let’s say, 1,000 backups, then we will have only one instance of the file. We refer to that original file in each of those 1,000 backup sets, but we will storage only one instance.

It’s stored once, but that file is pointed to in each of those 1,000 backup sets. We’re not duplicating data needlessly. Deduplication means that we need much less storage space and can reduce network load because less data is transferred from incremental backups, and less data is held in storage because of deduplication. This is all possible because every file, no matter the file type, has reliable identifiers where you can kind of say, “This is exactly the same file.” 

Let’s say I send someone a Word file and she doesn’t change it. She just saves it from my attachment, and that can be identified as being identical. Let’s expand this across an organization: If you have 1,000 employees in your company that have identical copies of this file and we have those across the 1,000 backup sets, then we will not hold what would literally be 1,000,000 copies of the file. We will again hold just the single instance of the file and there will be a million references to the file. 

Not every backup and recovery solution does it this way though, and as a result, they’re using vast amounts of energy and hardware to power these operations and then to keep all this data in storage. Even if they happen to leverage a green energy source, they’re not exactly using resources responsibly if they are using 1,000,000 times or even 1,000 times what they would with incremental backup. 

Purpose-built storage architecture 

Inherent in our storage architecture is this deduplication across both space and time. And that’s one of these initial thoughts we had and one of the earliest ideas of our storage architecture that we built for this purpose. We did sit down and build a storage foundation for this backup service from the start. We basically invented a file system or object store, if you will, for this purpose: to store these enormous data sets for decades, and we could see we needed something that we couldn’t go out and buy anywhere. We needed something that was built for purpose and so we could avoid the problems we were already seeing others have with legacy systems. 

Legacy complexities add inefficiencies 

Running this stack end to end ourselves, we avoid legacy inefficiencies as I mentioned above. If we had chosen to run on AWS (Amazon Web Services), or Azure, or Gcloud, we’d be provisioning virtual machines, and there’s a lot of complexities that get added when you’re on a virtual machine: All of those layers of middleware that we don’t have to employ. (And with the storage virtualization: If you’re on S3 or Azure blob, then you’re using very sophisticated pieces of machinery that come with great functionality and therefore great overhead. To store backups on them is like hammering in nails with a microscope — it’s perfectly doable but it’s not a very good match of tools for the job.) 

With those virtual machines, you need some automation tools and some various management software to run them reliably. So, you add that, then the virtualization middleware, and then you have some resource management middleware. You have a lot of systems, and your software doesn’t run on the computer anymore: It runs on a collection of layers that run on the computer which you may share with other customers. And ultimately, even if you don’t, Amazon or Microsoft is going to want to instrument your code enough so they can charge you for what you’re doing. So, there’s a number of inefficiencies that are introduced here. And they all translate directly to cost and power consumption.  

But, since we built and operate our own architecture, we don’t have any of those costs, complexities, or additional consumption. No one needs to instrument anything to find out what we need to pay. So, in addition to predictable costs, another happy “side effect” is that we don’t have any sub-processors, which makes vetting and compliance (with GDPR and NIS2, for example) easier for our customers, partners, and anyone else we’re in business with.  

Conclusion 

Keepit’s holistic approach to sustainability sets a commendable example for the tech industry, particularly within data protection and backup services. By prioritizing responsible resource consumption and efficiency in its technology stack design and operational practices, Keepit demonstrates how environmental sustainability can be seamlessly integrated into essential services. 

Through the utilization of deduplication and incremental backup techniques, Keepit minimizes data storage requirements and energy consumption, paving the way for a more environmentally responsible approach to data protection. Additionally, Keepit’s purpose-built storage architecture and avoidance of legacy inefficiencies further underscore its commitment to sustainability, resulting in both cost savings and reduced environmental impact. 

As we navigate an increasingly digital landscape, Keepit’s sustainability initiatives serve as a testament to the importance of balancing important factors such as regulatory compliance and business continuity with environmental responsibility. By embracing sustainable practices, Keepit not only enhances its own operational efficiency but also contributes to the broader goal of mitigating the environmental footprint of the tech industry.

In essence, Keepit’s journey towards sustainability exemplifies the potential for technology companies to lead by example, demonstrating that profitability and environmental stewardship are not mutually exclusive. As we look to the future, let us draw inspiration from Keepit’s success and strive to emulate its commitment to sustainability in all facets of our operations. 

At the Microsoft Ignite conference back in November 2023, Microsoft announced their release plans for their Microsoft 365 Backup service. Now that they’re in a paid public preview, with general availability being slated for basically now (first quarter, calendar year 2024), I thought “what better time than now?” to share my takeaways and what I believe this milestone means for SaaS data protection now and going forward. Here are three main points I’ll cover:

• Welcome Microsoft to the backup space; 
• What Microsoft’s backup service means for the SaaS data protection world; 
• The Keepit promise.

Welcome to Microsoft into the backup space

First off, let’s give a warm welcome to Microsoft on their entrance to the backup space. As a long-time Microsoft community member, twenty-year Microsoft MVP, and Senior Director of Product Management at an industry-leading data protection vendor, I’d say Microsoft’s entry into the market validates what all the SaaS data protection vendors have long been saying about the strong need for Microsoft 365 data protection.

Ultimately, our mission is to protect critical SaaS data to help companies keep their business-critical data backed up, thereby ensuring continuity and compliance in face of rising ransomware threats. As long-time Microsoft partners — part of the ISV Partner Program — we at Keepit see this as an opportunity to have an even greater impact on the market. How’s that?

Well, we know that an overwhelming percentage of Microsoft’s enterprise customers have no backup. So, naturally, we want to bring that number down to boost cyber resilience of, say, critical infrastructure and critical services, and of course the market in general. So, how does Microsoft releasing their own backup help drive us forward?

Well, for one, it validates what we’ve been doing for more than 20 years. We’re built in the cloud, for the cloud, to protect cloud SaaS data. I guess a bit more practically speaking, another change is that we can now probably drop the top objection we faced from customers over that time: That cloud SaaS data doesn’t need backup.

What does Microsoft 365 Backup change? 

Now, let’s get into point two: What does Microsoft 365 Backup mean for SaaS data backup? Well, all the vendors in this space have long had to challenge the popular notion that data being in the cloud was, by default, automatically and perfectly protected. And many of us have talked at length about Microsoft’s shared responsibility model where Microsoft themselves clearly state that you, the customer, are responsible for backup of information and data, including your devices and accounts and identities.

Microsoft has built an amazing record of service quality and resilience, but their primary focus has been on protecting your data against Microsoft losing it. The Microsoft 365 Backup offering is the start of Microsoft’s journey into protecting your data against other threats, including malicious attacks, mistakes, misbehaving automations, and other misfortunes.

The optimist in me hopes that now, with Microsoft themselves developing their own backup service, we can finally put the shared responsibility model into its proper perspective. Of course you need to back up your Entra ID, M365, and other SaaS application data because clearly you are responsible for your data. Why else would Microsoft release a backup service if you weren’t responsible for it all along?

Now, aside from that original objection that perhaps can be laid to rest, at this point, not that much has actually changed with Microsoft’s announcement. That said, there sure is a newly awakened interest in data protection because of this release. This is how I see the typical train of thought playing out in response to the news:

• We clearly need to back up our Microsoft SaaS app data. Why else would Microsoft be offering a backup service themselves?
• Protecting our data is important because it helps us meet our business continuity and compliance requirements, but
• To meet those requirements, we need our data available 24/7.

Let’s dive down a bit more into that last point there. How does a business guarantee access to their data no matter what happens, be it mistakes, mishap, or malice (like ransomware)? The answer is true backup.

The Keepit promise: True backup for cyber resilience 

To get to the Keepit promise, we first need to consider what the meaning of backup is. You might come across the term true backup (we use it ourselves from time to time) because ‘backup’ alone has been misused to cover things that it shouldn’t.

The canonical meaning of backup refers to storing instances of your data on an infrastructure separate from your primary data. If something should happen to your production data, your backups won’t be affected since they are separated by a physical or logical air gap.

In cloud computing, a lot of what’s being called backup is actually storing data on the same cloud as the primary data. What this means is that whatever risks you’re exposed to in your production environment would also impact your ‘backup’ data since there’s no separation. For example, an attacker who can penetrate your Entra ID tenant and can pivot into your Azure tenant holds all your Azure-based storage — including, and especially, backups — at risk.

The Keepit promise is to always offer the ultimate in data protection for multi-workload SaaS application data. By building our solution from the ground up for SaaS data protection only, we were able to create an optimized data protection solution in line with best practices like the 321 backup rule. Air gapping, immutability, and a fully redundant independent cloud are all things we’re already offering now in our service. So, it’s more the Keepit reality rather than the promise of adding in things later.

Protecting SaaS data is the Keepit mission and has always been — it’s not a feature we’re tacking on. As specialists in data protection, we provide confidence to thousands of customers that their data is here today and will be here tomorrow via our vendor-independent cloud. We look forward to working with Microsoft now and into the future to continue to lead the way in protecting SaaS data.

As we embark on this new chapter in SaaS data backup, I’d like to leave you with a question: What steps are you taking today to protect your control plane (Entra ID and Power Platform)? If you want to learn a bit more about control plane data protection, read my previous article on why you should back up Entra ID (Azure AD) in the cloud.