Ep 256 - Simplifying Compliance: Navigating GRC with Karina Klever

In this episode, Karina Klever, founder of Klever Compliance, shares her extensive experience in governance, risk, and compliance (GRC). With a career spanning over three decades, Karina delves into the fundamentals of GRC, breaking down complex concepts and offering practical insights on streamlining compliance processes. She emphasizes the importance of creating tailored policies, managing vendor relationships, and the necessity of passive evidence collection. The conversation also touches on the impact of AI and data retention in modern compliance frameworks. Tune in to gain valuable knowledge on demystifying GRC and making it more manageable for your organization.

This podcast is made possible by GTM Delta

Episode Transcript

(00:00):
Music.

(00:19):
I'm Karina Clever with Clever Compliance. I am a founder of this company.
We've been around for close to eight years now.
We help customers with their compliance problems, standing up governance,
risk, and compliance kind of centers of excellence, COEs I call them.
And it's an old, old term going back, gosh, 20, 30 years now.

(00:40):
I've been in IT since April 1989. 89.
They did the first 15 or so years being a developer on an AS400,
didn't like it, became a project program manager.
And then in 02, shifted over to audit, really not by my own design because a
former CTO called me and forced me into the position.

(01:04):
You were voluntold into it, basically. It was a great, it was a great opportunity
after he said, name your price.
And so inherited inherited a bunch of audit findings.
And that's kind of how I started in the audit world and just started learning
all about the influences that influence our company operations.

(01:25):
And since then, it's been just different blends and variations of compliance and GRC.
Sometimes it's just vendor management. Sometimes it's support delivery.
Sometimes it's, you know, focused on a competency area like change management,
although vendor management has really been taking a big one lately for a bunch

(01:47):
of different reasons that I hope we can get into.
And when you look at the overall picture of GRC and the steps that are involved,
they're actually very repetitive and very predictive, and they're really not
as scary as people make them out to be.
So I really want to hone in on that point during this podcast.
For sure. And I'd say that that's actually why it's rife with error and potential risk.

(02:12):
Because as a checklist builder for like server build documents and security,
I lived this life for 20 years.
And one of the things that I would do is like really build standard operating procedures.
And whenever you do them, I've also struggled with ADHD and I've real difficulty
following ordered lists.

(02:32):
So the irony is I would I would never use my own list, but I would build in
assumed steps that or I wouldn't write them down.
So the reason I wrote lists for procedures was to make myself kind of verbalize
what I was doing as I was doing it so that somebody else could do it.
And then as I do it, it made me sort of rethink like, oh, can I optimize this?

(02:53):
And so my angle was much more around process and process optimization.
But then as I got into doing business continuity, disaster recovery,
and security, it was like, oh, wow, this is really wild because it's very much
built around practice and procedure.
And then there are, like you said, GRC is a complex thing because people think, what does it mean?

(03:17):
I've got a governance team well okay that's fine
but then there's a compliance aspect and like what's the
difference between governance and compliance and what's the our standard people
really they struggle when people change titles it was the chief compliance officer
then it was the CISO and anyway it's a it's a complex area of understanding

(03:39):
for people that aren't in it And that's also probably why it's a little daunting,
you know, for folks that are, I'm in tech, I'm just trying to do my job.
And then these flipping out of people keep coming by and asking me,
can you pull a record from this and get like, so it feels almost adversarial
in the way sometimes it's practiced internally within the org.

(04:01):
So I'll say that's the reason why it's an interesting thing for me that you've
been very good at both explaining it and executing at scale in teams from ground up.
So let's talk about the G, the R, and the C.
Let's start with the basics and set up folks that are brand new to more on what

(04:24):
the totality of GRC is on governance and compliance.
Sounds good. Yeah. So governance is how you're watching your own operations happen.
So you want to create a governance structure across your entire company that
has these little hook-ins that
let you know whether or not that competency area is doing well or not.

(04:47):
Risk we're going to actually talk about as well. It's actually a lot simpler.
So much, all of this is really, I'm going to keep using the word simpler.
And the reason why I'm doing a lot of these webinars and podcasts is because
I'm finding so many people being overwhelmed and confused by this topic.
It's very sad for me that they are crippled and they're trying to stand up these programs,

(05:12):
but really they're focusing on the spreadsheet versus the actual internal operations,
and they're leaving big, wide, gaping holes because they're following the spreadsheet.
So it's kind of, you want to come back to your actual operations.
Compliance is you want is from the word comply, right?
So when you have these controls established in your company,

(05:34):
you want to comply with them. And then that feeds your governance program.
If you're not complying with your own controls, now you have a risk.
And that's where risk comes from.
So I think the most important thing to start with is kind of the beginning, right?
So we have these things called regulations and frameworks.
And for this podcast, I'm going to use them collectively as the word influences.

(05:57):
They influence our company. They're outside of our company.
There's a big, hard brick wall. Imagine a firewall between your company operations
and the influences and regulations that you have to abide by.
So if we think about what frameworks are, they're made to be broadly applicable.

(06:18):
That's very important to remember. When they are written, there's a bunch of
super smart people sitting around a conference room,
that's all they're doing, for an elongated period of time, and they want to
create controls that are broadly applicable. That's the most important thing to remember.
They're vague, nebulous, theoretical statements that are just very ethereal almost and beautiful.

(06:43):
They're written for, not for your company.
They're written against all levels of maturity, all platform stacks,
all industries, most industries, right?
They're written against, it doesn't matter if you have one location or 72.
It doesn't matter if you're going to adopt the entirety of the framework or a little bit.

(07:05):
So what's really important here is to acknowledge Acknowledge that that framework
that you're wanting to adopt is written broadly, and there's a ton of them,
right? And I mean, I'm not even going to go into all of them.
You know, COVID-19 is one of my favorite.
COSOs, you know, SOC 2s are based on COSOs. You've got ITIL V3 and 4,

(07:26):
and of course, you know, the V4 is this big debate now. You have ISO standards
that are globally adopted.
You have CIS, you have CMMI, you have SPARC Institute, you have SIG shared assessments.
The one I kind of want to talk about that everyone's buzzing about is NIST v2.

(07:48):
So if you look at the abstract, and it's on page two of NIST v2,
it highlights the fact and it opens up this framework by saying this is only
guidance, guidance is literal, that can be used by any organization.
I'm actually reading real words out of the abstract, regardless of size, sector, or maturity.

(08:10):
And the CSF does not prescribe how outcomes should be achieved.
So in the very beginning of the NIST V2 framework, we all have now noticed that
govern band going across all of NIST.
It's such a critical part.
But in the very beginning, even NestV2 says to you.

