GRC Is Broken... And Nobody Wants to Admit It ft Dylan O’Dell, AVP Information Risk Officer @ Manulife

In this episode of Security & GRC Decoded, Raj Krishnamurthy sits down with Dylan O’Dell, AVP Information Risk Officer at Manulife, to challenge one of the biggest assumptions in the industry: that GRC is working as intended. Dylan argues that most organizations are stuck in control-centric thinking and missing the true purpose of risk management — translating data into business decisions.

Drawing from his background in Lean Six Sigma and large-scale enterprise risk, Dylan breaks down why GRC needs to evolve beyond audits and control testing into automation, orchestration, and storytelling. This conversation explores how modern GRC teams can reduce operational friction, quantify real risk, and actually influence business outcomes.

Key Takeaways:

• GRC today is overly focused on control testing rather than true risk management and decision-making.
• Automation should eliminate manual audit friction — not just make existing processes faster.
• The future GRC professional must combine technical awareness with storytelling, influence, and business understanding.
• Risk management should be rooted in probability and financial impact — not pass/fail compliance.
• GRC teams can unlock funding and influence by tying their work directly to revenue, cost savings, and business outcomes.

What You’ll Learn:

• Why the “three lines of defense” model often breaks down in practice.
• How to translate technical data into meaningful business risk narratives.
• What modern GRC automation should actually look like (beyond tools).
• How to position GRC as a revenue enabler — not just a cost center.
• Why “start with why” is critical for influencing stakeholders and reducing friction.

This podcast is brought to you by ComplianceCow — the smarter way to manage compliance. Automate evidence collection, eliminate screenshots, and scale your program with confidence. 

Learn more: https://www.compliancecow.com

Watch more episodes: https://www.compliancecow.com/podcast

Connect With Our Guest:
Dylan O’Dell | AVP Information Risk Officer | Manulife
Connect on LinkedIn: https://www.linkedin.com/in/dylan-odell-72a06412b/

Rate, review, and share if you enjoyed the show!

Subscribe to Security & GRC Decoded wherever you get your podcasts:

Spotify: https://open.spotify.com/show/5pigcMwOrYIA6d9OOOsxqr?si=416b82ab5c474683

Apple Podcasts: https://podcasts.apple.com/us/podcast/security-grc-decoded/id1795144450

Transcript

Raj Krishnamurthy (00:00.75)
Hey, hey, hey, welcome to another episode of Security and GRC Decoded. I'm your favorite host, Rajkrishnamurthy. Today I have, I'm trying to describe how to, I mean, I'm thinking how to describe you. He's a force to reckon with. And we have Dylan O'Dell joining us today. Dylan has 15 plus years of managing cybersecurity risks. He has built risk programs. He has worked for small companies, big companies, large companies. Dylan, to the show.

Dylan (00:30.833)
Thank you, Raj. Absolute pleasure to be here and thanks for having me.

Raj Krishnamurthy (00:35.276)
I want to jump straight into maybe a few things that you said when we met last time briefly, Dylan. Why do you think the three lines of defense model is broken?

Dylan (00:45.699)
Yeah, this is the best question to lead with and it's a hot take, right? It's fragmented, it's broken, and it's actually disrupting the entire GRC workflow. So this is why most organizations struggle to apply automation and orchestration in GRC. We misdirect our teams, we duplicate the accountabilities of teams defined by a three lines of defense model. And in sequence, we fail to deliver on the dynamic workflow that GRC attempts to represent.

We can break this apart if you'd like. Most institutions are static in their GRC workflow. Line one does line two and three duties. Line two is misunderstood and does line one work. Line three does line two work. And this fragmentation limits trust on roles, accountability, ownership, and it misleads and adds significant inefficiencies. So what I mean by that is you could have your line one team doing audit and assurance work.

You could have your line two team doing compliance work in partnership with line three and line one. And it really just causes this disruption and ambiguity as to what the core goal is, which is the business goals, right? And the risks to the business goals. So there's a lot there to take it, but the bigger slice is the GRC workflow is broken.

and that's misdirecting the three lines of defense.

Raj Krishnamurthy (02:14.816)
Is this because the three lines of defense is, I'm just trying to parse through what you're saying, right? Is it because it is outdated and you're proposing a new model or is it because it is misunderstood?

Dylan (02:27.224)
I don't think the model is outdated actually. It's a great question. think it, you know, what you're really seeing is so much complexity and companies throwing people at problems trying to solve this paradigm or these archetypes that come with risk management. And the regulators or the industry has made it very clear. Line one, you own the risk. You should be doing the risk assessments. Line two,

Challenge and oversight independently line three audit and assurance including control design and operating effectiveness testing Now there's a partnership when they all work through, you know collectively and they cross-pollinate But you can't have everyone trying to do everything

Raj Krishnamurthy (02:57.9)
Mmm. Mmm.

Raj Krishnamurthy (03:17.194)
Okay and so how do you propose we solve this problem?

Dylan (03:23.108)
I think you simplify it. think, you know, when you talk about system thinking or design thinking, right, which is the premise of engineering at its foundation, right, you got to understand that the complex problems that we're talking about of how interconnected parts influence each other rather than just looking at them as fragments in isolation. So this mindset or the set of tools for seeing the whole

relationship, the patterns, the feedback loops to find deeper. I organizations need to do a little exploratory notion of what they've created in the last half decade or decade since the regulator pressures have significantly increased, right?

Raj Krishnamurthy (04:10.422)
No, I think that makes sense. And I think you broke down the three lines of defense beautifully. And I think maybe where I'm trying to understand this question is that if you were to go to an organization, right, and you were looking at this and there is, like you rightly said, you know, the boundaries are very unclear. It's very blurry. People don't know who's stepping on each other. But the intent of those segmentations are very clear. And I think you beautifully put it. So what maybe one, two, three steps that you can take?

I think you said, obviously, you think at it from a broad perspective, take a look at it from a systems thinking. But what can we do to figure out if there is a problem? And how do we take one, two, or three immediate steps to go rectify so that this makes sense?

Dylan (04:54.158)
Yeah, no, and this is where I go back to the GRC workflow, right? So if you take the GRC workflow and you think about it of how do you move to a more engineered or dynamic agile workflow, which is what it should be, it's seven steps. Now, when you look at these seven steps, the intention is to say who is accountable for each step.

