Subscribe
Share
Share
Embed
Let's talk IRM. The real stuff. Join Jada, a certified ServiceNow IRM practitioner, as she breaks down compliance automation, risk frameworks, and the strategies GRC professionals actually need. No fluff, no theory. Just real talk from someone who builds it. A SaaSCE Boutique Podcast.
speaker-1 (00:02.638)
What's good Armies crew? I'm Jada and this is Let's Talk IRM.
speaker-1 (00:12.16)
In episode two, as you remember, we made the case that IRM begins before you even touch the platform. Today we're getting into what that actually looks like in practice. Specifically, what it means to plan for a ServiceNow IRM implementation. There's a version of planning that looks like a project manager's checklist where you have the kickoff date, resource list, and go live target, but that's not what we're here for.
We're talking about the planning decisions that determine whether your IRM implementation actually holds together at scale beyond the go live target. Now, for today, we have Ilay back with us, of course. Welcome back, Elay. Thank you. And today we're adding someone new to the mix. We have Nish from PSS Tink Support Services LTD based in the UK.
Mish is going to help us as our moderator and brings a strong strategic and implementation experience on the ServiceNow platform and specializes in HRSD application, which has more overlap with IRM than people might expect. So welcome Mish. Thanks for joining us.
speaker-2 (01:29.794)
Hey. Hello. Thanks for having me.
speaker-1 (01:32.91)
So Meesh is here to help ELA and I stay focused because if you've listened to us together before, you know that we can go deep fast. So Meesh, implementation planning is a big topic and we've got a lot to cover. So let's get to it and let you take us in.
speaker-2 (01:50.488)
So our first question, which is to Ine, is why isn't planning just project management? So my question to you, Ine, is when implementations go sideways, where does it usually trace back to? Planning or something deeper?
speaker-0 (02:06.808)
think it depends. And I say that because most of the time it does trace back to planning, but it also depends because depending on the team that the project has or the kind of people that are going to be involved will determine what that setback or pretty much an implementation setback is. Kick up is really for everyone that is going to be involved in that project to understand what exactly we are doing here.
So that everyone knows who those resources are, who the decision makers are, and what exactly we're going to be touching in the system. That's part of that implementation kickoff. And most of the time, that's part of planning. So that kickoff is part of planning from the customer side and planning from the implementation team side. And that's why I made the comment about it depends because it's part of planning that maybe it's from the customer where they didn't have enough of the resources.
or people who will be involved, including stakeholders, and that kick off. So everyone doesn't actually understand what they're gonna be doing or the level of involvement they will have, right? Because they think because I'm the product owner, I don't need to be here.
speaker-2 (03:13.602)
So is it actually a planning issue or a misunderstanding of the platform?
speaker-0 (03:18.06)
I think it's both. Like I just mentioned the planning part of it, right? Yeah. Yeah. And then when we get to the implementation part of it, it's more of do you understand what the platform can do for you? Or did you understand what the platform could do for you when they initially sold it to you?
speaker-2 (03:34.37)
What point does planning become a technical requirement, not a project management task?
speaker-0 (03:40.984)
Think it becomes technical when we actually get into the implementation of it. Like, let's give an example. If we were implementing some part of CMDB, okay, maybe business application. And yeah, we had a plan initially that hey, we were gonna either do, meaning during the key cup, we mentioned, hey, we will be loading the data with XYZ, right? From either a spreadsheet, maybe they have a repository in the spreadsheet, we're not gonna do any integration.
To any external source to bring the data in, or we're not doing discovery, you know, implementing the discovery for Sam DVD. Maybe that was initially part of the plan, where we're not gonna do that. It becomes technical when they start making the decision, when things start changing in the middle of it. And things change a lot. But there are some changes that have a huge impact on the timeline, that have a huge impact on the scope, that have a huge impact on the budget. Right? But they didn't nobody realizes it at the beginning.
speaker-1 (04:32.088)
It's true. Yeah. Yeah.
speaker-0 (04:36.75)
But then because the school grip and things like that, then that becomes that technical impact. Because it's not that it cannot be done, right? It's just gonna add more time to what we're you know, what we initially planned, right? It's gonna add more cost, right? Maybe the customer has to procure another additional license where we need more hours now to do the X, right? It will literally there's some form of implication, either negative or positive, when it becomes like a technical setup.
speaker-2 (05:03.982)
Jada, question for you. Is there a real difference between project management planning and technical discipline planning? Or are they both confused?
speaker-1 (05:11.848)
Yeah. So I heard Elay when she mentioned about the project kickoff, having the stakeholder list and for practitioner perspectives. Yeah. I do understand that's necessary. Having a project manager helps keep things on schedule. But from the perspective that I have is, you know, IRM is more of a process. And so while yes, we have due dates that we want to meet.
That doesn't necessarily mean that our implementation is complete by the end of that date, right? So from a project management standpoint, I feel like those individuals get too focused on, okay, what are the key milestones of the project? When is the go live date? What is the checklist? And those items not truly understanding the complexity of what's required for each item on the project roadmap. And so they get lost in focusing on
start to end that in the middle, just as Elay mentioned, there's technical difficulties that might occur that could cause delays. And so from a technical discipline planning, though, I kind of interpret that as an architect, right? An architect is someone that understands the platform, understands the application, but also understands the business needs, right? And so I feel like in a way, them working with
The project manager can help align realistic goals on okay, what are we accomplishing in this first phase of our IRM implementation? Doesn't necessarily mean all three modules. It could just mean focusing on the first module, policy and compliance. And then from there, what are the key people that are going to be utilizing that module and why? And so as a practitioner,
I see that third person that is going to be using that policy and compliance module that needs to tell them, this is my process. Now help me get to using IRM. Now keep in mind though, their process doesn't necessarily mean it has to be one-to-one in the platform. Their process has to also align with how IRM works. Otherwise, that's more work that needs to be added to the project roadmap.
speaker-1 (07:37.132)
Because if they're in a manual siloed state, that takes more time on the project. So overall there is a difference. Both sides are needed, but I think there is that third component that's also needed to help keep the project realistic and on time. I just wanna
speaker-0 (07:56.44)
Comment on something that Jada just mentioned, right? Because I heard her say that this is where the architect works hand in hand with the project manager to pretty much align on what needs to be done, right? Uh-huh. Keeping in mind that those should have been identified in the beginning. Personally. Because that kickoff includes what are we doing? And we all know it. We're in the IRM world. We all know even after implementation, that's never where it stops. Because IRM is more of a that's why we call GR sub.
speaker-1 (08:13.208)
Yeah.
speaker-0 (08:26.018)
Right. It's a governance risk of compliance. IRM is just a portion of how GRC gets accomplished, high level. Okay. So and I understand like practitioners wanna always say, this is my process, right? This is how I want to do my process. But keep it in line that there is no implementation of IRM that is never phased. You would never get what as a practitioner, what you're looking for immediately, right?
Your process would like you said, it's not a one-to-one. It has to evolve as you go along. Right. But that has to be identified even with the architect in the beginning. Because most of the time when the implementation actually starts, implementation starts truly when, and I use the word implementation, even though the whole thing is implementation, but the actual work starts when the development starts, right? When those configuration, the data load and things like that truly starts, right? But the initial the discussion of hey, during this kickoff.
This is what we're going to do. You might have bought the whole suite of IRM, but there is no way on earth those whole suites will be implemented. Right now, this of hey, this is what we're going to implement would have been even sculpted into the SOW, the statement of work to say, hey, this is how we would do it. This is how we would start. And that's why literally every time you start a new phase, you have a kickoff so that everybody understands this is what we're doing, including our architect, including the practitioner themselves, right? So that there's no confusion of what are we doing again?
speaker-1 (09:23.608)
That's decision.
speaker-1 (09:46.414)
That's a good point that you put, Elay. So not necessarily at the kickoff, but when we're at the SOW development, those key parties need to be discussing then, making it clear that, hey, this is what's realistic. This is what's on the SOW. This is what we're gonna plan for. I like that. I don't know if in reality, if that happens, but I think that sets a business up for success when you have all those key individuals.
that are going to be doing the work, that's going to be doing the strategic plans, and that's also going to keep the roadmap together. I feel like that makes it realistic. So thanks for clarifying that.
speaker-0 (10:26.274)
no, definitely. And I know it maybe all implementation don't do that, but I tell you, at least from our perspective, we do do that. Fine. Huge difference. And we just finished one and we're about to start phase two. And we're still doing policy and compliance. That's our phased approach, right? Even though, you know, IRM is more application. But just one, we're breaking it down, right? Just because it's like, hey, there are a lot that you're looking for. Let's break it down so you get your ROI at every phase of it.
speaker-1 (10:32.456)
It makes a big difference. Yeah.
speaker-1 (10:53.006)
Mm-hmm. Exactly. So
speaker-2 (10:54.828)
This is to you really. What does the build actually depend on that most teams don't validate?
speaker-0 (11:01.868)
When you say build, can you explain to me what your meaning by build? So
speaker-2 (11:06.222)
So it's like what does a team look like when their control framework documentation isn't actually ready versus when it isn't? So when's it actually ready versus when it isn't ready?
speaker-0 (11:17.422)
So and that's from the customer standpoint, right? Where every organization has some form of requirement, right? Regulatory requirement they have to adhere to. Now some organizations think they have it until they get into service now. Some organizations have it all in a spreadsheet, right? But when we implementers come into the picture, or consultants rather, right, come into the picture, most of the time we want to understand what does your organization, not just what you have on paper today. Okay.
What does your organization currently have that they need to adhere to? It could be ISO, it could be COVID, it could be NIST, whatever that regulatory body is. Now, today, how do you do it? How do you know you're following whatever NIST says? How have you been doing it? Right. I have a customer right now where everything is done on a spreadsheet. Okay. They literally have tabs and
columns that help them track each control objective, meaning the requirements that I'm gonna give example, the requirement that NIST says. Now, for us, that's not ready for us to bring into the system, right? Because sometimes you have some requirements that can help you satisfy multiple clauses within a regulatory body. You're not gonna ask the owner of a control to give you evidence for the same thing that they just gave you, because it's gonna be the same thing for
Let's say it was an access control issue, right? Or access control requirements. And the same way they're gonna give you the evidence for Okta is the same way they're gonna give you the evidence for ServiceNow because they use Octor or single sign-on to log into ServiceNow. Those are two different applications, right? But they're all linked together. Now you're not gonna ask them to give you individual evidence, right? Because maybe they only track it on the Octor level. Now keep it mind when we're bringing in that framework, we wanna know.
What are those requirements that can satisfy multiple things? Sometimes they don't have that depicted on their spreadsheet. Sometimes we have to even suggest to them, hey, why don't you do an integration with UCF? Because they already have that framework in place. They already have the requirements already mapped, which is like compliant onto test many kind of situation, right? Or you might already have, and you can reach out to UCF service now has that integration. All you need to do is make sure you have a license.
speaker-0 (13:31.426)
That's something Service Now has, right? Sometimes Service Not gives you accelerators that you can start with.
speaker-1 (13:36.118)
And you know, me, that those are key points that Elay's brought up from a practitioner standpoint that I see as a big gap as well. So internal controls are what she's describing. Yes, we have the regulation that's telling us what we should be doing, but how is your organization doing it? That's the internal controls that are documented that are traced to multiple regulatory requirements. And when you bring up that conversation.
Sometimes it gets a little uneasy because depending on how long the organization has been used to doing their way of things, they don't agree with it. They don't see that. They don't understand that that is the purpose of what a control objective and ServiceNow IRM is supposed to do. It's supposed to document those internal controls and then give you traceability back to regulation. So I definitely highlight that, yes, that is the first step.
But it's not easy. It's sometimes it's a difficult conversation and Elay was very polite about that. But I've seen it and sometimes it can get pretty difficult. So do you
speaker-2 (14:42.998)
think documentation is ever truly ready or is it always evolving?
speaker-0 (14:47.64)
Me, I think it's always evolving, right? Because even these regulations change over time, right? Even the internal documents that Jada was just mentioning some seconds ago, they change as well, right? Because if something in the regulatory body changes, you're gonna have to update either the implementation of
Any of those internal controls for how they've been implemented or what the requirement is or what the supplement or guidance is, you're gonna have to update something. So it's to me, again, I know I'm not a practitioner, but I've seen it evolve over time, especially with mutual customers. And one of the things they always ask is, hey, I need to be able to update this. And even sometimes they would implement another part of IRM called regulatory change, so that they can keep track of those changes and let the system do some automation of updating for them and all they need to do is approve it, which saved them a lot of time.
speaker-1 (15:34.518)
I'm so glad you brought that up. That was the first thing that was on my mind because yes, it's an evolving program meet, but it's done manually half the time. And so if you don't have someone monitoring those regulatory changes, it gets out of date fast. But see, that's what IGAREM excels at. It's helping you automate processes like that through the regulatory change management solution so that you don't have to worry about whether or not you're gonna have an audit finding when audit season comes.
speaker-2 (16:04.012)
Yeah. Instead of doing it manually.
speaker-0 (16:06.656)
You don't want to do a lot of things manually in the IRM world or GRC world in general. Because it's a lot of work doing things manually. Once you can remove as much manual work as possible, it makes it easier for people to adopt. It makes it easier for people to say, Hey, now I like this change to my process.
speaker-2 (16:22.542)
So did if a CMDB has gaps, is there ever a minimum viable threshold?
speaker-1 (16:29.518)
So I think there is. Now IRM has an entity hierarchy structure, right? So an organization that is intentional and understands that yes, our CMDB needs work, that can be worked in, in my opinion. But for an IRM implementation, you'll notice that a lot of organizations don't track as granular as IRM can. So having a CMDB with gap.
As long as we can start at that crawl state of starting with, say, your department level, I think that's a good start because that's where a lot of the documentation lands. If your internal controls are based off of document of departments, that's an easy landing spot for us to get started. It's not the end, of course, because then you have the work processes that follow under that department. And then you have the teams that actually do those work processes.
And then you have the applications that those teams do to manage the work processes under the department. So as long as it's intentional and understood that yes, we have a plan in place to improve our CMDB before we get to the desire of granularly tracking our applications or assets, I think that's the minimum valuable threshold.
speaker-2 (17:48.078)
Do you think it's always a blocker to go alive?
speaker-1 (17:50.11)
if they say no, if they decide that CMDB is not important, that's a whole different conversation. Because I don't know, Elaine, I don't know how many times you've seen the CMDB in different organizations, but in my experience, I've seen a team where CMDB was implemented, but no one trusted. And as a result, when IRM came into the picture, there was a scramble of trying to understand what do we do with our CMDB health.
There wasn't an intentional plan in place, it was an afterthought, and that caused delays, that caused scope creep. So honestly, if you're considering not to improve your CMDB, I definitely think that could be a huge blocker for your IRM implementation. So
speaker-2 (18:33.528)
realistically can IRM run without a fully trusted CMDB?
speaker-1 (18:38.964)
I say a C D B is a key component to an integrated risk management strategy. You need to have a plan in place to say, yes, we're going to improve our C D B so that we trust it, so that it can integrate with our IRM strategy. That would be the highlight that I would say about that.
speaker-0 (18:55.734)
Okay. And I would respond rather with I don't disagree, Jada, but that's if the whole I'm not gonna say whole purpose, but if the reason of implementing some of the IRM feature is for you to go granular, like you mentioned previously. Because when we say granular, you're really checking those applications, those business services, right? Those servers, those windows, right? You do need your CMBB to be up to date and for your organization to trust it.
But IRM is not all about CMDB. And I feel like sometimes customers do not realize that because it depends on if you're trying to do high level enterprise risk assessment or high level enterprise compliance, that's not gonna leave in your CMDB. You're talking about your business units, you're talking about your departments. Those are not in your CMDB, right? So I feel like it just depends on we need to understand what is the object that we're trying to show.
Compliance or risk against?
speaker-1 (19:57.294)
So let me ask you this. So I know you've seen more environments as a consultant. So as a practitioner, the interpretation that I received was we want to go granular. Now, from your perspective as a consultant, do you see more orgs trying to go more granular with their IRM strategy? Or do you see them trying to stay at their same state, but just in IRM?
speaker-0 (20:21.09)
The more mature ones go granular. They have the body, the resources, right, to be able to account for that granularity. The organizations that are trying, right, to mature, they don't have the capacity to go that granular. They don't even have the resources to support that granularity. They don't even have the information to be able to say, I want to start doing that granularity. And if you're doing an implementation for the first time,
for that organization, if they're coming from spreadsheet today, you're not going to tell them, hey, you have to do granular because they don't even have that.
speaker-1 (20:55.19)
That's a disaster waiting to happen. Yeah.
speaker-0 (20:57.058)
Yes. So that's why even with Service Now, and I'm sure a lot of people would have seen, you know, the document where they talk about maturity level. Right. Let's start with what you have. If it's business level that you're capturing, fine. Because the entity, remember, the entity hierarchy will grow over time. It will mature over time. You're not gonna build all the hierarchy at once. It's not possible in the first implementation. So that's why I'm like, it just depends. And I try to help our organizations understand. Yes, you want your CMVB to be maturing.
speaker-2 (21:04.941)
Yeah.
speaker-1 (21:20.078)
Exactly.
speaker-0 (21:26.914)
But we also have to face reality.
speaker-2 (21:29.464)
Stakeholder and ownership readiness. My main question is over to you, Jada. So is stakeholder alignment a soft skill or a configuration dependency? So I wanna ask you, can you walk us through a case where ownership wasn't confirmed before configuration? Or don't we just break it down for you?
speaker-1 (21:31.278)
Sorry, okay.
speaker-1 (21:50.104)
So I definitely think stakeholder alignment is key as a part of the process, especially ownership. I had a time where ownership was not confirmed and when the quote unquote go live came and the adaptations went out, about seventy five percent of the people were like, What is this? IRM got it wrong and IRM got so much heat for it and that made me so sad because IRM is an application.
It is not a person. It only operates on how you've implemented in the information that you feed it. If you don't take the time to properly identify who your owners are gonna be as a part of the entity process, I mean you might as well stay in the spreadsheet. I agree.
speaker-0 (22:35.79)
And I a thousand percent agree.
speaker-2 (22:37.848)
So why she went wrong in that situation?
speaker-1 (22:40.3)
In that situation, it was communication and stakeholder alignment. There was the intention of building IRM siloed, which does not work, and then letting the stakeholders know, hey, you have this attestation that you need to do, and they're like, What is that? What are you talking about? And this is wrong, by the way. So it was a communication error and it was a data error that
Could have been fixed if there was intentional planning on aligning and correcting it during the implementation process. User trust is very thin when it gets to that point. When you're rolling out the ServiceNow IRM tool, ServiceNow already is a complex tool. So you need to have proper user adoption. So when you make a mistake like that, and owners are already busy, stakeholders have they have to go to meetings to meetings.
And they have controls that they know that they're responsible for, but when they get the wrong control, they don't have time to just jump around and expect, well, let me fix this for the GRC team or whoever's managing the IRM application. No, they're gonna look to the IRM application and say, I thought this was supposed to solve our problems. And in turn, it caused more problems. So being intentional when you're planning about your user adoption.
Who's the stakeholders? Who are the owners that need to be notified that this is happening and confirming are you actually the owner of this department or your entity? That helps a lot when it comes to the control process. Because then they can ask, they can put in input as to, well, yes, I am owner of the department, but these are the individuals that respond to the controls under my department. So that helps and being able to roll out.
And have a user adoption that's more positive than negative.
speaker-2 (24:33.848)
So, Eile, can I ask you a question? Have you ever started an implementation without confirmed ownership? And if you have, what happened?
speaker-0 (24:42.708)
We don't start implementation without confirmed ownership. We always have owners. Somebody, one way or the other, has to own this and has to be responsible. And that goes back to one of the things Jada said, where she mentioned adoption. Because there needs to be communication since the beginning from that leadership or that owner to everybody in the organization for awareness of what's happening, what's coming, what's changing. So that nobody is surprised.
speaker-1 (24:45.784)
I love that. We
speaker-0 (25:11.02)
We also need ownership to help make decisions. Now, I'm not saying ownership does not leave in between or while we're already implementing and the person decides to win the lottery. Okay? Yeah. That's great. But we need someone else to take responsibility right after. And I'll give you a literal example. We had an owner who decided that they needed to I'm just gonna use the word they they were gone for PTO for the remainder of the project. Okay. Before they left, we made sure.
You need to assign somebody and the person has to be able to make decisions on your behalf because you knew this project was coming, right? You were aware of it. You need to designate somebody else. And that person pretty much has to have almost the same authority and power or permissions or responsibility that you have right. And they have to be willing to take it.
speaker-1 (25:58.712)
That part is key. It cannot be an individual contributor, point and blank.
speaker-2 (26:03.32)
So what does good ownership set up actually look like in practice?
speaker-0 (26:06.968)
This. I think it depends on the project or what you're implementing. But for me overall, good ownership requires someone who also knows how to not just only make decisions, but communicate. And not just as basic communication, like leadership communication. Yeah. I don't know how else to describe.
speaker-1 (26:27.712)
I can understand that. And I think in a perfect world, Elay, from my perspective, I know that there has to be a technology owner that owns the IRM application. But then on top of that, there's also the business stakeholders that have been identified for their responsibilities on the business side within IRM. So I think in a perfect world, an organization that comes in knowing that.
and understands that there's the technical ownership and then the business ownership. I think that is setting us up for success because we're all understanding our roles that we play within this implementation and that it's not just going to get thrown onto one team and expect them to figure it out. And then when they get it wrong, use them as the blame point to say, Well, if you did X, Y, and Z, it wouldn't have ended up like this. I hate that. I agree.
speaker-0 (27:19.254)
And that's why, regardless if it's IT or if it's technology or business, ownership, that person has to have, or those people, whoever they are, have to have some form of authority. Not authority to boss people around, that's another point, right? But to make that right decision, those right calls, even if they're not the ones making the decision and we're feeding them the information to make the right decision, but they ultimately still need to
speaker-2 (27:43.95)
So my question is ServiceNow versus practitioner responsibility. So this is out to both of you right now. So is a readiness gap ServiceNow's responsibility or a practitioner side problem?
speaker-0 (27:58.574)
I think it's both. When a customer needs to implement a part of IRM or the whole suite of IRM, whichever one doesn't matter. Right? The style dictates the decision, the scope, right? Okay. Yeah. It is the responsibility of the implementation team to provide to the customer, based on what they've asked for, based on the scope, a readiness checklist. So that they understand that these are things that we need from you either before we start during.
The process, right? They're aware of what would be required from them. Yeah. Now, when you hand that over to the customer, it is now their responsibility to ensure that some of those items on the checklist, they're covering it. And I'm saying some because in the beginning they might not be able to provide it. A good example is data, right? Now, when we start, are we gonna give you a cutoff date and to say, hey, buy X, Y, and Z date, we need this data just so we can meet the timeline, right?
Yes, we will. Okay. But at least you have this information ahead of time. And this information goes way ahead of time before even the kick up because implementation team is aware of what you want. Right. And that doesn't hold back. Now I've seen customers that even when you give them that checklist, okay? Yeah. For readiness, it's literally called a readiness checklist. There is some things that you will have to do, unfortunately. We implementers cannot do everything for you. Okay. But that's where the risk comes and where you have to tell them, hey, there's a risk, right?
Yeah. And I feel like anybody can say, it's not good to talk about timeline. There is no way you would never talk about timeline in an implementation. You need something that if not, you're gonna just keep doing work that is not measurable or not shippable. You need something to hold even the implementation team or the consultants accountable for. I know for us, we give you that checklist because we want you to be aware of some of the things you have to do as the customer.
speaker-1 (29:51.502)
That's an interesting perspective that you have, Elay, because from my perspective, I feel like a lot of that ownership falls on the business side. And I think of it as ServiceNow IRM is a product, is an application, right? But the underlying understanding is that you've built for your organization or have an understanding of what integrated risk management strategy is, and that is what you want, and that's what you're working towards.
I would blame the organization because like Elaine mentioned earlier, they're the ones that need to set their goals. What am I doing with IRM and why? If they can't figure out that question before the SOW, that's wasted money. Like companies lose millions without proper planning and understanding and preparation. If your org is not ready for that level of risk management, learn how to get there before you purchase the tool.
speaker-2 (30:50.134)
I'm underestimating how much discipline IRM actually needs.
speaker-0 (30:54.068)
IRM needs a lot of discipline. It's not an underestimate or estimate. If you're you need discipline in general with IRM. Either you're a mature customer or not, you need discipline. And you need alignment and you need organizational strategy like Jada mentioned.
speaker-2 (31:09.496)
Jeder Planning word is the implementation. Can you summarise that in one takeaway?
speaker-1 (31:16.562)
I think the biggest takeaway is if you're at the point of deciding, should I purchase an IRM tool, take an assessment of your current processes. Do they align with what an integrated risk management strategy looks like? Meaning, are you working in silos or are your control, your internal control library developed and traceability is aligned to those regulatory requirements that you have?
Or you've already started the process to automating your controls and need a source of truth for your data to go to and read how the risk looks across your org. Do a real assessment. And if all of that seems strange or is non-existent in your org, then you're not ready. Don't worry about the tool. Understand how to get to an integrated risk management strategy first, whether that's through spreadsheets.
ShareDrive, whatever the tools it takes, you need to break down those silos. You need to work towards automating. You need to understand how your organization is meeting regulatory requirements, then transition into a tool to manage all of that. I think that is the key point that I would want to leave with our listeners if they were trying to make a decision this week.
speaker-2 (32:38.85)
Thank you for that. And Elay, what's the one thing you want people to remember about readiness?
speaker-0 (32:44.698)
I would say from a readiness standpoint, before if you've seen all the beautiful things about IRM in service now, it can do it. But just make sure that your organization has a strategy and is ready to do the work as well, right? Alongside your implementers. That being said, make sure that you're actually purchasing the right tool for the number of
Teams that you have, right? So if you know that you're a small team of GRC practitioners within your organization, think about how do I want the experiences of those practitioners to be. And then my end users who are the owners of those controls or applications that are trying to attest for compliance or assess for risk, think about what should their experience be. Because when you start implementing service now.
You have to also keep in mind the people who will end up using it. And if you're implementing with a partner, ensure that they give you a checklist. What do you need from me as an organization to ensure success? Yeah. Just because you have the platform does not mean we should go crazy on it. Sometimes I would ask customers, take the platform out of the picture. How does your process look today? And what does the future look like for you? Yeah. So think about it before you start implementing.
speaker-2 (34:00.802)
Yeah. So to finish you off there, Elay. So now create. From if I went and I had a now create, I can literally run my IRM and my processes just by downloading now create and starting from there. Or is it a
speaker-0 (34:15.982)
Now create, think about it, it's a template. Keep in mind now create is showing you what does out of the box look and feel like. Now create is a template that helps you jumpstart. Okay. So keeping in mind that with now create, it is a starting point for you. There's a lot of information on Now Create, even how to do integration. It is on Now Create, but I've seen where there's nuances that is not there listed.
It tells you what you need. Now, does it tell you how to map everything together when you get all that information? No. It just it doesn't, but it tells you what you need. It's not gonna tell you everything because it's again, it's a starter.
speaker-2 (34:55.297)
Thank you so much, lady.
speaker-0 (34:56.686)
Thank you.
speaker-1 (34:58.094)
Thank you, Mish, for keeping us on track. Okay. All righty. So now that we've had this thorough discussion on implementation for the IRM application, now there's also issues. Everything's not perfect. There are scope creep that was mentioned. There's roadblocks that happen. But I think that's something we should also touch on in our next episode, Ela, is just because we have a plan.
doesn't mean the plan will always go accordingly. So thanks for talking with us. Until next time, I'm Jada. And I'm Ela. And let's keep making sense of IRM.
speaker-0 (35:40.32)
One conversation at a time.
speaker-1 (35:42.988)
Let's Talk IRM is a Sassy Boutique podcast. If you're looking to go deeper on how to implement IRM as a strategy and as a ServiceNow application, we're building something for you. Head to thesyboutique.com to join the wait list and be the first to know when it drops. Connect with me on LinkedIn to keep the conversation going and follow the show so you don't miss what's next. Links are in the show notes.
But until then, my friends, let's keep making sense of IRM one conversation at a time.