(08:31):
This is guidance. This isn't prescriptive. You don't have to follow all of it verbatim.
And that's very important to acknowledge as far as frameworks go.
I think the days of, especially when they became new, the earliest one I bumped
into was Sarbanes-Oxley.

(08:52):
And it was really tough, especially for IT pros at the time,
because we hadn't necessarily seen the level. I mean, back then it was SAS 70, now it's SOC.
There were different things that were applied, but for the most part,
there wasn't as much vendor relationships.
There wasn't as much, there wasn't cloud computing, there wasn't data transfer.

(09:13):
You had metropolitan area networks and wide area networks. You owned most of it.
And then every once in a while, because I worked in financial services,
we would have a third-party partner where we would have to ask them for their
checklist to make sure that they were compliant to meet our compliance because
we had the responsibility to carry their, certify them basically.

(09:36):
And when Starbanks Oxley came in, it was now internally applied.
And we understood that we didn't know what loosely defined was.
We didn't understand that you can be wide or not narrowly defined,
but this idea that here's a framework, here's guidance,
but then at the end, an executive is signing their name on a contract that they

(10:03):
are responsible for the outcomes if it were to go sideways.
Immediately now all of a sudden, it gets really narrow on like,
it may be broad in definition, but it's narrow on the execution because there's
a real human risk in it going wrong.
And I think we started to say, hey, we need to talk to the executives and the business teams more.

(10:26):
And we started to see collaboration across groups.
That was way back then. And then a lot has happened since then,
which is why, as you say, this idea
that a lot of IT folks don't have the understanding of outside of just IT,
what it means around GRC and specifically on regulated.

(10:46):
And like NIST, when you ask any IT pro about NIST, cloud computing,
we've stuck by the standard definition of cloud computing for however long.
And it was always, it was the only thing that NIST was on for most of the nerds in the world.
So it's kind of cool now that more people are becoming aware.
But also, as you say, it's like, they're still a little frightened about the

(11:08):
impact and reality of what this means.
Thinking it's like execution of a rule versus guidance towards a standard.
So interesting you bring up SOX. So Sarbanes-Oxley is actually a regulation, right?
So that's kind of the second part of that influence bubble, right?
So the first part is that framework and the second part is a regulation.

(11:31):
So a regulation is Sarbanes-Oxley, is HIPAA, for instance.
It's any law that you have to abide by, right?
You know, FDA, if you don't abide and you're brewing drugs and you don't abide
by the FDA, well, then you're going to get in trouble, right?
If you're a bank, we saw it just last year, a few banks closed down, right?

(11:52):
Because they're governed by a regulation, right?
GLBA, Grammage Supply Act. So you have to know, based on your company and your
operations, which frameworks and regulations.
So the regulations you have to abide by, the frameworks are really there for guidance.
So collectively, these two create this bubble called influences.

(12:17):
Again, that brick wall, it's outside of your company.
Remember, when auditors show up, they know what those frameworks and regulations say.
They don't need a regurgitation of them on your spreadsheet. internally, right?
And now we're missing the critical spot. Now, when we have that collective spreadsheet
with these regulations and frameworks, this is where it goes south for most companies.

(12:42):
Because the output of that combination, you need to take it,
you need to bucketize it into these competency areas.
And now comes the human factor, you have to sit down around a conference table,
hold hands, order pizza or sushi or vegan or whatever you want to do, hold hands.
Some people want to say a prayer. That's fine.

(13:03):
Whatever will make you.
Be able to make decisions that apply to your company.
And now you do this thing called I call into the force. Now, next, near, never.
Look at the bucket of controls that you do now.
Those are your big, fast, hard wins, right?

(13:24):
You're already doing those functions.
You are already actually creating collateral to show that you're doing them, right? Right.
You're you've already executed on so many of these actual requirements that
now maybe it's just a matter of just documenting the controls.
Right. So you already you don't.

(13:47):
A lot of people try to boil the ocean for compliance and it's just not realistic.
And they just screw themselves at the end of the day with it and they overcomplicate themselves. selves.
And then they call some big consulting firm, you know, I always say,
if you don't do into the fourth, it's the equivalent of having a recipe with,

(14:08):
you know, with 12 things on it for tonight's dinner.
And you go to the grocery store, and you buy one of every single thing that
they have at the grocery store, you buy one of every vegetable,
one of every fruit, one of every box thing,
one of every canned thing, one of every refrigerated thing, one of every meat, one of every dairy,

(14:29):
one of every cheese, you haul it all home.
Only to get to those 12 things that actually you need for tonight's dinner.
And without this appropriation, this thing called end to the fourth,
that's what you're doing.
You're literally downloading the entirety of the grocery store into your GRC platform.

(14:49):
And so now the first one is now, what are you doing now that you can document?
What are you going to do next?
So that's your next target. That's your about one to three year goal,
depending on the company.
Appropriate the project manager for it. appropriate the
budget prioritize the controls that you want to hit
on next then there's going to be near so it's your three

(15:10):
to five year strategic goal that's what shows up on
your quarterly roadmap and then there are nevers there are actually even out
of regulation you can exclude controls that don't even apply to you and i'm
going to use an example of 21 cfr 115 so that particular control says,

(15:31):
if you make goat milk ice cream, you have to use goat milk. Why is this important?
Because when you're at, you're a pharmaceutical firm, global pharmaceutical
firm, and you're brewing drugs in your cauldron, and you have a recipe list and a temperature list,
and you're doing all of these things to make sure that the output is repeatable and consistent,

(15:51):
but you don't make goat milk ice cream, but you have to follow the FDA.
So what you do is while While you're sitting at that table, you can actually
figure out how to exclude even regulatory controls that don't apply to you because
why would you track them?
It's silly, right? So this middle part of appropriating those influence controls

(16:13):
out of those regulations and frameworks, this is the part that everyone is missing.
And this is the part at the design, architecture, foundation,
whatever example you want to use, blueprint. Some people say,
you're missing that blueprint and you're coming up to a lot with a hammer and
a nail. Let's build a house.
But you have no idea where the plumbing is, where the electrical is,

(16:36):
what the layout is, where the walls are even going to go.
But you've got your hammer and nail. Let's go.
Right? Right. So this is where it's really important to just stop at that moment
before uploading anything into a GRC platform or an IRM.
Integrated risk management is kind of equivalent now. The industry is starting

(16:56):
to use this language just like they're starting to use third party risk management
instead of vendor management.
TPRM, it's called. So as you're bringing this stuff into your GRC platform,
form, make sure you're only bringing in the stuff that directly applies to you only.
Yeah, this is the challenge that, as you say, there's so much that could be broadly applicable.

(17:21):
And even in finance, there's mortgage finance, there's personal banking finance,
there's investment finance, there's hedge funds.
There are, even within investments, there are different types of investments.
And on the licensing side for brokers and such,
there are different licenses for different capabilities