Line one, line two, or line three, right? So let me pull this apart just in the seven steps. Business goals. You always should be starting with what is your business goal and objective. Now that could be a technology goal and objective like let's not get breached. Let's sustain and maintain the trust of our customers. That could be the goal. The why, the what, how we want to do things the way we do. We often immediately fail on the first stage.

Line one should know their business goals and they should go into the second step, is governance and then the third step, risk management. The fourth controls the fifth compliance, the sixth audit and assurance and the last step being improvement. But each of those steps is missed.

Direct it by which line does it today and I want to unpack them with you because it will it'll apply the answer much more simplistically I think when we talk about failing on that first stage I don't think when I sit in a second line or a third line or a first line that everybody actually understands the business goals or the first line is not there they're taking goals from

directives and expectations set in governance by the second line, they're not actually focused on what the business is trying to achieve, right? So teams need to understand how the security team's goal may be to not get breached and to sustain its trust. That could be the business goal. Or it could be the business goal to improve straight through processing or build an accessible centralized platform for customers, dealers, distributors, advisors, or addressing client inquiries in a timely manner.

Dylan (07:12.878)
The directives and the expectations in the next phase is your second line setting your foundation, your policies, your standards, your policy is code, your infrastructure is code, setting what good looks like to help achieve those goals with risk in mind. Flip that down to the third phase, risk management, where you're actually identifying, analyzing, prioritizing, and mitigating risk. You're not just pulling against the directives and expectations, but it's

It goes to the first line then to say, I know my goal. I know that I built the directives and expectations in the regulatory obligations, but at the end of the day, I have to manage the risk. It's not for the second line to tell me what the risks are in those directives and expectations, right? It's for them to actually set the baseline or the floor and then allow me to build upon that and make sure that the risks associated with the goals of the organization.

Do not materialize. You do that through controls, the fourth step. Fast forward, fast forward compliance. You can do your certification and a test station audits. You can do your audit and assurance, your third line work. And then improvement is your corrective actions and issue management. But we can unpack those through the call. But let me take a pause.

Raj Krishnamurthy (08:30.061)
No, I love what you're saying, but what I want to ask you is that, so when I remember the days in which, for example, I had responsibility for IT SOCs, 404 controls, and these were the early days, right, of Serpent Soxley, and the way that we arrived at our control narratives, if I remember right,

Dylan (08:43.887)
Mm-hmm.

Raj Krishnamurthy (08:54.483)
it was a very expensive exercise. They brought in, I don't want to name who the auditor is, big auditor, huge check. They basically went and spoke with, I was in architecture and engineering, they spoke with people, all sorts of different people to understand what are you trying to do and what are your KRIs, KPIs, what are your goals and what does that mean in terms of risk? And essentially they came back with the risk matrix that translated to a bunch of controls and control narratives and prioritizing which of those controls are key

Dylan (09:00.058)
yeah.

Raj Krishnamurthy (09:24.407)
manage which can be compensated, is not mandatory, so on and so forth. The reason I'm asking that is that's the approach they took, but even as they took, there were so many compromises made, it sounded extremely academic, if you will, right?

Dylan (09:40.814)
Yeah.

Raj Krishnamurthy (09:41.518)
And what was very clear to me, I was not there for a long time, what was very clear to me even for a short period of time that I was there, is that it was almost like a static exercise and nobody had, especially the leadership team had, no appetite to redo this exercise. So the question I am asking is that what you saying makes absolute logical sense to me.

Dylan (09:57.54)
yeah, not after the money.

Raj Krishnamurthy (10:05.675)
But given the past, it looks like it's a very expensive exercise for companies to go through. And that's why nobody does what you're. Is that a wrong take? How do you take this question that I'm asking you? And how do you go solve it?

Dylan (10:20.227)
Yeah, so okay, so let's pull that apart though in Bite Size for the audience. You were in enterprise architecture, so a first line position, you had a consultant firm come in and help say, hey look, this is the IT socks framework, this is what you guys are trying to achieve for IT socks or what you don't want to go wrong, what the risks are. And they gave you a bunch of control process or control objectives or descriptions. This is a great example.

of the GRC workflow being broken because they started with just a theme, IT socks, and they applied more than likely GITCs, right? Against that, they started with controls, general IT controls, right? That normally around your financial reporting mechanisms, user access, yeah, the examples aside. But hear me out, they started with controls.

Raj Krishnamurthy (11:02.261)
GITC is the IT general controls. Yeah.

Dylan (11:16.803)
they didn't go to architecture or the business and get an appreciation for what is the goal of SOX. Even from the industry, right? Coming out of what occurred in the early 2000s, they didn't then ask, well, what directives or expectations does this organization have for financial reporting? What thresholds, what systems are scoped in, scoped out, right? What in

common nature should we start with? Well, the goal of IT SOX is to ensure the integrity of your financial reports, right? At its finest and most simplistic value. Your second line, your governance, your risk management team is there to help put the directive and expectation or the directive controls or the requirements of reference. say they're not even controls yet. They are requirements of reference that then you should be in the first line architect.

into the system's design or if you're an engineer putting as your infrastructure as code your policy as code. The first line should then equally say to this consultant, okay well this is the way we work. These are the risks that we're entertaining. Do a threat risk assessment at that point to understand well we know our directives, we know our goal.

See, you guys didn't start that you started right with controls process, just like go implement all these. But why they didn't start with why they started with what and how and that's the problem with the industry today. We need to start starting with goals, directives and expectations, allowing then line one to say, okay, I get that I get what we're trying to achieve. Here's some of the risks in the way we work the operational risks, the technology risks, the cybersecurity risks. And then what

controls should we do to manage those risks, right? Then your consultant can come in and give some prescriptive, you know, conversation and interviews and then you start to do compliance checks on it, right? And audit and assurance. Like today, you'll just get your annual SOX audit. Audit will come in and tell you, hey, look, here's a bunch of controls. You have this many failures on those systems. They never even talk about the risk to the actual goal, which is the integrity of the financial report. They just go immediate.

Dylan (13:40.483)
Hey, there's a potential, right? So I hope that made sense. But this is what I experience every day with with consultant firms and no shots in the dark to my partners in consulting firms. But this is also why I don't want to lead with you because I don't need another PowerPoint that's filled with here's the controls you should go and adopt, right?

Raj Krishnamurthy (13:45.581)
made sense.

Yeah

