
Loading summary
A
We love controls. We're excited to build a partner with our clients. We have a great understanding of all the major ERPs out there and we really kind of see that blend of technical skills, compliance skills, audit skills, and then really business process skills coming together to be able to really understand what are the true impacts to an environment from a controls perspective.
B
Hey everybody, real quick, if you're going to be at GAM next week, go check out booth 111. That's where the Clear Salting folks are going to be. So Mark, who's our guest today, is going to be there. Courtney, who was our guest last year and was at game last year is not going to be there, but she has a pretty good excuse and that she had a baby recently. So congrats to Courtney. But then just the other folks that we've met and talking to Clear Salting over the years, the CEO Mark D.C. who runs North America, Samantha, the other Courtney have all been fantastic and I highly recommend go and check them out. We're also going to put a link in the show Notes to their quarterly newsletter. Sign up for that. Quarterly is pretty easy. You know, I know we send stuff once a week and even sometimes I'm like, nobody's going to read this, it's too much. Quarterly is pretty easy though. So do that. Connect with them on LinkedIn as well as their YouTube channel. All three of those links, the newsletter, LinkedIn and YouTube are all in the show notes. And if at this point you're like, what is a Clear Salting? So Clear Salting is a digital finance consulting firm. They're known for implementing, optimizing and managing best in class financial software solutions. But that's not, not all that they do. They're also true advisors and believe in figuring out exactly what organizations need to thrive and grow. They build transformative relationships among the organizations. I can attest to that. They serve and free up time to focus on what matters. Uncovering new insights that drive businesses forward and their risk advisory practice. They believe in evolving risk management solutions. They're a trusted partner across the three lines of defense, supporting internal audit, co source and outsource, controls integration and control execution support. Again, if you're going to be at gaming, go by booth 111, check mark out, hang out with the rest of the group. Hello everybody. Welcome to another episode of the Audit Podcast. I'm your host Trent Russell and today on the show we have Mark Walrod. Mark is the controls integration leader at Clear Salting. Prior to that he spent 21 years at PwC closing out his career there as the Trust Solutions Managing director. A lot of this episode is about controls integration, which I think is probably near and dear to most of our hearts. And so a few things that we hit on is when to start talking or having those conversations around controls integration for think like major transformations in your organization. So if it's like moving from one ERP to another, that's huge. Rolling out AI across the organization, huge. And it doesn't always have to be a huge transformation in that sense, but a transformation nonetheless. And when controls should be discussed and what Mark refers to as phase zero. And a couple of things. One of my maybe favorite parts of the episode was when we talk about what is phase zero and how to keep an eye out for that so that, you know, we're months or years into this transformation and then somebody goes, we should probably bring in like the controls people to talk about putting controls in. And so it's almost like these warning flags of like, hey, things that we can keep an eye out on so that we know when phase zero is approaching to make sure that the controls integration piece is involved. So we don't implement some huge ERP and then go live and then go, oh yeah, we should probably put some controls in there, shouldn't we? All right, so again, largely controls integration topic that we're hitting on, we also go through some, maybe some myths as a way to put it, assumptions that management makes around controls. So as an example, and I speak to when this happened to me or I first recognized it, but I assumed when I first started out in audit that if you bought some huge ERP that at least some sod controls relative to access were kind of already baked in there and they're not. And so I think likely management has that idea too of like, okay, we got this well known erp, we're going to be good on the controls front, right? Like it must have internal controls and that's not ever the case, at least sufficient controls. And so there's a few other ones that we hit on that I think a lot of us can probably empathize with and have seen. What I thought was super interesting is how to scope controls integration. It just kind of seems like a ton of work and not necessarily super easy to keep everything in line and heading forward. So we talk about that, talk about Clear Salting's controls integration framework to a degree, to the extent that we, you know, could of course, common pitfalls with controls integration as well. So again, controls integration from a couple different angles and really a really fantastic episode along with of course, AI thoughts to kind of close this out. So with that said, here we go. Mark, what is a. Maybe a favorite AI use case? It could be a personal one or a professional one. Favorite prompt. Even if you're going agentic to any degree, anything along those lines, just kind of share with us a little bit about how you're using AI. Again, you can use personal, professional or both.
A
Yeah, yeah. A couple of things come to mind. I think kind of operationally, I think we keep trying to explore more and more uses here at Clearsaulting around just how we can use AI to help run our business a little bit quicker, faster and kind of get rid of some of the recurring steps that we do. I think professionally, I still use it an awful lot just to kind of educate myself on clients. If I getting introduced to a new client, trying to understand their competitive landscape, kind of their market, what are the trends going on out there? So just kind of helps me get up to speed really quick when I'm getting introduced to new clients or to just new industries in general.
B
The deep research on chat gbt, the equivalent is researcher on co pilot. But being able to use that to understand from your perspective clients for the audience, it could be their own industry or their own business. But like using that to understand the actual business and what's going on is. I remember when Google's thing came out, I think a year and a half ago and it's just a demo, I was like, that is the most insane thing I've ever seen and I cannot wait to be able to use it. And now I've got three windows open or tabs open right now that are all doing deep research. So yeah, I absolutely love that use case also.
A
All right, yeah, yeah, it's.
B
I did want to set the stage for the audience a little bit about. And so I've kind of talked about what you do, what clear salting does, or rather what you do within clear salting on your intro. But, um, to further set the stage, I don't think it's a surprise to anyone that there's more and more software being implemented. There's more and more AI being implemented. Like nobody is looking at their current software that they're using going, you know, we should probably just go back to pen and paper. Like we're not going to use software anymore. So like everything has software components to it. That's no great revelation. A lot of these like huge ERPs now, they force their upgrades and so it's kind of difficult to Work around that. If you have something that's like super custom, you can kind of dictate that kind of thing. But for some of these you just, you really don't have a choice. And that can. Speaking of AI, you know, when a. They basically throw away a model that someone is using, that tends to blow things up. And so a lot of those in some instances are unannounced. And so it is a huge pain. Um, and I think the other thing is like a lot of this is led by. And let me know if you disagree. But I think a lot of this is typically led by like one maybe 2ish team. So there's like a finance implementation team if we're sticking with finance or it's, you know, typically it led there. And so I think like especially the. Those three in aggregate just cause these like huge issues. And when I think what people do and what I want to get your. Your thoughts on is rely maybe too much on what they think is the situation or the case when that's not it for. For various reasons. So I wanted to play this game of why is this wrong with you? So I've got a couple of scenarios. One in particular that I remember, I was two years into my external audit career. This client I was on, they implemented this huge ERP and then they, they brought in another team like yourselves to do like sod. I think it was specific to user access. And I was like, well that's crazy. Why wouldn't. Either they do it themselves or why wouldn't the software already come like that with some level of understanding? And I was like, it's basically out of the box. Everybody has super user access and then you have to go in and, and actually change it. And so that I like, I remember where I was sitting when I learned about that. I was like two years into my career and I just, to me it just blew my mind. So I think that's what it's not uncommon for people to go. And this is where I want to get. Why is this wrong? Hey, we bought this software package. It's great and wonderful, great reputation. I'm sure it has internal controls.
A
Yeah, yeah. I think it's a great, It's a great question. I think we get that a lot. Right. It's the a. We're a big company. We're either buying a new ERP system that's kind of leaving class or we're upgrading what we have. And certainly we are not the first public company to implement this package that needs to think about SOCs. Or internal controls and just audit implications. So we must be in good shape. Right? And I think that's a, it's a fairly common kind of thought process of like, hey, we're definitely not the first, we're not the first in our industry, so we're just kind of following what others have done and we should be in pretty darn good shape. I think the reality is that these large ERPs come with so much optionality, so much ability to configure different processes, different ways. It gives you the option to really configure very well, kind of tightly controlled processes or fairly wide open processes. And in certain scenarios, a wide open process may make sense for you operationally and perhaps from a control side. But most of the time that configuration is really where our clients see themselves kind of getting in trouble because they're like, hey, this, this makes sense. We're going to go ahead and kind of push forward with this, you know, this piece of configure. We want kind of this workflow in place and they're not always thinking about the control implications of it. Or also sometimes it's, we have a fairly, you know, structured process, but somewhere six, seven, eight steps down the line I'm going to allow someone to modify what they received and are we going to route that back to the second or third step where someone actually made that decision and get a reapproval? So sometimes it's also kind of like, hey, we want flexibility. We want everyone in this integrated software package to be able to do their own thing, to be able to kind of respond to customer needs. But we also can have it impact what we thought was a wall control process earlier in the, in the, in, in the that transaction flow.
B
Now I will say I am grateful for that service that's offered because I'm. It's what my wife did for like four years. So it paid her salary. Very grateful. Got to know much more about how that works in those, in those years. But I think the other thing that I think about, and if I tied it to what we do, it's like an analogy would be we're going to go hire a data analyst, bring them into internal audit and then we're done. Like we're done with analytics, they're going to crush it. That's great and wonderful. And if you have someone with the audit background, that's perfectly okay. But a lot of times if they don't have that background, it does not go very well. And so similarly, it feels like there's a situation where it's like, hey, we hired this like fantastic system integrator. They've worked in public companies before, they're familiar with stocks, they have to know controls. Why is that wrong?
A
Yeah, I think oftentimes what I've seen realistically is that when, you know, most of the time when a system integrator is being selected, it's going through a very competitive RFP process. And a lot of the system integration shops do not include controls as a part of kind of their standard offering unless it's specifically requested in the rfp. And I think what I've seen is there's hesitation on some of the sis that do have controls teams. There's sometimes hesitation to include them because they're concerned they're going to inflate their price compared to their peers and it's not going to be an apples to apples comparison. So sometimes it's kind of like I just, we're not even going to include it because we don't want to be seen as having too inflated of our price. And then if we do include it, you know, is it going to be more of a minimalistic approach or is it going to be kind of a full blown. So kind of seem to come at it from a whole bunch of different ways. But the advice I always give my clients is, you know, review the engagement letter almost all the time. You're going to find a section in there that says, hey, when it comes to internal controls, when it comes to Sarbanes Oxley, we have no responsibility. That's a management responsibility. And even then they'll say, well, yeah, but still they've been there, they've done that, they understand controls, we're probably going to be okay. And the reality is their team is really focused on delivering functionality and they're not really thinking about the control implications of that functionality that's being implemented.
B
Okay, so we're talking controls integration and scoping that. I was curious to the extent that you can, could you give us like a little peek under the hood of the clear silting methodology relative to controls integration?
A
Yeah, absolutely. I think we think about controls as an iterative process. So we know that our clients are going to be going through, you know, if they're using an agile approach or a waterfall approach that they're going to be going through, through kind of a very well thought out process when it comes to gathering requirements and then kind of building and testing those. What we really like to be able to do is iterate on controls with them along the way. So there are probably Specific points in a project life cycle that we'll be able to come in, understand what design decisions have been made, how is that going to impact the control environment and then be able to provide feedback on it. So it's a bit of an art versus a science of like, hey, we want, you know, we want the paint on the wall, but we don't really want that paint having dried yet because we still want to be able to influence some of those design decisions if there's an opportunity to better leverage the technology to make controls more efficient. Kind of when you get to day one. So we like to iterate with a company with the system integrator along the way to make sure we're being timely in our feedback. But we're also, you know, not there too early or too late.
B
I've not heard the paint on the wall analogy, but I'm definitely going to steal that and start using it. That's a good one. The other thing I wanted to ask you about is this idea of a. I mean, you've heard it before, the audience has heard it before. I don't think it's ever actually gone this way. But when some software organization goes, oh yeah, it's just like a simple lift and shift, what you're doing already, like, we're not going to change your business, nothing's going to change business process wise. It's just a lift and shift and plug it in and you're good to go. Have you ever seen that actually happen?
A
No, I've definitely had a lot of clients think that that was going to be the case. Like, hey, our fundamentally, our business isn't changing, right? We're implementing new technology. It will enable us to do some things, but our fundamental, you know, what we do as a company is not changing, so it must not be impacting our control controls. So we can do a lift and shift our controls at go live right after go live and it'll be just fine. I think that kind of gets into the they don't know what you don't know scenario where the technology itself, the configuration that's being put in place, is it helping you from a control side hurting you? Obviously when it comes to key reports and kind of baselining the environment, there's an awful lot that can happen there. So yeah, the lift and shift tends to be a bit of a pitfall or hurdle that I've seen a lot of companies struggle to kind of clear because you do have new technology. So obviously from an IT general control perspective, you know, you gotta be updating that, but really the risk normally comes down to the business process controls and what's the config in place and then what are any potential manual controls that you'd have to kind of overlay. And then what about security? What about segregation of duties? And are we really thinking about how access is being provisioned? And are we, you know, you know, getting ourselves in trouble from a role design standpoint kind of out of the gates.
B
One of the major problems, maybe even root cause, this isn't my area of expertise. So I want to get your opinion on this though. But when we have these, these major initiatives, these transformations. So I know earlier we talked about like there's a team lead, but that doesn't mean that they are the only ones involved. So it is obviously ha. They have to be involved, finance has to be involved, risk has to be involved. And sometimes it's difficult to get those three groups together and understand their role within all this and to really communicate, which is so frustrating that communication is still like lack of communication is like one of the major control failures in a lot of scenarios. But do you agree with that? If so, how do we get that to happen? So like imagine we'll play a use case scenario game. I guess you're going into an organization major ERP upgrade or a quote, lift and shift. How do you work with those folks, it, Finance and risk to make sure that everything goes smoothly, they get the right people in the right room at the right time, et cetera, to really like root out where these issues typically pop up.
A
Yeah, I think a lot of it comes down to setting expectations, ideally even before the program gets kicked off. So if there's a phase zero that's happening or even kind of during the selection process of the system integrator, I think having some of those control discussions then is probably, you know, when it's probably most appropriate and ideal to try to have it really early. Because what we find is that if you talk about controls early, if you start to set expectations on, hey, this is what we're going to need the systems to do. Or as a system integrator, this is what we're going to need you to document and evidence from like an overall SDLC side, controls doesn't have to be this massive drain on resources. It doesn't have to be something that slows the overall program down. I've really found that if you have controls integrated well from the kickoff of a program, it really kind of just flows with the program. And the way I like to think about it is you know, the business is going to be coming up with requirements and they're going to be, you know, going through kind of visioning, you know, sessions around kind of what, what are we getting out of the box? Kind of what's the standard process that's being delivered by this ERP system? Is that going to meet our needs? It's not going to meet our needs and they're going to be documenting that. What I have found is if you can have control requirements being gathered as you're gathering your business requirements, that is a great way to kind of think about controls and integrate controls. So then it becomes very seamless. So then as a project team, we're gathering our requirements. Those are business requirements, those are control requirements. We're then going to build those, we're going to test those, we're going to train our end users on those new processes. And at the end at Go Live, you're sitting there with a well controlled environment because it's just been integrated along the way as opposed to two months before Go Live where you're like, man, we forgot about controls. I guess we better come in here and try to figure out, well, what did we actually build and then how do we kind of throw controls on top of it? And at that point you're probably going more manual as opposed to automated and really losing probably a great opportunity to try to, you know, build, build some automation into your controls and kind of get some ROI out of that technology spend from a control side.
B
Yeah, the, hey, we're two months in, three months in, whatever. Oh yeah, controls sounds common and awful. Like it just made me cringe a little bit to think about that. Just all the extra work that has to be done. Yeah, but I was curious, you were talking about phase zero, like bring in the controls aspect as soon as possible, basically. What does again you refer to as phase zero? What does phase zero look like? And what I mean by this is for those that are either going through this right now, either they're at phase zero or maybe they're at phase one, or for those that have a transformation project, like they know it's coming up, you know, at least looking at vendors or something like that, what can they keep an eye out for in quote, phase zero, so that they know like, oh, this is coming, we need to make sure that the controls aspect is involved or well, we're in phase one now so we, let's like stop it now, get the controls conversation going or pick it back up so that we don't have this two to Six month gap of lack of controls discussion.
A
Yeah, I think I've seen phase zeros kind of go different for different clients, right. Because typically there's a short list of things that they think they need to work on. You know, sometimes I call them big rocks or something like that. Like, hey, we kind of have some known issues here. We have a data issue or we've got some issue with some legacy systems that we're trying to understand their impact or maybe we're trying to make them go away before we even kind of get to the big program. So I think just understanding what really are their goals of phase zero. And then from there it's really just having the control team having a seat at the table. And again, it's not going to be the loudest voice in the room, right? There's going to be a lot of other key decisions that are going to be made, but just having a voice in the room to say, hey, we're going to build in controls, we're going to understand from an SCLC side, you know, what are the different kind of gates and checks that we're going to need to clear as a program. Let's make sure that we've got those things evidenced. But it's really just about kind of having that controls consciousness in the room so that as decisions are made, it's like, hey, we're talking about a business process flowing this way. Oh, hey, controls team, what are the control implications there? And I've seen it work really well where you're just in design sessions and people are kind of talking about things. And again, it's not like it's not adversarial, it's really consultive in nature where that controls team can be like, yep, no, that makes sense. We can control it this way or if we do that, it probably means we need to do something else before or after that to make sure that we've kind of got line of sight to what's happening there. So it can happen in a very, I would say, kind of like seamless manner. But it's really just kind of getting the team on board with, hey, controls are important. You know, we're going to make this big technology spin. We don't want to come out in the back end with, you know, any, you know, concerns. So like, let's just be thoughtful about it along the way. And you had mentioned earlier some of the kind of parties to get to the table. I think one that gets left behind often is external audit. And I was, I was in that world for A long time. And I think, you know, a lot of times our clients would kind of keep us at bay of like, hey, we've got all these things going on and we're going to bring you in at exactly the right time, which is typically really close to go live. And then we're going to tell you everything that just happened and we hope you're okay with all the decisions that we made. I definitely encourage my clients like bring external audit in early in the process, like let them know what's going on. If there are key decisions that are being made, let them understand what those are. And then they also understand your historic processes, they understand your pain points, they understand maybe the extra work that they've had to do for years because of the way you've got a process currently built. And hey, is there a way to maybe fix that process as a part of this new technology deployment? So I would also just encourage folks to bring their external auditor in at strategic times, right? You're going to, you're not going to want them there in phase zero, right? Other than to say, hey, we're kicking off this program. But as you start to make some of those key designs, as you start to have a draft, you know, risk and control matrix being pulled together, let's bring them in, let's get their thoughts on it, let's have them have a seat at the table. So when we go live, we don't want them coming back saying like, hey, we didn't even know this was going on. Now we've got all these concerns, we've got all this, you know, additional audit procedures we need to do. Look back procedures we need to do like let's shut all that down, let's get them at the table nice and early. And I think that can be a really again kind of helps smooth the go live. For the entire organization.
B
There was not much better than being an external audit doing year end testing. And the I was on the IT audit side and the CPA assurance side folks going, hey, we just realized they made this system change. You know, like there's a new software they've been using for the past quarter that we didn't know about. Nobody told us. So hey, I know it's you know, crazy busy season right now in January, February, everybody's trying to file but we're have to scope in this new application. And it's just, you know, it's a nightmare for everybody because depending on the industry, from my experience, certain industries have more of a control. Like financial services typically have a Higher acumen maybe for controls, like it's just beat into their brain so often. It wasn't usually a scenario there or a situation there, but others for sure that would pop up. And then it's external audit as the, you know, the IT auditor, we go in test controls and go, fail, fail, fail. Yes. Kick it back over to the, the business Insurance or the CPAs and be like, I know your busy season sucks too, but now it's going to be a lot worse. So I can empathize with that.
A
Yeah, Definitely saw that a lot in my time on the IT audit side as well. Like you just. Yeah. Finding out about things after they go live close to year end. Not a, Not a fun scenario for everyone. So, yeah, let's include, let's include our friends from the external audit side. Get them in, you know, in the loop on what's happening and, you know, just kind of eliminate some of those surprises.
B
Had to miss a couple of Super Bowls because of that. Not in attendance.
A
Never good. Never good.
B
Yeah, yeah, Just watching it for a moment. I was like, I guess I'll watch some of it with. With it on mute. But yeah, yeah, they made this change three months ago. So. All right, if we put a term on this, that kind of. The overarching conversation has been controls integration. And I think the thing that gave me anxiety about the, hey, we haven't considered controls integration for two, six months into this process is just the scoping of that even before. This just seems like huge organization, huge software implementation, and then just scoping this all out seems incredibly, I don't know, tedious, painful. So I'm just curious, how do you scope controls integration for any of these situations that we've been talking about?
A
Yeah, I think a lot of times what we're trying to do on the front end is really it's a bit of like a controls impact assessment. Right. So we understand your current state controls, we understand new technology is being implemented, and we know on the back end that we want to have really strong controls. So there's a little bit of a crosswalk of like, let's talk through our financially significant processes that we have in place today. What technology are those processes flowing through and then with this program, how many of those are being impacted? So at a very kind of base level, just, you know, L1, L2, L3, kind of like the L3 level, let's just kind of talk through what's being impacted by this program and then from there we can do a crosswalk to the controls side of it. So that that exercise itself is often eye opening for the business and then for kind of the compliance and risk folks at our, at our clients because they don't always understand the full impact of some of these programs. Like, hey, I thought we were implementing this piece of technology. I didn't realize it was going to impact these other things. So just understanding from a pure kind of process and system side, what are the impacts going to be, that gives great insight to like, okay, here's our future state. Well, when we go live, this is the technology that we're going to have in our environment and then this is how we think our transactions are going to flow through that environment. From there then we can start to understand, well, what are the impacts to our current set of controls and then what are the opportunities that we think are out there to optimize those controls, to automate those controls, kind of reduce some of the, the manual kind of human input that we've got in the environment today. And then also what I've seen with a lot of our clients, how do we then increase security and sod controls as well? Typically we don't see a lot of those being key controls, but we think there is an opportunity to really kind of hone in your other controls, especially your manual controls, if you can limit some access that's out there as well. So from there we kind of understand what systems are going to be impacted. Then we can do some itgc, you know, scoping, you know, that, that kind of piece of it. We'll understand what business processes are there. So we'll start looking at manual automated controls, I think some other categories that are out there reporting. Right. What are, what's the impact going to be to our key reports? So there's normally going to be an inventory of reports and what is going to be delivered out of the system, kind of out of the box that we can just kind of say, hey, it's there, it's never been modified, we're good. What kind of custom reports are we talking about here? You know, custom reports is one of those things where at the beginning of a program my clients will tell me we're doing no custom reports, everything out of the box, then you get to go live and we're at a 50, 60, 70% custom report. There's a controls in back there. Right. We need to understand what you did. And we got to go and baseline those things and give all that testing and evidence kind of ready for audit. So that can be a big piece of it. I think the other piece from a data. The other piece from a scoping side is data. And we could probably spend some serious time talking about data, right? Because I think anyone that's been through a big ERP program knows that data has probably been an issue or at least a troublesome spot for them. Right. I think the effort around data is often underestimated and the controls and compliance around data, I think is often underestimated. Right. There's a, you know, I've even seen it, you know, going from an upgrade, right? We're kind of going from one, the same ERP to the newer version, but we're doing, you know, we're not, we're not, we're. We're. We're technically doing a greenfield. We're doing a new implementation of that package, but it's not like a brownfield or just like a pure upgrade, right. And even those companies really struggle from a data side because they've customized those systems and the new versions of those applications want to ingest data slightly differently. So data is an area that we spend a lot of time with our clients talking about data, data lineage. And then obviously from an audit side, just understanding kind of how the system that we have been auditing and we had controls over, you know, those ending balances, how are we then getting those into the new, the new system, and do we really have comfort around completeness, accuracy and validity of that data as it makes it move over? So data is a big, a big item as well. So I think when you start to kind of think through all those kind of different things, that's probably an awful lot of what we think about from a scoping side, obviously SCLC would be in there. If it's a third party hosted app, there might be a SOC report that we'd be looking at as well. But that's often how we think about scoping one of these big CI programs.
B
Think of the data, I would say data usage piece. And this isn't necessarily controls thinking, but it's something that gets overlooked also. So if you think about, usually with a new system, there are new fields, like at a simple level, like, hey, there's new fields that we can input data in. Or, you know, whatever the case, anybody who's gone through an audit management system, change will go like, oh, yeah, we never really captured that in the past. We never thought about it, here's a field, we should capture that. And so I think that gets overlooked also. And like, we have these, maybe even new ways to access the data or use the data. They don't get considered because it's, it's a huge implementation. So it's touching pretty much everybody in the organization. And so probably a lack of data literacy within the entire organization can create that. Not necessarily an issue, but create a lack of opportunity identification. That sounded like the most consultant thing I've ever said in my entire life. The lack of opportunity identification because of a lack of data understanding and being like, oh, we could use this now to do this as part of our business process. So that's, that's kind of where my mind went. Also, when you're talking data, as I start to wrap things.
A
Go ahead. I was going to say I just made one other thing to add on there that we often see is like, when you've got, maybe there is multiple legacy ERP systems out there and they're trying to move to more of a single global platform as a part of this latest transformation, all those legacy systems probably have very different data structures and that you're going to move to kind of a common platform, common structure. That is not an easy thing to do. And I have seen a lot of phase zeros be data driven, where it's a lot of cleanup of data because we know we can't even really start the overall program until we get our data in a better shape. And there are control implications on the data side. Right. We need to understand how data is being mapped, modified, as you said, kind of pulled apart or pushed together because that new system wants to ingest it in a different way than our old system did. A lot of those can be control implications. So I think having a controls mindset over the data process, migration, governance strategy, all of that, I think it's critically important and I think it's an area where, from a risk and compliance side, we can add a lot of value because I think it is one that's underestimated by a lot of project teams. So I think if as a, you know, consultant, as an advisor to a program, I think we can add a lot of value in that space and it is probably underserved at times.
B
Excellent. I think that's a good way to summarize it. Also, I think we'd be remiss if we didn't ask AI, of course. Where do you. Where do you see AI helping in the controls space?
A
Yeah, I think obviously there's a lot of, well, I'll kind of call like toes in the water when it comes to AI. Right. And I think we're, we've kind of been at this tipping point for a while. Where is AI really becoming a factor for the audit? Or is it used more for operational or business purposes, but then still being reviewed for, you know, completeness? And the control itself is still being reviewed by like a human at the end of the process. That probably is typically where we're still seeing it the most from a control side is how is the data being collected and presented to the user for review and AI helping to bring it together, to format it, to present it, to look for exceptions. But we still have an end user kind of at the end of that line still really helping to perform that control. So I haven't seen, you know, AI completely eliminate kind of humans from the picture, right. It's really more about enabling that control performer to be more efficient, to be more kind of effective, less time, you know, all of those things. But I think there's still an awful lot kind of in the near term pipeline that we're seeing where I think we could really start to kind of trip over to where, you know, there are companies that will be using AI to really either perform their controls or to perform larger portions of the control. And we're going to have kind of this kind of mega control at the end with someone reviewing a whole bunch of information and signing off on it. So I think that that's where I see a lot of our clients heading. But I'll say that for my clients at least there's been a lot of baby steps, right? This is not an area where, you know, they want to, you know, kind of be the first with their external auditor to try to get some of this include included. So I think it'll be interesting from that side to kind of see what is the external auditors want to have in place around controls. And that's an area where we've been spending time just understanding how AI is being used and how to prepare for external audit to be included in their approach. And like I said, this seems more baby steps than we making these huge, huge leaps.
B
That's where I see it also for the time being, I can't imagine when, but not having the human in the loop ultimately at the end, like I can't, I just can't imagine regulators even being like, yeah, we're totally fine with this, let AI make all the decisions. I cannot foresee that happening. But I also agree there is the, the idea of using AI to actually test controls. So thinking about the internal audit folks is definitely very real. It's not an idea, it's, it's real. And there's, you know, Some teams that are doing that and some vendors that are doing it at a pretty high clip also. So. Yeah, all right, for sure.
A
Yep.
B
Sorry, say that one more time.
A
I would just say for sure. On the testing side, I think there's some a lot. And those are, I think, easier to get your arms around. Right. And easier to get comfortable with that because you can kind of really see what the AI agent is doing as a. You know, and then you can see how it replicates kind of what the human was doing. So I think those are. Those are probably a little easier for everyone to get comfortable with.
B
So I appreciate the conversation. I think one of the things that stuck out to me the most was the. The phase zero talk that we had. And really, because it's just like a. Not a red flag, but a flag that goes up as like a, hey, now's a good time to consider this. And so I appreciate that. Again, thinking about the anxiety of this has been going on. You know, we've been going through this without considering controls integration for X amount of time just does not make me feel warm and fuzzy inside. So I appreciate that. I'm sure the audience did, too. With that said, is there anything else that you want to leave the audience with? I'm just going to kind of hand the microphone over to you and let you take us out.
A
No, thanks. And thanks for the time today. Hopefully you can tell, like, we're really passionate about controls at Clear Salting. And I think it's an area that, for a lot of our clients, we find that it's a blind spot for them. And we've really been able to add a lot of value by helping them kind of see around the corner and really understand some potential impacts to their program and really to their organization if they don't think about controls. So we love controls. We're excited to build a partner with our clients. We have a great understanding of all the major ERPs out there, and we really kind of see that blend of technical skills, compliance skills, audit skills, and then really business process skills coming together to be able to really understand what are the true impacts to an environment from a controls perspective. And it's an area that we're super passionate about. So we are going to be a GAM. We're going to booth 111, so I'll be there if anyone wants to stop by, catch up on controls or anything in this space. We would absolutely love to have anyone stop by and visit with us there.
C
Hey, everyone, thank you very much for listening to this episode of the Audit Podcast.
B
Whatever platform you're listening on right now,
C
I'm sure there's a subscribe button somewhere, so please hit the subscribe button there. If you're listening through itunes or Spotify, feel free to go give us that five star rating. It only took me about 16 seconds to give myself a five star review and it really helps to get future guests to come on the show, so we'd really appreciate that. Lastly, be sure to check out the show notes and follow us on all our social media channels, on Instagram, on LinkedIn, and on TikTok. Also, if interested, please sign up for our weekly newsletter from the Audit Podcast.
B
Thank you all. Have a great one.
Guest: Marc Walrod (Controls Integration Leader, Clearsulting)
Host: Trent Russell
Date: March 3, 2026
This episode explores the persistent challenges organizations face when integrating controls across IT, finance, and risk functions—especially during major technology transformations like ERP implementations and AI rollouts. Trent Russell and guest Marc Walrod dig into where controls integration breaks down, common myths, the crucial "phase zero" in transformation projects, and actionable strategies for getting controls right from the start. The discussion is candid, practical, and driven by real-world examples, with a focus on preventing costly surprises down the road.
Misplaced Assumptions about Controls in Software
System Integrator Limitations
“Almost all the time…there’s a section in the engagement letter that says...‘we have no responsibility [for internal controls]. That’s a management responsibility.’” (12:17)
What is Phase Zero?
“Just having the controls team having a seat at the table...not the loudest voice in the room, but just having that consciousness so that as decisions are made...you can ask, ‘what are the control implications?’” (21:43)
Early Integration of Controls Prevents Headaches
“If you talk about controls early, if you start to set expectations... controls doesn’t have to be a massive drain on resources.” (18:15)
“It’s so frustrating that lack of communication is still one of the major control failures in a lot of scenarios.” (17:05)
“At the beginning...my clients will tell me, ‘we’re doing no custom reports.’ Then you get to go live, and we’re at a 50–70% custom report. There’s a controls impact there!” (27:48)
“Bring external audit in early…If there are key decisions, let them understand what those are...and maybe fix pain points as part of the new deployment.” (21:43)
“I haven’t seen AI completely eliminate humans from the picture...it’s more about enabling the control performer to be more efficient.” (35:54)
“I assumed...if you bought some huge ERP, at least some SoD controls were already baked in. And they’re not.”
—Trent Russell (06:39)
“We want the paint on the wall, but we don’t really want that paint having dried yet because we still want to be able to influence some of those design decisions.”
—Marc Walrod (13:56)
“Data is an area where we spend a lot of time...the effort around data is often underestimated, and the controls and compliance around data is often underestimated.”
—Marc Walrod (27:48)
“The phase zero talk...it’s just like a—not a red flag, but a flag that goes up as a ‘Hey, now’s a good time to consider this.’”
—Trent Russell (39:11)
Want more?
Catch Marc Walrod and the Clearsulting team at Booth 111 at GAM, or connect via LinkedIn/newsletter (see show notes).