(17:43):
that they're allowed to execute and at the same time on
the back end of course to run operations for those then
there will be subsets that are applicable and subsets that aren't and i think
that's one of the pain points for a lot of folks in in technology in particular
because we find ourselves having to go through and just like try and explain

(18:05):
away why we shouldn't have to check a checkbox either way.
And we don't necessarily understand the risk.
Mostly it's risk avoidance because we don't want to be subject to the potential,
like if there's a non-compliance, that's really what we're trying to avoid.

(18:26):
We don't want to avoid non-compliance because we want to get away with it.
We just don't want to have to be compliant for something that we don't actually
have to be concerned about if it's not truly narrowly applicable.
Obviously, we're nerds. We tend to be frightful of anything,
especially the security team.
I've been at many a security professional's office who they're the only ones

(18:48):
that know where the key to their desk is because it's in their pocket.
Everybody else is just, they walk away from their desk and good luck and may your God go with you.
I'll see you tomorrow morning right right so
it's it's funny that we do in in
technology we tend to play a little fast and loose in general when it comes
time to then do testing and evaluation it's like okay now we get super serious

(19:13):
where's my checklist right right so i mean i think it's important to say that,
based on the things in the influence that you do have to fight that do apply
to you right so So let's say we're in that now bucket.
So we've gone through our influences, our frameworks and regulations.

(19:34):
We've sat around a table. We had the decision makers in the room.
And now we've identified and isolated really the controls that apply to us specifically.
So now we get into this document creation posture.
And so I'm going to use change management just as an example,

(19:54):
because everyone knows what change management is. It's kind of easy, right?
So most regulations and frameworks will give you some control,
but the core of what they're saying is you ought to have a change management
tool, right? Right. You ought to have a change management tracker.
You ought to have segregation of duties and change management because I don't
want the same person to request a change and code a change and approve a change

(20:17):
and deploy a change. Right.
That says maybe put a million dollars in Karina's account.
Right. So that change, we want to
make sure there's segregation of duties throughout the life of the change.
But let's say one company, their change management policy says,
we're okay to go to cab only once dev and QA is complete.

(20:39):
We're going to have a cab once a week. We want to have two signatures as our
approval before we go into production.
And our requirement as a post-implementation review is to send notices to affected end users.
So there's probably more, but let's use these as an example.
The next company's change management policy will say, we have to have the impacted

(20:59):
business sign-off before we go into production.
We're going to do CAB twice a week. We have a very large volume.
We have a CAB voter base of seven people. We have to have four out of seven
approvals before we go into production.
And our requirement post-implementation review is to update the CMDB,
the Configuration Management Database, right?
So the reality is, even though there are different controls inside that change

(21:25):
management policy, that change management policy is satisfying Sarbanes-Oxley.
ITIL, NIST, FDA, GOBA, and on and on and on because every single regulation
and framework will say to you, you got to have a change management policy.
And some of them will have some innuendos like you got to have a post-implementation

(21:47):
review or you've got to have a rollback plan before you go live.
So you're going to have these innuendos, but the reality is you just got to
have the policy that works for you because once those controls inside that policy are defined.
Now you can actually gather passive evidence, which is another huge thing that

(22:08):
we're all missing doing on an active basis.
Have a ticket be generated every week, every month, every quarter,
whatever is your frequency cycle, and have that ticket say, hey,
just send me the approvals for this week for your caps.
And now you've got passive evidence being collected.

(22:28):
Deducted it's small and it's actually palatable
so you can keep up with it so all of
a sudden in a year when the auditor shows up look you've
got 52 weeks of evidence on every single cab that's gone through every week
if that's your frequency and now you don't you can see all of the approvals
in one spot all of your controls whatever your controls are that you've defined

(22:53):
you can have them all be in one spot.
And the big, the better thing in this is your auditor isn't going after your
change crew to say, Hey, give me a screenshot.
Hey, I'm going to interview you because you haven't gotten me a screenshot.
You're actually preemptively already making all of this available in a passive
fashion as part of your normal operations.

(23:14):
Yeah. And interesting thing on that is, especially with a lot of technologies,
there can be changes that occur.
Go back and forth. And they're right at each point.
One of the oddest things I had, I remember getting a traditional,
you know, regular audit, no big deal.
I was like, okay, it's just more of a time spend than I was never concerned.

(23:37):
And in fact, we welcome, if we find a vulnerability or a risk,
then it's like, yeah, I'd rather find it this way than the hard way.
And the auditor was super fantastic, went through, he's like,
this is the stuff I'm going to ask you for.
But then And at that point, he's like, okay, it's like a factory line.
Like, all right, I'm going to pick one window off the line, and I'm going to

(23:57):
take a hammer to it. And if it shatters, but it's pointy, that means there could
be a risk with your glass.
This whole batch is going to stop. We're going to test four more.
That's like that type of inspection. So here we were. It was Active Directory user management.
And this was for, at the time, it was a SAS 70.
And so it's like, make sure that when somebody is terminated,

(24:17):
that their account is deleted within a period of time. And again, there are ranges.
It was reasonable is used a lot.
And I mean, even in the law, it's often used like what's a reasonable expectation of privacy?
Would a reasonable person do this?
There are certain things that we deem as they call it natural law,

(24:40):
but it's more like just normal average reason. Anyway, so we go through this
whole thing of like, account was deleted, reasonable time, no problem. 12 hours later, gone.
Life is good. So they go to do the proof on it.
Let me just grab the current state of that particular account should be archived.
You look at it, it's active. Yeah.
Right. Okay. What's going on here? Well, that person was a student,

(25:04):
had been hired back, and then had had their account reactivated again.
But at the time, at the point in time when the audit was meant to cover,
now it was sort of in flux.
And this is where this passive evidence and for IT folks is like building checks
and automating as much check and balance as possible so that you know what's coming.

(25:27):
Why would you want to start all over again with a brand new blank spreadsheet,
go through 8,000 different things? 14,000. Right.
That's even more, right? So 14,000 things that if I had to, it would be like
doing your taxes every quarter. Like it would be terrifying.
Well, now that we have to do them for your business. But that's,

(25:48):
so that from my experience was like, what you're saying hits home so hard that
build procedures in day to day, don't treat it as like a one time thing.
And then by doing that, that systems thinking and automation thinking on the
technology side, empowers the business to also be like, hey,

(26:08):
let's organize ourselves so that we are more constantly ready.
And like, you should be ready from a governance and risk perspective and compliance,
but you should be ready to just jump in and someone says, hey, quick question.
You know, line 7,248, you're like, gotcha. No problem. We, we, we, we manage that.