Raj Krishnamurthy (14:01.1)
Now, how much time do you expect your first line of defense, if you allow me to use that term, your engineering teams, your security teams, your platform DevOps teams, how much time do you expect them to spend with you to articulate these risks and articulate these business goals?

Dylan (14:08.472)
Mm-hmm.

Dylan (14:21.016)
So I gotta separate your question because I think the time that's spent with me in terms of say I'm in line two, right? So I'm there helping set the directives, the expectations or setting the baseline, the floor of what the appetite is for the organization. That amount of time for them to ensure that they've integrated that into their systems or their assets, I do anticipate that to be five to 10%.

Raj Krishnamurthy (14:27.468)
Mm-hmm.

Dylan (14:51.02)
Right? Because it's a partnership and as the business shifts their goals and their objectives, I may need to shift my directives and expectations to sustain my risk appetite. And maybe we have to play around with the tolerance. The most amount of time I want to ask of my line one partners is actually on the seventh phase of the GRC workflow, which is improvement because that's where you make a risk treatment decision. Right?

There is elements there or equally in this directive expectation. If my line one partner says, Hey, look, I need to stretch that directive or expectation a little bit to innovate and take opportunity risk. Then I want to have that conversation and accept some risk to innovate and move and get a competitive edge in the market. That's the relationship I want to be having. Risk should be there to help make decisions easier.

Right? Not just to critique them on harm, on control and compliance failures. I expect line one to manage their risk on their own time. They're intimate with their systems. They know how they work. They are the expert. You should manage the risk. I've set the baseline to protect, but you're going to see the dynamics. They're going to have to live with the machine. You're going to see the people interacting with it. The machines interacting with it.

That's your risk to manage, right? And that's not an ask of me. That's an expectation of the organization. That is a line one duty in the three lines of defense.

Raj Krishnamurthy (16:26.166)
Got it. Got it. I think that is beautifully laid out. I think maybe what we should also do is that if you're OK, I think the seven stages, we would add this to the maybe hyperlink or a podcast or something so that folks can see what those seven stages are. So thank you. So Dylan, you are talking about GRC as being an enabler, as being an observability function to the first line of defense.

Dylan (16:41.89)
Yeah, absolutely.

Raj Krishnamurthy (16:52.97)
and also acting as a conduit to the third line of defense, meaning the audit, right? And so from what you're basically saying, what I understand from what you're saying is that it's not a static thing. I mean, it is an evolving dynamic process, right? And it is, in some ways, I'm continuous as well through the period of time, whereas you are not stuck with a static audit once a year or just doing some theater work. The question then becomes, how do you, as an enabler,

Dylan (16:57.315)
Yes.

Dylan (17:08.568)
Hmm.

Raj Krishnamurthy (17:22.612)
as an observer, right, for the first-line offense, what do you do to help them get there? Think about, keep risk at the top, make sure that you coach them, right, to provide you this data continuously. How do you make that conversation happen with the first-line

Dylan (17:39.299)
Yeah, I think Raj, when you actually, there's two things that you have to do before you absolutely just go and help them. They or any GRC professional needs to understand why they work the way they do, what systems they utilize or tools they utilize to deliver for the organization. So with those two things, just the why and the what, and eventually you get into the how.

Why do you use Ansible or Terraform? Or why do you containerize certain things? What I'm getting to is understanding why they've made the decisions in their processes first is so important because then you can actually provide the right level of oversight or challenge, right or wrong, but then you can start to say, hey look, there's a more efficient way of doing this possibly.

Raj Krishnamurthy (18:13.93)
Mmm.

Dylan (18:38.636)
there is Ansible or Terraform if you were doing them, you know, statically one by one per a change record, you can deploy at scale, right? So we can become an advisor, if I say, or if I will, knowing our directives and why they are set as expectations, but also understanding the market, the best practice, the way to actually manage that in a continuous fashion. So, you know, the key thing and

you know the whole the hottest topic right like let's automate all the GRC workflow. Let's get away from checklists. Let's get away from static screenshots. I am absolutely on board. It doesn't tell all the story though because as a risk practitioner I still need to convert all of the automated data into a value proposition to the board to the executive team. What story is the data telling me? And so

After you understand your why, your what, how did line one works, it comes back to us, right? The truth is though, you don't want to be giving your board or your executive, hey, 90 days ago, this is what I knew, right? This is what I was told. This is what the risk posture is 90 days ago when I got a screenshot. What you want to be able to do is say, I know that they're continuously monitoring and I've done a loss.

you know, an LDA or a stochastic random probability test against this, and this is the risk in the way they operate. So when we talk about what is risk's end-to-end role in GRC, we're equally working with the line one and the line three, like what you had mentioned in your question, to get to a position that says you've automated now your risk management, your controls,

which align to the directives and expectations. Sure, you still have to do compliance audit certification, attestation related work that, you know, GRC could actually turn into revenue generating exercises. Audit and assurance will still come in and probably do point in time statements. Improvement will still happen through issue management based on observations or opportunities. But where I'm going is none of that actually explains risk.

Dylan (21:05.505)
What I need to do is actually compound or concentrate all the data offline, but I can only do that if I have continuous monitoring and access to the data as a GRC practitioner, right? Meaning I need to see the configuration. I need to see the output of Security Hub. I need to see the logs, the events, the records, the properties to see where Drift had occurred.

And I need to run scenario exercises, scenario analysis to actually draw upon what the actual risk here is, rather than saying, show me that screenshot. So, you know, I've expanded well beyond your question, but where I'm going with this is I think people often think that the GRC workflow just ends after the audit, after the issues or observations are noted, and then people go and improve it and then, hey, next year, let's go and do it again.

And then maybe you implement some metrics, KRIs, KPIs in between the audit season, and you think you know your posture. But again, that's all point in time. It's all static. We need to shift or, you know, it's a radical, it's a revolution of sort. I would say evolution, but it's actually a revolution of our industry, where we're able to start converting this risk story to help make decisions with our executive teams, with our

partners, our engineers, our architects.

Raj Krishnamurthy (22:34.294)
I actually love the way you put it. And let me rephrase, let me summarize what I understood from what you're saying. You're saying you don't think of this as a very static function that ends with an audit. Yes, it can come back to the next year. So there is some level of cyclical to it. But what you're talking about is, how do I collect data all along the way? How do I collect it continuously, especially based on the business goals and the risk thresholds that I've established?

