Abdicating responsibility

Sorry I’ve been quiet on the blog post front but I’ve had a hectic few weeks involved in all kind of interesting conversations and events (even manning the booth at a couple of them), what’s been noticeable at these events is the amount of similar discussions I’ve had with businesses of all sizes, from small to large and all that’s in between and there’s been some interesting areas of commonality.

Over the next few weeks I’d like to share some of those with you. Up first has been something really interesting that has gone right to the top of my list and actually it came to light again this week when in a meeting with one of my favourite CIO’s. For this post let’s call him Bill (can’t share his or his companies name on this occasion), but Bill is a very astute CIO, very well connected, spends time doing all the things that you would expect, what is always interesting is when I bring something to the table he hasn’t thought about before.

Today was one of those rare treats, as I was sharing with him my last few weeks and some of the fascinating chats I’ve had, so what caught Bills interest?

Abdicating responsibility

Let me pose a question for you.

When we design our internal IT infrastructures, our compute, our applications, our storage, how many of us look at that infrastructure, that holds all of our key data assets and decide, that’s OK, I’ve built it now, it’ll be fine, I’ll just leave it there and make no provision whatsoever for protecting the data on that infrastructure?

I’ve built it now, it’ll be fine, I’ll just leave it there and make no provision whatsoever for protecting the data on that infrastructure?

None of us , right?

None of us design an infrastructure for our business and just trust the IT gods with our business data and assume everything will be fine and I don’t need to take any further responsibility for it, do we?

So here’s my question..

When we move bits of our infrastructure to a “cloud” provider, why do we then abdicate all responsibility for our data and say, that’s OK, Microsoft, Google, Amazon or <insert your provider of choice here> will just take care of it for me and I no longer need to concern myself with such triviality as data protection.

Whenever I posed that question recently there is a moment of realisation, that actually, in many cases that’s exactly what’s going on, we have not sufficiently considered the implications.

This isn’t to say all cloud providers, or all people haven’t, because of course they have and if you are taking infrastructure as a service, you may well be including levels of resilience and data protection, however the further up the cloud stack we go, i’m finding the less this is considered.

I was pointed last week at the very interesting AWS shared responsibility document (I suggest you go give it a read here) which makes very clear who is responsible for what.

The diagram sums it up nicely, AWS “responsible for security of the cloud” you, the customer “responsible for security in the cloud” and right at the top of this is Customer Data.

When we look at software as a service offering such as Office 365, this problem persists, Microsoft have a number of policies and rules you can set around data retention to try to mitigate data loss, however they do not backup your Office365 environment, you lose data in there, you have to realise it’s your responsibility and it strikes me that often we don’t.

How many of us are dropping our data into these platforms without seriously considering appropriate data protection models? If my conversations are anything to go by, quite a lot of us.

What’s to be done?

It’s certainly a problem, so what do we do about it?

I thought I’d share with you a couple of ideas that have come about during my discussions of the last few weeks;

  1. Understand the risk

    Out first step with anything like this, is of course understand the risk, if we are moving infrastructure and production data to any kind of service, then we need to understand the risks, fully understand who is responsible for what in your service agreement.

  2. Understand our requirements

    What are our data protection requirements for the information we are moving to our service provider, do we need to retain it long term? do we need it in alternate locations? How critical is the data we have housed in the service? Really all the same questions you would be asking for the data you have in your own infrastructure.

  3. How do we fulfill those requirements?

    Of course the last part of the equation is how do we go about addressing the problem, well it’s how long is a piece of string, a bit like it is when it comes to protecting our own infrastructure, maybe we want to simply backup, there’s a bunch of solutions out there that backup data from services like 365 to an alternate location, people like Assurestor offer “backup solutions”, or there is the Symantec approach of using enterprise vault to archive out of your cloud provider, and even vendors who you may surprise you, like NetApp with their backup for Office 365 solutions.

These are just the simple ones, protecting a service like 365, but there is considerations a plenty, if it’s software, platform or infrastructure as a service, what you need to protect and how, can vary greatly. But the point of this post wasn’t to provide every possible answer, it was much more straightforward than that, it was simply to raise the question, are you abdicating responsibility when you move your critical data assets to the cloud?

If you have been don’t worry, you are certainly not alone, because let’s face it, it is just not discussed, hopefully if nothing else, this post will encourage you to ask the question of your current and any future cloud based data infrastructures.

Go protect that cloud data.

If you want to contact me, please feel free to leave a comment here, contact me on LinkedIn or via the twitters @techstringy

Update – about two minutes after i published this post by friend Jason Reid over at Assurestor published an article about the very same subject – go and give it a read


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.