(26:30):
So you shouldn't have a line 7,248 to start with, right?
That's the most important thing. Yeah. That's the most important thing.
But B, you bring up a few really good points.
Number one is one of the largest risks that we have right now as an industry
are non-employee on and off boarding procedures, right?

(26:50):
So the employees are getting really well controlled through HR.
And I'm going to talk about that in a second. But when that rogue manager brings
on a consultant and fills out an access request form,
they tend to forget to fill out the form that says now remove the access because
the person's gone, the consultant's gone.
And this is one of our largest risks are the employees or the workers who bypass

(27:18):
the employee triggers because a lot of the core employee triggers are locked down.
Now, the second thing I want to say is what you were describing on having that
passive evidence collection be actively gathered on an ongoing basis.
That is governance in itself.
Right. So you have procedures that are policies or processes or templates or standards.

(27:42):
I don't care what you call them. There are debates that go out that are like,
you know, books worth of debatable topics of which vocabulary word to use.
Whatever your company uses, rock on.
And if that's what you guys are used to using, OK, let's scope down what that
quote is as long as you're doing it. Right.
Because if you don't have those auditable control statements inside your published

(28:07):
documents, when your workers show up, do they even know what ballgame they're playing?
Right. I mean, I have a picture in my presentation that has a kid with a with
a basketball jersey holding a softball bat and a football helmet on.
Different rules, different ballgames. But when we have people come into our

(28:27):
companies, a lot of times that's what they feel like. They're like, what am I supposed to do?
And when you omit controls that are very specific and applicable to your operations,
workers come in, they have no idea what the hell's expected of them.
They don't know how to succeed.
They don't know what they're supposed to be doing most of the time,
right? And so we need to make these controls very, very specific.

(28:51):
That's just one of the reasons. The other reason is inside your published documents,
you need to have statements down at
the bottom that say, these are the cross-referential internal documents,
and these are the controls from those influence documents that this document is satisfying. fine.
We are continuing to miss that piece, that bridge.

(29:14):
And that is the thing that a lot of times, that's all you really need is to
show the auditor, right?
So auditors can be internal auditors. They can be the externally hired auditors,
and there can also be regulatory auditors.
And they kind of go in that sequence, right?
Your internal auditor, if you got to pick a best friend auditor,
pick your internal auditor to be your best friend, right? Because you want that relationship.

(29:38):
You want that give and take and to have them explain to you,
what are you doing wrong?
Where can you get better? Where's my biggest risk? These auditors that are showing
up, what are they going to look for?
And then whatever report they have will be handed over to the next level auditor.
And the federal regulators, you never want them to really show up.

(29:59):
I mean, they may out of need and requirement to audit you, but you want to make
that experience as short as possible, right?
And if you have your ducks in a row, they come in, they see all they need to see.
I mean, I've been in rooms where there's 12 federal auditors sitting around a conference table.
They get a big pamphlet. We go through everything and then they say,

(30:21):
where's lunch? Right. So, so.
What auditors love to see unanimously across the board, regardless of who they're
representing, is your own risk identification and risk mitigation.
So I think we can get into that now if we can move on to the next topic. How are you? I like that.

(30:41):
And I can say that, honestly, neither Karina nor I endorse the purchasing of
lunch for federal auditors as that would be considered a gift,
which could be considered.
We simply escort them to the area where they pay for their own lunch.
Always, always, always.
Isn't it even like little nitpicky things it's so funny that like i said it's the fear.

(31:04):
Of reprisal and the fear of retribution like unknown we just we don't know what
it means when we're on when we become non-compliant it may just be like hey
can you fix this like today oh okay and sometimes it may be like hey we gotta
now come back every month there are certain.
But we just don't know right and

(31:27):
there's like there's so much technology now like there's no reason why
we shouldn't have more comfort at least
in the ongoing process which you know we'll talk much
more about kind of how how much has changed in the time that you and i have
been at this yeah right right so okay so when we have those documents and the
controls are written they have to be very specific right we have to know who

(31:49):
the owner is that's the first thing the second thing is how frequently does it happen?
And again, depends on your own operations, maybe weekly, maybe daily,
maybe monthly, maybe quarterly, maybe annually, right?
The other thing is, you have to omit those theoretical words.
Now, they're all over the place. And they're all over a lot of the templates

(32:12):
that we're seeing these days.
And they're a little dangerous, right?
So So words like periodically, frequently, routinely, occasionally,
recurringly, you know, I'll say periodically to me that might mean a week to
you, it might mean monthly.
You know, I'll say routinely, it might mean daily to me, to you,

(32:33):
it might mean quarterly.
Right. So when we have these three things inside of our controls,
who owns it? When does it actually happen?
Right. So getting rid of those nebulous words. and what is the control itself?
So what is that evidence going to look like, right? What are we measuring for here?

(32:53):
Now, when you have them written with these three elements in place,
you know if it fails, right?
This is the simplest way to make sure that you have very specific output requirements
for if I've met these three things, I'm good.
If I haven't met these three things, something's wrong that instantly goes onto
your risk registry. So let's talk about risk for a second.

(33:17):
There's two types of risks, right?
There's a risk, again, framework, right?
Just like there's a framework for your general compliance controls,
there are risk frameworks.
You know, ISACA has a risk IT framework.
ISO has 31,000, which is a, you know, risk management gauge.

(33:40):
CIS has the risk assessment method that's called the RAM. NIST has, you know, 837.
It's basically say, think about environmental risk. Think about reputational risk.

(34:00):
Think about whether a tornado is going to come through and take the roof off.
Think about opening up a data center in Los Angeles, right?
Think about, because of the earthquakes, right? So think about these things
that could potentially happen.
And as you're doing that, and those are important to acknowledge and use as
another framework, but as those things are happening, if your Your documents

(34:22):
are written the right way with controls that are written the right way.
Now you instantly know if a control is failing. That is governance.
Now you can say, oops, I have a failed control. Let's kick it over to the risk
management registry and figure out what's going wrong.
Is it the way we've documented it? Is it the way that the department is doing it or not doing it?

(34:46):
Is it the platform that we're using? So now you can actually ask all of those
real self-assessment kind of questions about why that control is failing.
And now you can proceed instead of, I mean, some of these controls on these
14,000 spreadsheets, I mean, you can't even read what the hell it says.

(35:08):
So how the hell do you know if it's failing or not, right? Right.
So, so that is kind of the best way to manage risk registry.
And then if you don't have questions on that, we can kind of get into some of the competency areas.
Well, I do, because this is what, what are the, what are the people and sort

(35:28):
of the team definitions in an organization that transfer?
Because some stuff sits under maybe the CIO, some sits under the CISO,
some sits under legal and compliance and human resources.
There seems to be compliance and regulatory and governance across all of them.