And how do I tell the story of the risk on a continuous basis, not just for the leadership, but also for the operational team so that they can continuously and iteratively improve upon? Is that what I'm hearing?

Dylan (23:13.943)
That's absolutely right. Like, so, you know, the question I always get from it's stables, how do you sell, you know, Dylan, what you're talking about? Like it all sounds great, but how do you actually sell an organization that is very caught in their ways of working? Right. And how do you avoid the paralysis of large organizations who have all these lines of defense, just doing busy work due to the volume of data, people, the process, the pressures from clients, regulators.

Raj Krishnamurthy (23:28.193)
Yep.

Raj Krishnamurthy (23:38.88)
Yep.

Dylan (23:43.768)
people aren't actively diving in and trying to say like, help me understand. Yes, it's a bit of a challenge to the industry, but you're absolutely spot on. It's to help inform collectively in partnership, line one, our operational teams, our delivery teams, our developers, our engineers, to say, you can actually end to end own risk management, but I'm gonna help you tell that story.

Raj Krishnamurthy (24:15.508)
I love what you're saying. Please go ahead.

Dylan (24:16.363)
No, yeah, because I think this is where when you just look at it in its simple nature, again, business schools line one helps understand it when line two understands it with partnership. But then we set directives and expectations. You give it back for risk management, which is first and foremost, line one, start identifying, analyzing, prioritizing and mitigating risks that you are observing. Right. Put controls into mitigate.

Then you get into your compliance imbalance, and then you get into audit and assurance, your third line, you get into improvement. But in that improvement phase, it's not just about issues and corrective actions. It's actually about looking at risk and making decisions to move faster, to scale back if you're beyond the appetite for reasons. It's not just about pass fail of a control. It's actually about converting the narrative to say that

When I look at all the data from governance, from risk management, from controls, from compliance, from audit and assurance, and I start to pull upon loss events, near misses, major incidents, priority one, two events, problems, security incidents. I look at reportable events. You can look at anything from risk assessments that even if they pass the control, you can actually put dollar values and capital.

towards this to actually appreciate like, look, if I run this scenario analysis, there is a high probability we are going to lose money there. And if our insurance or our capital at risk loss threshold does not cover us, we are in and carrying high risk. So what are we gonna do about that? But it starts with just getting the three lines correct and not

having second line try to do what the first line should be doing or first line thinking second line should do it because of the nomenclature that is GRC, right? So you gotta really just like start with that hot take of it's all broken. We only start with controls. Everybody just gets in these, you we spend a lot of time just arguing control effectiveness or descriptions. That is not risk management. So yeah, there's a huge journey in front of us.

Raj Krishnamurthy (26:40.489)
No, and I love the way you're saying it, but one of the challenges that I see, Dylan, is that where people get stuck is the curation of this information from one level to another level. So let me explain what I mean by that. So if you, for example, you're an engineer, you are very focused on engineering org, right? Let's say that you're the VP of engineering.

you are very focused on the next release. You're focused on the next product release, right? And the way you think about risks are, how is my product going to fare? What is the market sort of ramification, right, implications, so on and so forth. If you are in security, you have a very different set of, you know, parameters by which you are measuring, like you were saying. The challenge seems to be that how do you translate the data that you collect from these systems? From MFA.

Dylan (27:16.715)
Yep.

Dylan (27:31.701)
Yeah.

Raj Krishnamurthy (27:33.324)
We will take some very simplistic examples. MFA, the change request that I'm doing in GitHub, GitLab, whatever that is, right? All the way to a point where I can measure risks, benchmark risks, and compare them and improve them. That translation layer seems to be where most people are stuck. So what is your advice? How have we done this in the past? How have we taken this? How do you translate metrics from metrics?

Dylan (27:40.779)
Mm-hmm.

Dylan (27:57.493)
Yeah.

Raj Krishnamurthy (28:01.695)
to risk indicators. How do you do that?

Dylan (28:04.715)
Yeah, well, think in, you know, the products that are available in the market compliance kind of gives some of the opportunity here, right? Let's actually unpack what those teams principle goals are security or evaluation of the product shelf and how it hits the market and the customer impact. You can take things like net promoter scores and actually convert that into new controls, new governance, new directives, right? Maybe we're too tight. Maybe it didn't work. But what I think you're asking is

How do I accomplish risk management and that story without constantly going into the engineers, into the developers and changing the way they do their day, right? Apologies for the kids in the background if you can hear them. But that said, look, when you talk about, today everything's built. I wanna start there. Let's just say that today. I've not had a meeting in the last three years

with any chief technology officer or CIO or chief data officer that has not started with, we have automated this in our way that we've built our operations or we've delivered our pipeline. DevSecOps 30 years ago started building on this, security got integrated 20 years on this. GRC is kind of just compounding and putting a bubble around that.

need to do better at just seeing what the outputs are, Raj, rather than going and saying, hey, I need an hour of your team's time. I'll give you an example from one of my roles. We spent 100,000 hours testing controls across first line, 100,000 hours across an institution, give or take seven to 11 million depending on the complexities.

Think about all the underlying bureaucracy, politics, frustration with descriptions, outputs, effectiveness ratings. Why are we wasting that? That number should be maybe two to 10,000 hours in a first and second line because the system is already talking and telling you what you need to know. But if we just trust it that, you know,

Dylan (30:19.084)
I don't want to use product names, but there are great compliance features on products that allow you to set the direct of expectation or control so that no one can change it. A system control policy in a particular cloud environment, they can't overwrite it. So you know that the risk will be managed and you monitor it for drift or change in the production environment. Getting the alerts.

into GRC rather only to the engineering and operations team. Right? Another example is how do we compile events, incidents, priority one through P4 events, taking all the thousands of tickets, but pulling the risk themes out of that. Picking up root cause analysis for what is recurring, what has high probability of recurrence. That scenario analysis, I don't need to

bother or disrupt my operational team for that information. But I do. I pick up the phone, say, hey, I need an hour of your time. I need a screenshot of all the incidents. I need you to tell me why, you know, in a sample-based model, why this one didn't have that approval on it. All of that can be automated. And those themes are what risk needs to start talking about. then full finish the story, right? Like don't just say, hey, look,

200 of the 10,000 incidents or changes had an approval, didn't have an approval on it. What does that actually mean? Did anything actually go wrong, right? Like we never finished the story in risk. All this automation can help inform, all the data can be automated. The GRCT means to spend way more time with the stakeholders understanding the impact, right? The probability the systems are gonna tell you and just, but having that.

