how other risks come with data ownership. And if you'll recall,
it's the owner of the information that determines classifications.
And by determining the classifications, they determine the degree of security they
who has access to the information.
That's a really important role.
So when we talk about that, the question then becomes,
well, who owns the information?
Is it the user? Rarely is it the processor, is it? Senior management is the head of the organization, and the answer is,
the individual that is
in charge of developing your policy should know, and that should be well,
there should be a clear line of ownership because of the responsibilities that the data owner has
with the systems as well.
So we need to make sure that that's well documented
and that we have a clear path.
Four, uh, ownership to be traced.
All right, now, third party Chris.
So if I were to say to revolts
by outsourcing work, I eliminate my wrist.
Thank goodness I got somebody else to take care of all of this for me.
I can almost hear some of you laughing now because you've probably worked with contractors in real life,
I can tell you, you may take on more risk by outsourcing work because sometimes contractors outside source to subcontractors, to subcontractors and your several instances away from the folks that are actually doing the work.
You're turning over the control and access to 1/3 party.
So, you know, that's the very nature of outsourcing. You no longer have control over it.
the risks associated with that man we can think about. Okay, well, how do I know how my vendor hires people? How it that's people with the on boarding process is
Can I make sure that non disclosure agreements are in their proper place?
What sort of back up and disaster recovery and business continuity plan does that vendor
or the subcontractor of the subcontractor,
um, would are their requirements as far as
communications, what information they have to provide
How did they separate out my information from another coming
Are they going to meet the compliance needs that I have?
And once again, the answer is I don't.
But the way I do know
is first of all, before I select 1/3 party vendor, I want to get
I would get an assessment of that vendor from a neutral entity. Whether
they have certifications
He has a little bit dated. But you know,
what are their processes? Are there I su 27,001 compliant
Howard? They certified.
And then, of course, the next thing is I need a well written contract.
Now I can guarantee one of the things that you'll see come up in this material multiple times is the necessity tohave a well written service level, agree,
and to ensure the service level agreement details what your needs are.
We'd also like that right toe audit so that I can ensure my needs are being met, writes in the contract. I want to make sure they're following the contract,
and a lot of times, you know. Now, when we're thinking about third party risk, my mind immediately goes to the cloud.
So when you look at evaluations of cloud service providers, those audits air conducted based on how well the CSP, the cloud service provider,
meets their service level agreement. So do they do with their promising to do
Really, All the cloud is is just 1/3 party vendor right. We're just outsourcing. I'm outsourcing, perhaps management of my data
the network infrastructure and infrastructures as a service. You know, really, What type of cloud structure you have is determined by what you're outsourcing, if that makes sense,
there's there's very little that you cannot send to the cloud today.
So what it means is we're not eliminating Bris.
We're just transferring risk
to that third party. But remember, you cannot trends
We're still ultimately liable.
And even if the cloud service provider is responsible for a compromise
all they see is that we've compromised their dad, right? So we have to be very careful and purposeful. Not just that. But how do we send information to the cloud, right? That's not the clouds.
A cloud service provider.
that our employees how do we create accounts? How did they authenticate to service is in the cloud that's on us. A swell.
So we could just go on and on and then, you know, with the cloud also, you might hear about things like vendor lock in where the clouds stores your information very proprietary formats. So if you need to leave.
It makes it difficult to get your dad back.
What about data remnants? Once I leave a cloud service provider, I can't very well go there and shred their hard drive.
So that's where we need to use crypto shredding. It's just encrypting it in such way. Can't decrypt.
You know, these are things we have to discuss before we determine.
Yeah, we're gonna migrate to the cloud and we have to continue to assess it
as we move forward because
the cloud has a tremendous amount of benefit,
just like everything else. It brings risks in a swell
on. And then the last things for us. The risk scenarios go
Project and program management. I cannot tell you how many times
I have viewed projects that have failed. Maybe they were over budget.
Maybe they came in late. Maybe they used a resource. Is maybe halfway through.
on and on on so many reasons, usually
and this may be a stretch, but I've found almost always when projects fail,
it goes back to the very beginning of a project with identifying requirements and turning those requirements into a scope of work. If you've ever heard Scope, creep,
man, scope, creep will
and scope Creep is one of those things where you know, with Project Management you have a set amount of defined world,
and based on that set amount of defying work, you've created a budget and you've created this schedule.
But if all of a sudden I start finding that one piece of work leads to another leads to another
doing all of this work
that doesn't really add to the project that isn't defined by the requirement.
All of a sudden I'm behind schedule and I'm over budget. And I'm not moving towards our ultimate results of scope. Creep will kill you.
Lack of funding, changing requirements. Those of you that have been in project management. I bet you could add to that list sort of ad. And,
projects fail in many times
goes back to a problem with requirements if it doesn't go back to a problem with requirements and hearing those out
many times. Also, it's poor risk