(35:51):
Some may be shared, some may be very individualized to specifically HR systems and HR activities.
But I'm curious, Karina, what is the modern...
Organization look like that supports these types of team interchanges?
So I'm going to hate to give you this answer, but the reality is it depends, right?

(36:13):
It depends on the industry. It depends on the size. It depends on where your operations are.
If you're a global company, for instance, consumer privacy data may be handled
a little bit differently because of, let's say GDPR in EU, right?
There's over 120 consumer privacy laws globally.
Five of them are now inactable in the US. We have another two states coming

(36:37):
on board July 1st, right? So we're going to be at seven.
And even though seven have, and you know, the proposed federal privacy law actually
cites a patchwork of state privacy laws, right?
Because one state, you have 45 days to to fulfill the request.
Another one, it's 30. Another one, it's 60, right? One says,

(36:59):
I can, you know, ask for an extension.
The other one says, no, you can't. So, I mean, there's, there's all of these
different variations to even U.S.-based consumer privacy.
So, a lot of times, the CISO is a very technical person who has grown up in
the ranks and knows everything about everything.
It's many times, unfortunately, a single point of failure because

(37:21):
they do know everything about everything and you
know to have compliance be part of
their organization is sometimes a conflict of interest
sometimes they bring in a compliance group or
person just to give give it to somebody else because they don't want to do it
right yeah it's you know sometimes in publicly traded companies you'll have

(37:45):
a compliance group under the cfo or the CRO is a chief revenue officer, right?
Or financial officer, you know,
you may have a compliance group out of the legal department, you know,
I'm going to pause for one second my long answer to your short question.
Vendor management, I'm going to kind of hone in on this real quick before I forget it.

(38:09):
A lot of contracts that are reviewed by legal are reviewed by legal for completely
different checkpoints opposed to what a technology group might be reviewing
a contract for with that vendor.
And some of the things I've been noticing recently, number one are breach notifications.
There's an admission to a commitment from that vendor that says,

(38:33):
I'm going to let you know if I've lost your data, is the first one.
The second one is a disclosure on your data being sent to someone else.
Now, please remember, even if you have a mature vendor management program and
you ask your vendor for a SOC 2, SOC 2s exclude subservice organizations.

(38:53):
I'm going to say it again. It's very important.
SOC 2s exclude subservice organizations.
Based on AICPA trust principles, remember SOC 2s were originally started by CPAs, right?
So they were looking at specifically financial information and your SOC 1 turned
into a SOC 2, which included more IT controls.

(39:15):
SOC 1s include financial controls. So, because you're working with a vendor,
and you're, let's go to NIST, you're sharing, transporting,
or storing, that vendor is sharing, transporting, or storing your data,
they may not have their own data center.

(39:35):
It's very likely that they take your data and send it to their vendor.
That vendor might send it to their vendor. And so this chain reaction really
has a hard stop that you cannot trace because of that contract and because of that SOC 2.
So as part of your vendor assessment program, you have to very,

(39:55):
very carefully and specifically ask about, do you share my data with someone else?
And if you're sharing my data with someone else, who is that?
How long are you holding on to my data?
And where are you retaining my data? Because you know that downstream controls,
those physical and logical access controls, they almost kind of disappear.

(40:18):
And now if the frequency of your data is frequent enough, the backup frequency
is frequent enough, the downstream data, four or five vendors removed,
probably about as good as only yesterday's data.
So not that much of a variability, right? And the other thing you want to ask for is COI.
You want to ask for cyber insurance specifically from your vendor and what the amounts are.

(40:42):
Set the amount inside your own company as a threshold.
Maybe it's five. I wouldn't go less than five, preferably 10 million.
So, but your legal department, they may not be checking for these things, right?
So in IT, you need to check for these things in addition to your basics, your SLAs, right?

(41:03):
And so here's another huge thing that we're all missing.
When we have controls that are written inside our company documents that say,
my MSSP is going to take care of incident management for me,
you where is that evidence why
why is your vendor not providing you

(41:24):
weekly monthly at least qbrs on a recurring basis i walked into clients it's
two years since they signed with a vendor and i say okay what kind of artifacts
are they giving you because we're going to line this up to our compliance program
and i get blank stares why i
i don't know we just we just pay them legal Google didn't ask us for that.

(41:44):
Well, why don't we leverage the fact that they are a company that is providing
a service if they're scanning,
if they're do a ticket count, do a something, figure out a way how to validate
the fact that this vendor is providing you evidence for the controls that they're
accountable for in your governance program.

(42:06):
And not only that, now you can take a look at those metrics and say,
you suck or you're are amazing.
I want to expand my services or you suck so bad. When does my contract end?
I'm going to give myself an RFP right now so that I can find a replacement for
you so that at the six-month mark, I'm going to start parallel processing with
the replacement, right?

(42:27):
And until you get those metrics, you never know.
There's no commitment to you for those SLAs.
Well, SLAs are even, that's always a classic in technology teams as well,
is that an SLA is merely a recommendation, not a really hard and fast thing.
And if anything, it's usually about financial compensation more than actual service availability.

(42:53):
So if you have a third party provider and they provide a service and they guarantee,
and the SLA is three nines of uptime and they totally blow it out one day.
Then they say, hey, we're really sorry. Tell you what, we'll knock one 30th
of your bill off this next month.
Our business was wiped out for nine straight hours. We're a financial trading environment.

(43:18):
This taking $1,000 an hour off of my bill is not fixing the problem that I have to deal with now.
And so understanding not just, you know, what the SLA says, but what's the impact
if it were to be breached, you know, and I say breached in the mean that we went beyond it.

(43:41):
And then we talk about actual breach, as you say, COI and understanding that
there's insurance requirements, because if it does happen, there has to be some
sort of financial recompense and there has to be some way.
We're not trying to punish people. We just have to be ready because if something does happen.
Everyone downstream of that is now in this legal fund, like an end client.

(44:06):
You know, we've got Betty in Wisconsin who has got her investment with,
you know, Company X and Company X decided to offshore some of their stuff.
And then all of a sudden their back end payment processor moved to Texas and away from Colorado.
All the stuff is moving around. It's not Betty's problem to know.

(44:27):
It's all of our problem to know. Yep.
Yeah. So I'm going to dive into incident management really quickly.
And then I do want to talk about logical access controls and access controls in general.
So incident management, because we were just talking about vendors and tickets, right?
So one thing that I'm seeing very frequently right now is a swivel chair approach

(44:48):
for multiple different ticketing systems, if the company's large enough,
and lack of separating the end users,
I need something, which is an ITIL terms a request versus something's broken,
which is in ITIL terms, an incident, right?
So a lot of ticketing systems will combine the two types of tickets into one.