Raj Krishnamurthy (31:52.171)
Yeah.

Dylan (32:11.628)
time to invest with stakeholders to change behaviors, that's where you want to ask people for time. I don't want to have to call someone on their two week sprint and say, by the way, I need an hour for an audit. That sounds absurd to me, but it is the norm. It is the norm.

Raj Krishnamurthy (32:26.514)
No, think that is a very beautiful way to put it. But in your world of what you're describing, are you putting too much expectations on the GRC team? And I'm asking this not as a GRC leader, which you have rightfully to do so, but I'm talking about generally for somebody who's watching this, right, and who's sitting in the GRC team. I am already inundated with what I am doing today.

Dylan (32:47.914)
Yeah, you know.

Raj Krishnamurthy (32:53.532)
And they may not necessarily agree with what they are doing today, but how do they move themselves to the next level of what you're talking about? I would love to say the word finishing the story, right? Because what you're saying is you're making GRC to be storytellers, and how do we, the GRC community, become better storytellers? And what sort of investment do we need to make in ourselves?

Dylan (33:03.723)
Yeah.

Dylan (33:14.42)
Yeah, this is, this is a fundamental, you know, gap in the industry. I'll take the hot take. I'll take all the pressure where, the archetype of the GRC individual is I'll do a risk assessment. I'll do a control test. I'll do a report on a KRI like, or I know this industry framework or this regulatory obligation and you know, I'll test it. Like that's the archetype today. The archetype that we're talking about now is how do you navigate.

Raj Krishnamurthy (33:22.206)
Yeah

Dylan (33:44.584)
a GRC professional to have the soft skills, the empathy, the emotional intelligence, the social influence, and the speaking skills to convert data into meaningful action and outcomes. Yeah, yeah, and yes, absolutely. It's one of, know, call them generalists, not specialists, but they're technically inclined to a broad depth of areas. And it is...

Raj Krishnamurthy (33:58.717)
and technical skills as well.

Dylan (34:12.552)
You're not wrong when you say like am I just hunting unicorns because my team is inundated with doing those risk assessments or Doing those directives and expectations or designing them for the first line but I think this is again where if you Get the three lines of defense and you say you know what? This is my mandate. This is my accountability You start to shift the archetype of the GRC professional

Because challenge and oversight is a social skill. You can't always just go in and say everything's wrong. You're bad at what you're doing. That's ineffective. There's risk there. You have to go into it understanding and starting with why, learning the what, the how, and then outlining and helping educate, hey look, I've done my research. I've studied a little bit more about what the loss events in the industry are.

If we continue, I've run a scenario analysis and this is the output. So there's so much of that technical need and that GRC talent to do those scenario analysis. But you can use, you know, to convert that into a story in business terms, which is money at the end of the, you know, ROI return on value. It is a skillset you have to learn. I, you know, you recommend.

I love your podcast because one of the last questions like what influences you or what inspires you and you know, it's uncommon for you to get a GRC practitioner probably on the phone who says one of the books I'd recommend to the industry has nothing to do with security or GRC. It's the Ride of a Lifetime by Bob Iger, the CEO of Disney. Because you start to appreciate a whole different dynamic of some of the characteristics you want in a GRC professional. Leadership principles.

you know, emphasizing courage, decisiveness, fairness, course traits for decision making, innovation and risk taking, right? Advocating for change and taking calculated risks from data, culture, right? How do you create a collaborative culture for long-term success? Adaptability. So yes, there's an ask of the profession to get more exposure to

Dylan (36:35.081)
this type to the business. But if you go back to how we started, start with the business goals. Do you even understand how your business makes money? Right? Do you understand how they sell your products? What are your critical operations and why? And then start talking about the technology that enables it, right? And then start talking about the directives, the expectations, the risks, the controls. If we

learn and educate GRC professionals to be curious first, start with why and understand the business, we can definitely change the archetype.

Raj Krishnamurthy (37:15.24)
Got it. Let me go with that in two directions. One, let's say that, you know, the world is listening to Dylan and we all build this high-efficiency 100x GRC teams, right? And we on a path towards it. What is the type of conversation you have with your auditors? Because they seem to live in a very different world. You are an ex-auditor yourself as well, if I understand right. So help us understand what would that conversation look like?

Dylan (37:18.804)
Yeah, please.

Dylan (37:35.627)
Yep. Yes, I was.

Raj Krishnamurthy (37:43.708)
as the leader of GRC with your internal and external auditory.

Dylan (37:49.034)
Yeah, and you know, I would actually, I encourage, go to your auditor and ask them at any point in time which direction they're taking their own audit practice. I think you're gonna get a lot more, especially the bigger consultant firms, if you're doing your SOC 2 type 2s or your ISOs, you're gonna start seeing them deploy more automation, more offshore machine to machine. They wanna plug in what they call their ACT scripts.

right, whether it's PowerShell or whether it's Python, whether it's a compliance cow or one of the competing products on the market, like you start to see the auditors start talking in terms of less a line on the schemas, the JSON schemas, the YAML schemas, like let's start understanding that what is being applied and then test it and then allow me to monitor it for a duration.

That's what I think the conversation with the auditor is. I'll let you in in an audit role with read rights. Take five business days, monitor it. Don't just ask me for March 20th of 2025 screen print of the conditional format or configuration. Sit there and monitor how it's working, right? And if you want the logs from March 25th, 2025, I don't know why you would, it's passive.

But hey, let's go and pull it from our audit log, right?

Raj Krishnamurthy (39:17.19)
And Dylan, I don't mean to interrupt, but I've heard this many, times and I cannot name names and these are very credible people that if I give you...

And I heard somebody say this, maybe I'm paraphrasing it, that in the world of audit, ignorance is a bliss. And what they mean by that is as a GRC team, I don't want to provide all this information to the auditor because I become liable. And what you're saying is an exact antithetical to it, right, in complete contrast to it. How do we, what am I saying wrong? Why is this person wrong and why are you right?

Dylan (39:56.607)
Yeah, no, I think it's the right question, but this is where and why audits have objectives and scopes and why they work with the partner or why the first line in the business sets the scope of their external engagements. Set the scope or your statement of applicability. Look, I've never, I've done a thousand ISO audits, right? You get my SOA, you get my controls against the NXA. I'm going to tell you exactly how.

