Split-screen-image
Unlocking SaaS Data Security With Shared Responsibility In The Cloud
Data Protection as a Service
Data Protection as a Service

Unlocking SaaS Data Security With Shared Responsibility In The Cloud

June 25, 2024

Understanding Shared Responsibility Models and Avoiding Critical Mistakes in SaaS Data Protection

Close your eyes and think of how many as-a-service applications your organization is using right now. What if I told you that number is closer to 10 times your original guess?  What if I told you it was 20 times your original guess?

XaaS applications including SaaS go beyond Microsoft 365. It applies to your cloud platforms and all their underlying services. It applies to your marketing organization, to your sales team, to your finance group, and so on.  

SaaS Applications – Everywhere All At Once!  

The average midsized organization uses well over 200 SaaS applications, and according to some research reports as many as 71% are paid for outside of IT. To any of us in IT, this is no surprise. It’s reality. At HYCU, we’ve seen this in our own organization and many of our customers and partners as well as, from digital native organizations to FORTUNE 500 companies—that reality and the obvious problem are the same. Here is a sample “tech stack” we often see at many organizations. This does not include all cloud services and as-a-service apps associated with any particular production application.  

Sample Tech Stack

Addressing the Gray Area: Data Responsibility in SaaS

There are many reasons why SaaS application usage is so popular. SaaS applications bring scale and flexibility. Once you subscribe to any SaaS app, you don’t have to worry about on-site management, patching, or updating the server/data center editions. Visit the URL, log in, and start using it. That’s it. It really doesn’t get more difficult than that. Sure, there are many SaaS apps you get for free that tease you with upgrade features you may or may not need, but that’s a topic for another day.

However, simplicity of SaaS has led to a massive misunderstanding. Many companies assume that they are not responsible for security, that includes no need to focus on being responsible for data protection, compliance, backup, etc. It’s a popular misunderstanding and we understand why people may think this way, but it’s fundamentally wrong. And not just wrong, but dangerous. Let’s break down why and explain in more detail what your responsibility is in a cloud or SaaS application or service.  

The System – Your Provider is Responsible for the System, Not the Tenant (you).  

Let’s use an example, Jira Software, an Atlassian application. It is one of the most used applications in the world. Don’t believe me? Ask any of your developers or engineering team members! Once downloaded or hosted as server and data center editions, Jira is used primarily in Atlassian Cloud. Atlassian Cloud = SaaS.  

Now, think of Jira as the system and Atlassian as its owner and sole responsibility holder. That means, as the owner, managing all its infrastructure and security, keeping the lights on, and keeping the system safe and secure.  

A diagram of a systemDescription automatically generated
The System – Your Provider is Responsible for the System, Not the Tenant (you).  

     

The Tenant – You are responsible for Your Account and Data, Not Your Cloud Provider.  

If you’re a visual learner like me, here’s a good analogy for how best to understand a system and customer shared responsibility. Think of a parking garage. When you need to find parking, you go to a garage, you pay, and you can park. The garage is responsible for keeping the lights on and ensuring accessibility.  

But what about your car? What if it is scratched, or someone breaks in and steals something or helps themselves to something on your backseat because you left it unlocked? The garage isn’t responsible for this; you are.  

The garage is the system; the car is your data.  This means you are responsible for:

  • Recovering data/configurations that are lost (deleted, corrupted, encrypted, etc.)
  • Keeping backups and safe copies of your data regularly
  • Meeting compliance requirements for your organization (NIS2, DORA, etc.)
  • Securing your access and permissions inside of your company  

A white board with writing on itDescription automatically generated
The Tenant – You are responsible for Your Account and Data, Not Your Cloud Provider

Although this is a straightforward model, most IT administrators and application owners are unaware it exists. Because of this, we see the same three critical mistakes companies make:

Mistake #1 – Assuming the SaaS Provider Will Recover Data for You.  

Data loss is a given, no matter what application you use. Accidental deletions, bugs, corruption, and even insider threats are a day-to-day occurrence. Typically, as we see it, the customer’s first reaction is to assume they can ask the SaaS provider to recover their data. Of course, most SaaS providers will try to help, but the reality is that they cannot do this for you. In all Shared Responsibility Models, providers explicitly mention that data backup, and recovery from lost data must be made from customer backups.  

following diagram illustrates the areas of responsibility between you and Microsoft
Following diagram illustrates the areas of responsibility between you and Microsoft

Mistake #2 – Assuming System-level Backups Are Your Backups.    

Yes, cloud platforms and SaaS applications keep their backups. But these are system-level backups used for disaster recovery and data loss scenarios inside their infrastructure. These backups are not accessible for tenant-level recoveries.  

Incoming hurricane or power outage? Don’t sweat it, the cloud platform has system level high availability, disaster recovery, and backups to make sure your access and data are intact.  

Did one of your admins accidentally delete data? That’s your responsibility.  

For example, Salesforce keeps system-level backups but takes direct measures to inform customers of the importance of backing up their data.  

A screenshot of a computerDescription automatically generated
Best Practices to back up Salesforce data

 

Mistake #3 – Not Taking Data Retention and Compliance Seriously.

Let’s continue with the parking garage analogy. In case of an accident or due to the law, you must have insurance on your car; you can’t depend on insurance from the garage. The same applies to compliance.  

You can't rely on SaaS to be compliant if you must meet regulatory compliance (ex., HIPAA) or government-backed directives like NIS2 and DORA. You must be compliant.

For example, NIS2 and DORA regulations explicitly require you to create backups, test recovery, and provide documentation that you have completed all necessary steps. You cannot use the system-level backups for this, you must use yours.  

NIS2 mandates that essential and important entities implement baseline security measures to address specific forms of likely cyberthreats.

 

What does this all mean? It means don’t fall into the mistake that many may make before it’s too late. Make sure you have your data protected, you’re able to backup, and recover in the inevitable event of accidental deletion or malicious attacks. But most of the time it starts with knowing what you have in your data estate. While it makes for interesting conversation to know exactly how many SaaS applications or cloud services you have running in your environment, it often happens that not knowing is where it all begins. Stay tuned as we cover why you should know, and how easy it can be.

Author: Andy Fernandez, Director, Product Marketing, HYCU

Interested in learning more?

  • Elevate your capabilities with R-Cloud

eclipse
Follow us

Get started today

Seriously, you really need to experience HYCU to believe it.