(45:10):
And so you don't really always have a very good sense of what's truly broken,
especially when you have a flood of changes, incidents come in after a change
record, you need to quickly be able to isolate them because your change may
have broken something, right?
We've seen it all. I got bad news for everyone's Once in a while,
somebody in the help desk, their MBOs are attached to the number of incidents in a month.

(45:34):
Can we call these incidents events like there may be reclassification to satisfy
an internal business SLA?
There you go. They're not meaning to be on the wrong side of compliance,
but they may not understand what, yeah.
So it can be confusing that we don't know what it means.
Yep. So you've got first, how you're treating the end user. Second,

(45:56):
internal system alerts, right?
Thresholds, quarantines, some sort of a trigger or alert that's happened.
Make sure that that dumps into the incident management platform, whatever you're using.
I'm very tool agnostic. And if it's repetitive,
create quick knowledge-based articles that are actually embedded into that ticket
so that whoever picks it up can actually execute on fixing it and at least has

(46:21):
three attempt steps before there's an escalation that happens.
Also, vendor alerts are very important.
Vulnerability tools, external platform notices, right?
Maintenance notification requirements like your preemptive SSL cert that's going
to expire. buyer, create the ticket three months before it does, right?

(46:41):
Identified threats and scan results, provisioning and approval requests, right?
One company, we sat down with IT and identified 37 possible tasks for onboarding
anyone, any role, physician, temporary staff,
student, full-time employee, administrative worker, and we had a,

(47:02):
the max possible number was 37 different tasks.
And so based on the role that was actually being brought on,
you know, if it was a physician, we enacted task number two,
three, and four, then seven through 12, and then 27 through 32, right?

(47:23):
If there was a different role that came in, there would be a different sequence
of tasks that would get enacted.
A different role would come in, a different set of tasks would be enacted.
And in every single one, we actually had knowledge-based articles that would
create the knowledge for that technician that would pick up that ticket to be able to provision it.
And so basically your least privileged permissions were actually enacted that way and enforced.

(47:51):
So now I'm going to talk really quickly about access controls, right?
So access controls must always be associated to a role, never a human.
It's a really quick story.
I worked for a company where there was a staff of 152 sales folks and one of

(48:16):
them came in crying into my office and confessed to me after some coercing that she changed her
peers commission check that the peer was supposed to get 7,000 some hundred
through 400 something dollars.
And she rolled back the, the, the, the decimal and the peer only got a $7 check

(48:38):
while the peer was, she was mad at the peer because this woman ended up having
an affair with her husband.
They met at a holiday party two years before that. So now she just found out
about this, she was very resentful and went to go change this woman's commission check.
So a bunch of questions, and I'm going to shorten the story, but.

(48:58):
Basically, when I started figuring out why she was able to have access to change
a peers commission check and her sales fellow, her fellow salesperson.
What I figured out was the person who started the organization hired this woman
and said, hired a different woman and said, replicate my access for this new person.

(49:20):
And then this new person went and built out over five years,
this incredible staff of superhuman salespeople now at 152 people.
And every single time somebody came on, she'd call the help desk and say,
replicate my level of access.
Well, what ended up happening was all of them had read, write,

(49:41):
delete permissions, change commission checks. And nobody ever stopped to say,
wait a minute, let's create a role that says this is salesperson access.
I don't care if your name is Paul or Susie or Bobby or whatever your name is, right?
But you're going to get this standard level of access for these systems.

(50:03):
Anything on top of that, I need an approval, right?
I need a boss's approval. And so that is what's inside very many of those regulations
and frameworks that say, if you have elevated privileges, you can show me that approval.
And when you issue permissions based on least privilege permissions to start

(50:24):
with, that means only that baseline level of access exists, physical,
logical, and then from there you have an approval, right? Right.
And I do work with some, and this is a company I'm going to call out, UATest.
They do a really great IAM product, very easy to stand up.
I've heard really great things about it from clients I've referred.

(50:46):
Like I said, I'm too agnostic, but I'm going to give that group a big shout out for their product.
That's awesome. Yeah. And that's really one of the things that.
It's very easy to get caught out. And I've seen that similar situation where,
you know, or somebody just changes roles within the organization and they forget

(51:06):
to remove previous rights from their account while adding new ones.
And sometimes it's even because they're like, well, there's like a three-week transition.
So we still need access to the secure repository and the new side.
And we know that at the end of this three weeks, and even while they're in that,
at a business layer, they have built their own Chinese wall mentally to keep

(51:29):
church and state separated.
But then, you know, the turnover date begins.
There's no second accounts. It was just like, oh, we'll remember to remove it when we're done.
We don't. Right, right, right. So, and that, I think I'm going to close with
data, data classification.

(51:50):
Some people call it data categorization, science that we have completely forgotten
about because it's a lot cheaper to store data now than it was way back when I started IT.
We had a one gig server that actually was the equivalent of 12 refrigerators, right?

(52:10):
In a refrigerator data center, it was very cold in there.
And we would have to decide, do you want to keep employee data,
client data, financial data, all important,
but your data classification really needs to specify who has access to what level of data,
how long are you retaining that data, because we are not enforcing data minimization

(52:35):
or data purposefulness right now, and the data hoarding is just becoming obscene, right?
My dad passed 11 years ago, and five years before he passed,
he went to see a medical center close to my house, and I remember the day he
came home, he started getting sick, he wasn't feeling well, but he was so angry
at the doctor. He's like, that idiot doesn't know anything.
Just a few weeks ago, I received a notice addressed to my dad.

(52:59):
Saying, we've lost your data from that data center. It's been 16 years.
Why do you still have my dad's data? And why are you losing it?
So data retention, data destruction, data minimization, data purposefulness.
Even for incident management, you have 10 servers that are down.

(53:21):
Which one has the golden egg?
Which one do I want to recover first? What's the most important one, right?
And then DR, obviously your DRBCP exercises, right?
You want to recover the most important, the most important data first.
And we kind of forget about these things, but these are really,
we have to kind of pivot our policies and processes back to where is the data?

(53:45):
And it's going to make us ask those questions about, does the vendor have it, right?
Are they backing it up? Where are they backing it up to? That's really our most
important asset right now.
Of course, secondary only to the folks that
are running these shops yeah and you even
even this interesting thing of like reporting
a lot of people sort of there's a

(54:08):
real sort of broad misunderstanding around stuff like even
HIPAA where we just believe like oh it's obviously like we'll
find out if there's a problem it's like well it's actually self-report
there there are certain things to like oh
wow so there there may not necessarily be as
many we call it like on the outside a
lay person would say controls but it's not really control the control is there

(54:30):
to prepare for it but the reporting is not about the control it's the different
it's the compliance side so we think oh yeah well they know they have to protect
certain stuff then we're good not realizing that under that particular regulatory framework,
that it is entirely self-report responsible.