that control is designed and operating. That's the message. So if you're fearful that you're exposing more or don't want to expose more, well then the automation allows that. Like it may be a little bit more work upfront, let's be honest, it would be. But if you're talking about the scope of a particular system,

down to the resource ID or object ID in your cloud environment to a control, you can definitely isolate for an audit role in a lot of platforms today to say this is what you can observe and nothing else. I hear you Raj, like it is absolutely a cultural shift of people thinking, look, until we start looking at audit as partners, less.

Less dare I say it line to where they're challenging the way I do things or trying to tell me I'm doing things wrong They are there to do audit and assurance They're there to especially your internal audit team if you're fortunate enough to have one, right? So your audits are a formal examination of your statements to provide an opinion on the accuracy and compliance of what you said, right? So give them what you said too often. I think this is part of it equally

And I'll close with this on this, like assurance on the independent checks and reviews of various types of information. Again, it's scoped, but why people hesitate or this ignorance is bliss conversation materializes is. Lime one doesn't allocate enough time for audits to come in, right? To prepare for audits. And they immediately go on defense or think of.

Dylan (42:16.671)
Hey auditor, you're just annoying me. I have shit to do, pardon my language, right? I gotta deliver the business goals. But this is where the automation and the orchestration plays dividends. You don't have to bother them. Line three, call line two. We did our oversight of line one and we're seeing it in real time, the monitoring of the controls. We're monitoring the directives and expectations to our appetite. Auditors.

Raj Krishnamurthy (42:20.86)
You

Dylan (42:44.008)
Come in, if you think there's new risk auditors that you want to audit, let's have that conversation. But again, that's more advisory engagement, not something that we scoped, right? So.

Raj Krishnamurthy (42:57.065)
I love it, I love it. And let me ask you a question on a slightly different vector. And I think you've said it so beautifully, which is, but as part of this, you also need investments in skills in people. You have to invest in people in their skills, bring in maybe new perspectives, thought process, maybe even potentially people with statistical analysis skills into the GRC team, automation, but you have to package this and sell this to your leadership team, right?

Dylan (43:25.002)
Mm-hmm.

Raj Krishnamurthy (43:25.265)
as a leader, how do you do that? How do you ask for that investment to say in all these competing priorities, invest with GRC? How do you do that?

Dylan (43:35.134)
Yeah, and you know, if I was out there and somebody was saying, hey, I'm going to need more money to do this, I would actually first start with saying, have you identified the budget you have today and is it utilized the best way? Because majority of GRC budgets are actually healthy, but there's ways to turn this. So, you know, if you're seeking new money,

start to find ways to generate revenue as a GRC function. That could be through, you you support compliance certification and a test station audits and you put a dollar value for every customer that inquires on it. And you've converted that into revenue if you sign the business, right? That's one way. The other way to do it, if you're not going to get more money is to continually show, you know,

And we're talking about not efficiency gained, right? Like we're not talking about efficiency through AI or a platform. We're talking about dollars saved to reinvest into talent, into technology, into process. And so what you're trying to ultimately show there is, hey, executive, we're gonna apply engineering principles and we're going to do this by taking our current

$3 million GRC budget for that business function where we have software licensing, allocate it, and we're gonna redistribute it to this. How do you get there? Well, the automation and that efficiency, and this is an unfavorable take, but you have to look at your resource model, right? You have to look at, do you have more people than what is

required because workforce management or you know where your expenses go today. I think you can be very creative. Respectfully, I'm a big fan of conferences, training and engagement and networking. So it's not something where I'd say like immediately slice money off of that. But a lot of these platforms today are at low cost for the value and return on investment that they'll give an organization reposition, go and pilot the solution with the partner.

Dylan (45:54.004)
who will more than likely do it at no cost to show the value and then bring that back to your executives. I think what I'm hinting at is a lot of the time people always jump to, can't afford it. It's not necessarily an immediate ask for funding. You should be able to come with data and apply. It's gonna save us this in head count, it's gonna save us this in training, it's gonna save my line one team. Better yet, let me just share one thing from my experience.

When I piloted a few solutions, my Lime One liked it so much, they came with the money. They said, you know what, if you're not gonna call me this often about getting screenshots and taking hours out of my developers and engineers day, have the half a million dollars, right? So there's a lot of creative ways to sell it, Raj. mean, it's not the only way and I'm happy to talk with anybody on some of my success and some of my failures, trust me.

Raj Krishnamurthy (46:39.122)
Okay.

Dylan (46:52.397)
There's been a few of those too.

Raj Krishnamurthy (46:52.604)
No, I love it. love it. Maybe in that way, what were some of your starking failures?

Dylan (47:00.583)
Yeah, I think driving or trying to start too fast with blue dollar saved and by blue dollars, I mean like starting with efficiency saying like, Hey, look, we spend a hundred thousand hours testing today. If I automated, can save 80 % of that and you can in turn see seven and a half million dollars saved. have like Dylan, you don't know that, right? Dylan proved to me at least that you're going to minimize the meetings, minimize the

Raj Krishnamurthy (47:21.426)
No, no, no.

Dylan (47:30.471)
you know, time spent with engineers, developers who are moving new features, new products into the market for the business. So, you know, don't jump too fast with excitement. Make sure that you're very aware. I think the best recommendation or the biggest failure on my part was going to the market too fast without understanding. Now this is the fortunate aspect of being in a very large global organization.

A lot of tools exist and a lot of tools today are allow or adding features that are compliance. And with that, allow a GRC team to actually codify their directives, expectations or controls. Now what the market, my recommendation is if you're going to a market, you want the middleware, you want the orchestration. you know, I've gone down the path of having

10 tools all doing their compliance checks, meeting the directives and automating it, but I have to go to 10 tools for all the outputs to tell the story, right? You want that centerpiece that gives you and kind of helps aggregate the compound storyline for you to then pull that out and then go back to your stakeholders with the information. I hope that translates, yeah.

Raj Krishnamurthy (48:49.626)
No, no, 100%. I think that's brilliantly said. What is your current opinion of the state of, and I'm going to use the word GRC, and that is a disservice because you talk in great depth about risk management and storytelling and annualized loss experts, on and so forth, but what is your view of the current state of tools in CR and GE?

