Graham Russell 6 min

The shared responsibility model is misunderstood


This video explores the hypothesis that SaaS admins value expert backup support, especially when they lack expertise in diagnosing and resolving data emergencies.



0:00

[MUSIC]

0:07

Our first hypothesis that I want to share with you is this.

0:11

It was about the extent to which these SAS administrators,

0:15

decision makers are or are not aware of the responsibilities to

0:20

proactively protect the information that they're keeping in and

0:23

on these SAS applications and platforms.

0:27

We had some surprising and I have to say continuing to be

0:30

disappointing results, the question that first asked is there in the screen,

0:34

which party is ultimately responsible for backing up the information kept in

0:38

your SAS apps?

0:40

Respondents could pick one of the various options.

0:43

52 percent of the respondents said, "Hey,

0:46

it's not me, it's the SAS vendor.

0:48

They're responsible for this."

0:50

39 percent said, "Actually,

0:52

responsibility sits here."

0:54

9 percent said, "Hey, why are we even asking about this?"

0:57

Because SAS data cannot be lost or corrupted and then there was 1 percent said.

1:03

I'm not really sure and I don't know.

1:05

Now, what's so disappointing about this is that actually for

1:08

the vast majority of SAS applications,

1:10

responsibility does actually sit with the end customer, with the user.

1:15

So, SAS applications will have a shared responsibility model with

1:18

a vendor says that they will invest a huge amount of time and energy to ensure

1:22

that

1:23

the application is available.

1:25

It's 99.99 recurring percent uptime that the system,

1:30

the infrastructure is protected.

1:32

But they're clear that it's the customer's responsibility to take steps to

1:36

protect

1:37

the information that they're putting into the application,

1:40

such that if there's a data loss or corruption event,

1:42

it can be restored and recovered.

1:46

The fact that so many people with backup and

1:49

recovered responsibilities still don't really truly understand the extent of

1:53

those

1:53

responsibilities is alarming.

1:56

We asked another question that followed on from this one and we were upfront

2:00

with

2:00

our respondents this time saying, "Hey, most SAS denters do make it clear that

2:04

customers ultimately have responsibility for the protection of their

2:08

information.

2:09

How does that change your view?"

2:11

And this time, actually, there was a shift in opinion.

2:13

This is 40 percent said they are yet.

2:15

Yeah, absolutely.

2:16

Yes, we are aware that it sits with us in the further 37 percent.

2:20

Yes, we kind of get that too.

2:22

But that still means there is over 20 percent saying even despite this point

2:27

about it being their responsibility,

2:29

no, no, we're not entirely sure it sits with us.

2:33

Andrea, I'd love your thoughts and commentary on the extent to which this lack

2:38

of awareness of the shared responsibility model continues to persist in the

2:42

world of SAS.

2:44

Yeah, thank you, Graham.

2:45

So I personally think that the confusion around who's responsible for what when

2:49

we

2:49

talk about data protection in SAS environment is much broader than just the

2:55

backup recovery, right?

2:56

It's the protection as a whole, as you mentioned earlier.

2:59

But just to limit one second the attention to the backup and recovery,

3:03

I think and I believe that there's still a lot of confusion between

3:07

backup and recovery and this is the recovery.

3:10

Just to be clear, backup and recovery focus on protecting and restoring data.

3:15

Data can be lost, for example, because of an accidental human error.

3:21

This is the recovery under the site,

3:23

consider a broader scope that includes the restoration of the entire IT

3:28

infrastructure and business operations after a major destruction that can be

3:32

a natural disaster, for example.

3:34

So disaster recovery includes backup and recovery, but it's just broader.

3:41

So now if we just look at this definition, it's easy to think that because the

3:47

SAS

3:47

vendors are responsible of the infrastructural part,

3:52

if something happens, it's not worth the thing that they will be in charge

3:56

on fixing it.

3:57

But let's try to analyze this a little bit further.

4:00

If the vendor is able to restore from a natural disaster starting from the

4:04

whole

4:04

infrastructure, of course, they have the ability to restore the data.

4:08

But the key question here is how fast?

4:11

And here the ball goes to the business and company side of court,

4:16

because the fundamental questions here are, what is the maximum acceptable

4:21

downtime

4:22

that we can accept, we as companies can accept, or our RT or recovery time

4:27

objective?

4:28

Or what is the maximum acceptable data loss that we can afford, or RPO,

4:33

or recovery point objective?

4:35

So when we think about backup and recovery, we are assuming that a

4:40

infrastructure is up

4:41

and running, nothing happened to it.

4:43

So in that case, the RTO and RPO are usually measured in tens of hours or even

4:50

minutes to ensure the minimal destruction to ongoing operations.

4:55

In contrast, when we talk about disaster recovery, that involves longer RTO and

5:01

RPO,

5:01

because we need to think about recovering and restublishing the whole

5:07

of the infrastructure and resuming the business operations.

5:09

And that can even take days for some complex organizations.

5:13

So going back to the original point, if we just rely on vendors because they

5:18

have

5:18

a disaster recovery in place, we cannot guarantee that the RTO and RPO,

5:24

for backup and recovery, are within the limits that we consider acceptable for

5:29

our business.

5:30

And that not even contemplates what the SUS vendors are committed to deliver

5:37

contractually, right?

5:38

Because some of them offer backup recovery options, but some of them do not

5:46

offer that contractually.

5:49

And for those of the vendors that offer the backup recovery, the two questions

5:55

are,

5:55

is the vendor backing up the data with a frequency that satisfy my own RPO?

6:02

And so recovery point objective.

6:04

And do we have service level agreement in place to ensure that when we have to

6:09

restore data that is done within my own RTO recovery time objectives?

6:16

So just to sum it up, as you already mentioned, responsibility fall on each

6:20

side,

6:21

vendors and companies, and that can vary case by case, right?

6:26

And because of that, it's important to perform a proper due diligence to make

6:30

sure

6:30

that nothing is misunderstood and actions can be taken quickly with no

6:36

confusion

6:36

when it's time to restore data that are critical for our business operations.

6:41

[MUSIC]

X

This is a test comment.

X

This is a longer test comment to see how this looks if the person decides to ramble a bit. So they're rambling and rambling and then they even lorem ipsum.


author