(54:50):
And they're likely, most companies do that, but it's like sometimes they don't even know.
And that really sort of hits home this whole problem of the confusion between
what are human, repeated business practices, that we've got so much technology that's there now.
Now, like when, when I was at this at the start of my career and,

(55:14):
you know, you and I came through it about the same time, it was like,
we really had to think deeply about what do we do with each thing?
How do we keep track of it? And then now it was like, where do we even keep
the, the documents for our disaster recovery?
And we'd have to put them on a hard drive and put them in a locker in a remote
location. It's like, well, now we can put them in 17 different locations in

(55:37):
the world in AWS or Azure in a second.
That's great. Or is it? Like, is that introducing a new set of risk and compliance
stuff that we should be concerned about?
But the excuse to say that we don't know why we do it and we just do it the
way we used to is an excuse that I don't believe is allowed to be used anymore. more. Yes. Yes.

(56:01):
And speaking of HIPAA, I just put into the chat, the HHS has actually made available
to us active investigations going back to the last two years on breaches that
are over 500 individuals.
And it's a very alarming read. And I encourage everyone,
like even if you're in HR and you're selecting a vendor, make yourself available

(56:22):
to go through that and just to find any companies of interest that you may be
wanting to do work with if you're in the HIPAA space.
There's a, I want to be on Santa's list, not that list. Wow.
So in that, right? So Karina, you mentioned 14,000.

(56:42):
There's a reason that number's important. And we chatted when we first met about
this and I was astounded.
I spent the next two hours digging through trying to
find out who creates this stuff we've got
the the framework you know this
idea of this unified compliance was like really neat but i'm like as neat as

(57:04):
it was it was horrifying at the same time thinking like what's the responsibility
and risk we're creating by strapping this on a person and saying you know here's
your google sheet template good luck and And may your deity go with you. Let me know how it goes.
Right. And like you said, because one thing could be applicable to five frameworks.

(57:24):
And then one thing could be only applicable to one framework and only applicable
to a geographic region and only applicable to a particular business vertical.
And only it's literally it's cryptography to me, how anybody could keep track of it.
And they and they and they shouldn't. Right. They need to take that in.
They need to take that output. But the one thing to really, really keep in mind

(57:48):
is we are creating an obscene amount of unnecessary busy work.
It's, I mean, when you look at those sheets that are 12, 14,000 rows and they
are listing common controls, and I'm using air quotes, you know,
because there's many companies that do this.

(58:08):
But they're going, that pendulum is swinging the other extreme direction opposed to none at all.
Then you have all of these, but now you need to really find that center balance.
And that center balance is really what only applies to you.
And you use them, use that output as, as, as a, as a check as,

(58:33):
you know, let me level set myself, make sure I don't want to forget anything.
It's, So I'm writing my own policies, right?
But outside of that.
Don't spin wheels and humans and hours on, you know, just as a really quick closing.
So an old boss of mine actually sat down to do this exercise very recently.

(58:56):
We estimated that over the course of an annual year, we spent about 200,000
hours on compliance efforts.
So this is the whole thing. This is, we're looking for, we're looking at influence
documents, those regulations and frameworks. We're updating our documents.
We're working with the groups for the evidence. We're making sure that the groups

(59:19):
know what they're doing. We're doing risk management. We're gathering evidence.
We're in front of the auditors. We're coaching people to be in front of auditors.
We're making sure the auditors have what they need and they're staying on scope.
We have continual improvement. We have vendor management. We have risk management.
So when you add up all of those things, 200,000 hours really isn't that much

(59:39):
for the big company that we were, right?
Now let's pretend that we're going to take fully loaded $60 an hour.
So $60 an hour, this is your bennies, your PTO, your hourly rate,
your rent, your insurances, $60 an hour. Actually, I think that's a little low,
but we wanted to kind of stay safe in the safe zone. You have a realistic number.

(01:00:01):
This totaled over a $12 million spend for the company annually,
but that was off of 14,000 controls.
When we appropriated those controls, we were actually down to about 4,000.
We saved over $7 million in unnecessary busy work.

(01:00:24):
Just from getting rid of those common controls provided by one of those spreadsheet
outputters that don't even really apply to us or were embedded in some other
documents that actually were applicable to the company.
It would be the effect of having 10% of your workforce in the office every day,

(01:00:47):
but doing a roll call on 100% of the staff.
Like it's, it's bizarre that that's how we treat it.
And the worst part is you're missing the big fat gaping hole that is really
unique to your company because you're so busy following this checklist that
you haven't even addressed the real compliance concern and the real security risks that you may have,

(01:01:12):
which is many times vendor management,
which is very many times track really tracing that data and where's it going. Yeah.
Well, and I know I, I, I'd realized there's a separate, there's so many things
we could talk about Karina, you, you, but I want to stop for a second before
we finish up because what are you doing?

(01:01:32):
And, and this is like, you came to me because I, you've got such a broad sense
of, set of knowledge and you're solving incredible problems for your clients.
So I want to make sure that you get a do shout out in, in what you are doing
through your work and where can folks find you?
Definitely an interesting topic that would likely take us another 20 minutes
into a path would be, you talked about like the lack of data minimization and

(01:01:56):
AI, and I'll say, just put it as a something in people's ear,
go back, go for all that we've talked about.
When we talk about data retention and why, perhaps, you know,
with, you know, with your dad as an example, I'm sorry for your loss that,
you know, to, they may be probably told by somebody,
Hey, we need to hang on to all of our data so that we can eventually do data analysis on it.

(01:02:19):
Not necessarily realizing the impact at a regulatory level or just in general,
like how are we notifying people that, Hey, we're retaining your data for an intense amount of time.
And here's why. So we are going to see a real broad shift in an understanding
or a misunderstanding of what the requirements are.
So I think you and I will be talking in a few months on the wrong side of a

(01:02:43):
bunch of notices and news articles about the impact of AI.
And when we talk about third party, third party responsibility,
people go to open AI, you know, I don't mean to call it, you know,
a generic AI, you know, place that has something called chat to EPT.
And they fire their data up there, thinking, oh, I'm going to do data analysis

(01:03:04):
on this client spreadsheet.
Like you literally just put client data into a vector database,
which is really, really difficult to get back out.
So I'm going to touch on this, because I think it It almost deserves its own
separate podcast, right? So-
Governance. I'm going to come back to governance. And simply,

(01:03:24):
when you look at, let's say, a QMS system, right, a quality management system,
in order for it to be validated, you have to have IQ, OQ, PQ,
incidence qualification, operational qualification, performance qualification.
Once you have those three things, you can call a system validated.
That's part of a QMS quality management system, which is based on ISO 9001 principles.