Dylan (49:16.741)
Yeah, I swore I swore earlier and if I just said S H I T right now again, it would probably, you know, translate well. Look, I think tools today are quite archaic. I think they had and did a absolute purpose over the last two decades where large and small medium businesses had to put together information to manage risk.

regulators were pushing buttons and saying, you need to be able to do this. You need to tell me. But one of the key elements that they always missed upon was again, making sure that the workflow was done correctly, making sure that the orchestration of the workflow added value, not just telling me how many things failed.

But if you look at the premise of, you know, go back to the early 1900s when risk and insurance, or the 1800s when, why did insurance come up? And it was to basically compensate for risk, right? So I'm not trying to give an insurance lesson here, but our industry was built upon loss expectancies, annual rate of occurrence meets your annual loss expectancy. And that's not a technology algorithm, that's a risk algorithm.

saying cost avoidance is an ROI is not working. Now these platforms don't do that. We've gotten so driven by, I'll just put my risk assessment in the GRC platform, I'll just put my control test in the platform, I'll put my audit in the platform, and we lost sight of what we were trying to achieve. Like what is the probability and impact of loss? And the tools today don't do it anymore, funny enough.

You know, you'd have to go and create a model offline that helps tell this story. And I'll say this, if you look at your other risk divisions, your financial and capital risk teams, they've been doing it the right way. Yeah, forever, right? I'm not sure where, you know, in the 15 years I've worked with, it's just been the norm. So I'm not sure when technology just jumped this path of a

Raj Krishnamurthy (51:14.408)
Totally.

Dylan (51:36.529)
specific GRC or approach to utilizing tools a certain way. But we lost sight of what risk management was meant to do, right? And the tools do that.

Raj Krishnamurthy (51:45.352)
100%. And I think you said it so beautifully because even if you look at, and I think you're hitting something very, very critical on its head because if you were to go out and obviously there are frameworks like FAIR, FARCAM, but if you really look at models that are existing for ALEs, the only reasonable thing that you would come is one from Netflix called Ristiquant that is like five years old that is archaic.

Dylan (52:09.801)
Yeah.

Raj Krishnamurthy (52:11.163)
And the question is that why have people not doubled down? There should have been more such models, not less, right? Especially in the open. so I think that screams for sort of making some of the transformation that you're talking about, right? So absolutely, I 100 % agree. What is, we are almost approaching the end of the segment, Dylan. How do you have some very powerful opinions, powerful perspectives? And I know you work for some...

Dylan (52:17.225)
Yeah

Raj Krishnamurthy (52:39.739)
very interesting companies, right? Canada Life, Manulife, so on and so forth. How, what has informed you of these? How did you create, what made you come up with these perspectives and opinions? What informed you, what created you of these opinions?

Dylan (52:42.408)
Mm-hmm.

Dylan (52:56.89)
Yeah, I think it started maybe a decade ago, less around technology GRC, but I was fortunate enough to take a, it was a security position of all things, but the division did not report into the CISO or the CRO. It actually reported into a senior vice president of what they called business excellence. Really in short, it was a engineering division of the business.

And a lot of businesses don't have this arm that is around process and continuous improvement. But working under that leadership, under that guidance, and the individual leading the team is my number one mentor today, I'll talk about that if willing, you immediately start to apply things like Lean Six Sigma and looking at all the waste and how information informs decisions.

And so that was the core driver for my thinking. God, and then you start to just get into GRC practice and you see all the manual work. And my favorite saying of the year is all this work goes and sits on a shelf or in a GRC platform and it sits on that shelf. No one uses it. No one reviews it. No one looks back on it. That's where the systemic problem started to come.

Raj Krishnamurthy (54:21.062)
Wow.

Dylan (54:23.418)
And I started to work with partners such as yourself or look at the market and start to understand. And, know, I loved what Netflix has been doing, what Docker has been doing, what Adobe has been doing, starting to quantify, you know, are we just lost and we got to really shift how we represent risk. Right. So they inspired me to really double down on this principle of GRC engineering and automation and orchestration.

Raj Krishnamurthy (54:52.379)
That's very powerful perspective. I think what I'm hearing you say is that you are coming at this completely from a different perspective or from your experience, which is the Six Sigma, the total quality management, where you're looking at waste no matter where it is. That can be in any part of the business. And that actually has given you a perspective and anchor on how to look at cybersecurity as well. And I think that's a very, very interesting way into how you can look at risk and how you look at sort of...

Dylan (55:00.893)
Yeah.

Raj Krishnamurthy (55:22.184)
particularly risk but governance and compliance as well, right?

Dylan (55:25.062)
Yeah. And think about your career as an enterprise architect. Part of your goal is to improve the flow, right? To design the flow so that there's consistency, there's reliability, there's adequacy, it's reasonable, and it's effective, right? Effective can mean many things, but to reduce variation and defects in the design, like that's where my mind comes from. And it's just with gratitude to see the industry

start to really buy into this thinking, to see products start to say, I will orchestrate and automate the thousands, the millions of critical items in your environment and tell you where there might be perceived ineffective controls. So you can spend more time with your business saying there's a risk to this goal. Here's what it is. Here's what may occur.

Raj Krishnamurthy (56:10.116)
Absolutely.

Raj Krishnamurthy (56:18.937)
And I am hoping, Dylan, that you start a movement for Six Sigma for cybersecurity. I'm hoping that this kicks off, this officially kicks off. I love what you're saying, brilliantly said. Where should GRC sit?

Dylan (56:36.518)
Yeah, this is a hot take. So a lot of GRC functions, you'll find them under a line one security leadership, like a CISO, or a second line under your chief risk officer. My opinion, the second line will always have that risk officer role, and that is appropriate. When it comes to the first line, so the team members that are actively doing the risk management, the controls.

I really think that they should be a product of the strategy and operations arm. Most chief operational officers are focused on operational levers, which cause waste. And how do I do continuous improvement? Security leading it does not, it doesn't by default ignore risk, but it may layer security on top of risk.

which in reality, when you think about the topic of technology risk, information cybersecurity is a part of the taxonomy that falls under technology risk, which falls under operational risk. And so it's a product where I think we need to slowly but surely move out of the security office, let the security office manage security. And like the operations team, like the delivery teams, like the product project teams.

all feed risk, right? It's a unique blend in these big companies. Like I cover risk for operations, I cover it for projects, delivery, development, security, but I report into one of the fifth, right? And so, you know, it doubled downs on what value back if it's gonna get translated into security and you ignore this entire arm.

So you want to get away with that. And an operational officer normally is looking at the big picture, the strategic picture, the business goals.

Raj Krishnamurthy (58:32.598)
But the counter argument that I've heard to that is that GRC in many ways has suffered because it has been extremely abstract and non-technical. And by non-technical, I don't mean that we have to all be engineers, Right, go on Python and Rust program. But what they mean by that is that, you know, being closer to where the process actually happens, right? And...

Dylan (58:47.527)
Mm-hmm.

Raj Krishnamurthy (58:56.068)
And that is one of the reasons what the arguments that I've heard why GRC should be part of the security office because they can be closer, they can be deeper. How do you balance that?

Dylan (59:04.591)
Yeah. No, I like that. I think, look, pull it, pull it back in again. You know, it's good to be close to your security engineers, but what guidance or partnership are you bringing? Say you're not technical. Say you don't know how to write a or build a web app or a Python script or a JSON YAML format. They do. So for them, it's about understanding what they need to translate. You

can always pick the phone up and give them, you know, the appropriate level of guidance and then ask for visibility and that the relationship matures to help me get the automated alerts if you drift beyond what we just aligned on, right? So it's not to say like the technology today just allows for relationships at a distance. And it's not

that I need to be directly with security. Because if you took that paradigm, you're further away possibly from development or you're further away from operations. And that's a gap too, right? So, you know, you see risk divisions in reporting to technology officers, data officers, or information officers, CISOs, but you want to be able to talk about risk the way an organization looks at risk, right?

What opportunities is risk giving us to innovate and move faster? While what risks have we observed that might impact us from a harm level, a compliance level or like regulator or a control failure level, right? Like we often just focus on the harm compliance and we go right into security breach. Like there's so much more to risk than it, not to understate the value of a breach, but there's so much more, right?

Raj Krishnamurthy (01:00:52.23)
Ha ha ha ha ha.

Raj Krishnamurthy (01:00:58.982)
Maybe I'll keep this as the last question. And for a person who is coming into GRC, risk or compliance rate or governance, particularly in the world of cybersecurity, what advice would you give them? How can they pick themselves up? What can they learn? Who do they associate with? How do they become Dylan over the next few years?

Dylan (01:01:04.945)
Sure.

Dylan (01:01:19.716)
Yeah.

Dylan (01:01:26.863)
Yeah, so there's two things I'll say. First and foremost, the notion of what they'll learn in school or in majority of professionals today, they'll immediately jump to the what and how your line one works, right? To put that challenge or to audit and put assurance. Stop doing that. Start with why. You may be familiar with that famous Simon Sinek book, Start with Why, right? Like far too often.

Raj Krishnamurthy (01:01:51.002)
Simon's in it.

Dylan (01:01:52.067)
Yeah, like we just don't start with why we don't even understand and we immediately put our partners, our stakeholders on defense. But rather if you ask why first and then help coach the what and how towards the risk appetite and the thresholds, you become a much more collaborative partner. Now the second piece, do your research in GRC. You will not be the line one smear the specialist, but do the right thing. Use AI.

Use search engine optimization. Do research on topics you are entering in advance. Like obsess over the customer value. Customer being both the business customers but also your stakeholder. Understand how your business makes money, sets goals and understands the behavior of the company. Get involved in how things are designed and execute it. It will only add value to when you actually do need to tell someone you're

like the challenge or you fail to control and this is the risk because if you don't understand all that in advance you're going to really lead yourself into a argument with a lot of friction you're going to burn your reputation so start with why and do your research and you will be well on your way

Raj Krishnamurthy (01:03:10.95)
become the next Dylan.

Dylan (01:03:13.211)
to become, well, I'll say that lightly. There's many people smarter than me out there, but I definitely have a passion for what I expect of my own team members and the attitude, right? Like I think I've heard it many times, the archetype of GRC really needs to shift and it won't shift if we continue to lead with what and how, but it will if we start with why and start with doing our research and partnering.

Raj Krishnamurthy (01:03:14.342)
I appreciate it Alan, that is great advice.

Dylan (01:03:41.529)
Nothing's going to stop someone from prompting in their AI, how does Ansible work? How does Terraform work?

Raj Krishnamurthy (01:03:41.958)
100%.

Raj Krishnamurthy (01:03:46.8)
Totally. 100%, beautifully said. And so Dylan, I want to give you the last 60 seconds and I want you to do any shout outs, your mentors, books you read, podcasts you watch, anything that you want to do a shout out, this is your last 60 seconds.

Dylan (01:04:03.919)
Yeah, thank you. Let's go with the one that we talked about, the unorthodox mentor who kind of got my mind thinking this way. Michael Bansal, I'll name him. He practiced industrial engineering and got himself into business excellence, right? Where he is constantly, he's a lean Six Sigma black belt, but he taught me how to lead complex process improvement projects and drive organizational excellence that then I've applied into my world.

He taught me lean principles. He taught me how to reduce variation and defects to achieve measurable business results. So huge shout out to Mike if he ever hears this. But that said, there's plenty of partners who helped guide me and help me learn from this. But truly from a book perspective, the ride of a lifetime, as I said, by Eiger, there's key snippets like unlimited investments.

one of the best books for just understanding this and a bit of the business there too, cause it starts well. but yeah, I think it, you know, cut it short that way. That's right. Yeah, yeah, absolutely. And you know, they even give tremendous source material, reference material on this automation, this orchestration architecture workflows. So, you know, you can only learn and it is a fast and easy read.

Raj Krishnamurthy (01:05:06.448)
The Unlimited Investments is the book from Phoenix, right?

Dylan (01:05:27.887)
And you've just, it starts with the business. That's what I love about it. How we started this, the GRC workflow. It is the CEO getting a message about a problem that came from governance. And then they start the governance team. The second line works with the first line to do risk and control management and audits there to then do the assurance. It actually stipulates everything we just talked about. I didn't even realize until right now.

Raj Krishnamurthy (01:05:54.24)
Dylan, this was fantastic having you on the show. I started this saying that you are a force to be reckoned with and I think I'm truly ending that with that statement. This has been great hearing your perspectives and best wishes.

Dylan (01:06:08.561)
Thank you so much, Roz. Happy New Year and absolutely to you too. Bye.

Raj Krishnamurthy (01:06:11.642)
Thank you. Take care.