(01:03:47):
And so it's much more complex than in this, but I'm going to minimize it and
say, there's an input, you do something with it, and there's an output.
And now we have to control the input, we have to control repetitively what we're
doing with it, so that we can know what the output's going to be,
but we know what's coming, right?

(01:04:07):
So ISO has come out with 42001 back on December 9.
And we're seeing this in the EUAIA, EU AI Act as well, that basically says you
kind of need to have a QMS system.
You need to have a validated, qualified QMS system to manage your AI data.
You need to know what's coming in, what it's doing, what its purpose is,

(01:04:30):
how it's crunching those numbers or that data, and what is the purpose outward.
So when we're looking at EU AIA and we're looking at ISO 42001,
these are basically standards and principles now.
So EU is going to become a law, right? It's already a law, but it's going to
become actually enforceable soon.

(01:04:52):
And ISO 42001 is a framework.
So we've got the same influence, regulation and a framework, right?
And basically the consensus is you have to make sure that you're putting the
right governance parameters around how you're consuming and using this data
and what the purpose of this data is.
Now, there are endless numbers of companies who are using our data completely

(01:05:17):
unbeknownst to us, right?
And I can go on and on and on about this. I'm actually having a battle with
two companies right now who I'm demanding that they remove my data,
but they don't know how to do that.
You know, the whole anonymization and pseudonymization is just kind of this
concept of, you know, we want to keep the row, but we're going to,
instead of calling it the Karina Clever, we're going to call it user one,

(01:05:39):
two, three, right? So when you go through.
The fact that most companies don't know how to solve for those gaping holes.
Now, that is a big, huge risk for me, right? Might not be on a checklist.
14 even might not be on any of those 14,000 items that you get,

(01:05:59):
right? There may be 16,000 by next year.
Right, exactly. So I think that we all have to look, I'm all for efficiency
and I think technology is a business enabler.
And if it's not enabling business, then check it out the window and go find
a technology that does enable your business.
And I want it. I want all technology to enable business and optimize our services.

(01:06:23):
But when we are a starting to use it as a crutch, be blindfully following when we really should be.
You know, 20 years ago when the Internet came out or it's now it's been a little bit more.
And we all used to say everything on the Internet is true. True.
And very shortly thereafter, we realized that that was total bullshit.

(01:06:43):
Well, now we're taking AI and we're saying the exact same thing.
It's now multiplied by times infinity or depending on your AI without that governance in place, right?
So if you're going to use AI and you're going to be a crutch for it,
you want to make sure that it is being used appropriately for your purpose.
There are people losing their jobs because look, AI wants to produce an answer

(01:07:08):
for you, based on your question.
It's going to come up with something, even if it's fake.
And it doesn't know that it doesn't know the answer. It knows that we'll come
up with the most authoritative answer.
And even more so, it is like a child that brings you a half-dead frog.
It is incredibly proud of the terrifying thing it just brought you.

(01:07:28):
And it calls it a squirrel, you know?
That is the tough part that people are really about to have to understand.
And I hope that people are moving down. The hard part is I find that we really
get stuck, often even the GRC discussions.
We don't get to the prescriptive, how do we actually deal with this stuff?

(01:07:51):
We get very much stuck on the, whoa, it could be this, it could be that.
And what do we do here? Well, that depends. And they're tough to really get specific on.
But we do have to have real discussions about true tactical things that we need

(01:08:12):
to have in place and examples, I think.
I think because if I go to another conference and there's a panel on the ethics
of AI, I would bet I could just replay one from three years ago and it's the same conversation.
And there are great folks that are up there.
Sure. But what more can you say? They don't want to get specific because it's

(01:08:32):
really hard unless you have the top level.
But you can't go from the broad level to the specifics in the same discussion.
And so we don't ever get to the discussion that I think we need to have,
which is why I think people that are looking at this need to look.
Look, I'll say there's 14,001 reasons why people need to contact you, Karina.
One, because you're fantastic and you're an absolute pleasure to chat with and

(01:08:56):
you're, you really, I don't think I could stump you on a thing about what I asked you.
You've not only understand what it is that we're talking about,
but you come back with specifics, references and proof in how you discuss it.
So this is certainly no, Karina's no fly-by-night operation on how you approach this.

(01:09:16):
And, of course, there's 14,000 bloody lines in a spreadsheet in this unified
compliance framework that make me just...
Cringe inside of even just the controls on that on a spreadsheet to think that
people are going to believe that they are on the right side of all of the things
if they just kind of do that so.

(01:09:39):
What i really think people can can really do to to get closer to you know being
on the right side of good practices with GRC and how do we get a hold of Karina Clever in our lives?
So Karina's either info at clevercompliance.com. We've got folks managing that mailbox.

(01:10:01):
My email is Karina at clevercompliance.com. I really, really want to thank you
so much for having me on and for giving me the bandwidth and kind of the voice.
I think more people need to hear it and stop bringing that entire grocery store
home to have a simple, you know, 12 ingredient recipe for dinner.
And I think they can be very successful with GRC just using some basic common

(01:10:27):
principles that are available to us all and not overcomplicating their lives
and themselves and their companies.
And so I really, like I said,
appreciate the time here and I
look forward to potentially another one yeah for
sure i definitely do want to want to think about as we get
there will be a lot going on the next one there already has

(01:10:49):
been but i i would love to sort of weather the
storm a little bit and see how it goes and that'll also give us a chance later
in the year karina to catch up all right do you go to any conferences events
are there things where i will be i'll be at black hat for sure probably not
defcon due to some family stuff but black hat for sure So I would love to connect with anyone there.

(01:11:11):
I'm on LinkedIn and folks can actually create meeting on my scheduler that's available on LinkedIn.
It is a one-click closer to goodness. I've been lucky enough to spend time with
you. Thank you, Karina, for sharing your knowledge.
And yeah, so it is definitely, I'll have the links to your website,

(01:11:32):
of course, and Karina Clever, more than just a cute and appropriate name,
you're clever beyond means.
But it is Karina with a K, clever with a K.
And it was really great to chat today. and I'm looking forward to hearing back more.
And I only wish I was going to Black Hat number one because really it's a wild

(01:11:52):
and an adventurous event.
I love the folks there, but it would be great. But hopefully over the course
of the next while, we will find ourselves in person somewhere.
I'd love to share time. Definitely, definitely.
Maybe even RSA next year. I was there at RSA this year, but I just really hope
that this helps a few people navigate some of these really dark woods that may

(01:12:15):
be bigger monsters in their head than they really are in reality.
That's it. And I think these are the conversations that need to be listened
to so for people to be like, okay, I understand more and I'm not afraid to make that call.
So it was awesome. Karina, well, thank you very much. Thank you so much.
Have a great week. We'll talk to you later.
Music.