Before the upgrade: ServiceNow IRM

What is Let's Talk IRM?

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.

Jada: 00:00

What's good, ERMI's crew? I'm Jada, and this is Let's Talk IRM. I get it. Integrated risk management is hard culturally and technically, But this is where we bridge the gap between culture and tooling one conversation at a time. Let's get into it.

Jada: 00:22

What's good, IRM's crew? Now as we all know, Australia release for ServiceNow is dropping soon. And I'm not gonna lie, there are some pretty cool features that I'm genuinely excited about, such as the new control objective workflow. There's the improvements to the smart assessment engines that's kind of small, but still, it's real upgrade changes that helps the workflow and even the process of defaulting users to workspace rather than the classic view. Nonetheless, though, I've been on LinkedIn and I can see the same energy across the ServiceNow Community.

Jada: 01:05

I see the MVPs, the partners, the product teams, ServiceNow leaders. They're all excited, and I'm excited with them. But I keep coming back to a question in my mind of a group that I'm not really seeing sharing the same excitement as ServiceNow practitioners, and that's the business. So I'm wondering, does the business actually know that any of this is coming? Do they know what it means when we're talking about the Australia release?

Jada: 01:38

Have we even walked our compliance leads or risk owners or auditors through what's about to shift potentially to their workflows once upgrade happens? Because some of these changes, while they are optional, some are not. And the ones that aren't can still affect the business. Either way, the business is going to feel that energy change when Australia comes out, when the product team tells them, hey. This is new.

Jada: 02:10

We're rolling this out, but they didn't know about it beforehand. So today, we're gonna get into that. We're gonna talk about whether we should be prepping our business counterparts that use the IRM application and what does that conversation look like. So let's get into it. Alright.

Jada: 02:31

So as I said in my intro, we're pretty excited for the Australia release to come, and it's pretty great. It's pretty strong. I mean, starting with the control objective change management flow, right? That feature introduces a structured life cycle for managing control objective records, which means that we can have major or minor changes and that can affect whether or not we want to affect the downstream controls from those control objectives. That's big.

Jada: 03:03

Further, the other cool feature that I mentioned is the smart assessment engine improvement. Now that seat may seem small where we're adding that delegation feature, but it can be pretty impactful being able to delegate and edit and highlight and make minor changes to an attestation before submitting it. That's different from the current smart assessment engine process. Lastly, the feature change regarding defaulting to workspace view, that's gonna be pretty hot in my opinion. So whenever users get an IRM related notification, the link that they click instead of going to that classic view takes them to the workspace view.

Jada: 03:48

Now, I think that's pretty great because I have always been a strong proponent of using workspace. That's the direction ServiceNow is going. And there's features within workspace that you get and can use that you can't get in classic view. Now while all of this is exciting and I love it as well, I know that implementation teams are developing their release notes. They're putting together their rollback plans.

Jada: 04:18

We're basically preparing for their upgrade. Right? But I wonder if any of those implementers or practitioners or those leaders of those technology teams are wondering, should we be having the same type of conversations and walk leadership on the business side through what's actually changing? From my experience working on the business side, I was never part of those conversations. All I knew was, hey.

Jada: 04:49

We're upgrading. It's gonna happen over the weekend. If you notice anything different, come Monday, submit an issue ticket. Right? That was pretty much it.

Jada: 05:00

But now that I'm on the practitioner side of ServiceNow, I see the heavy lift that happens when an upgrade happens, but I'm also still seeing the gaps of informing the business of what this upgrade mean, how that affects their workflows, how they should accept the optional changes or the changes that aren't optional because of what they've already enabled. Now, when we think about ITSM, right, that is normally used by IT users submitting tickets. Right? So when upgrades happen, they're already in the flow regarding upgrades and how that can change. But when we're talking about a product that is very business heavy, such as IRM and the features that it touches, the business relationships, the risk owners, the control owners, attestation reviewers, leadership.

Jada: 06:00

When the behavior changes because of an upgrade, their program actually changes. And if they are not prepared, that could cause compliance gaps. It could cause confusion on their user side of why is it that this workflow that I'm working on now is not working or why am I being forced to go to workspace? I've never used it. So those kind of quirky things are gonna come up.

Jada: 06:29

And it's important that while the technology teams are preparing for this upgrade, it's also important that we're taking the time to walk the business through changes, get their input, understand how the impact is going to affect them, and create an upgrade plan for them as well. Alright, y'all. There's the optional features that are property toggled that don't activate unless an admin enables it or installs it through a specific plugin. The business doesn't feel them until you decide to turn them on, which that usually happens in a discussion. Those changes aren't really what I'm worried about.

Jada: 07:13

Right? But then there's the behavior where the release have required changes that are baked into the upgrade when you go into Australia, and that new behavior is where anyone briefed in the business or not is going to feel it. So how do we navigate that? Right? How do we help them understand?

Jada: 07:33

Well, of course, that's the technology team first going through the release notes as usual, understanding their environment on what are those optional changes and what are gonna be those required changes that are gonna happen that's going to affect the business. And so in my opinion, I would highly start with the required changes because that means the business doesn't really have a set a choice and whether or not they want that new change to happen. As the upgrade is rolled out, that change happens. So for example, a business that has decided to enable their smart assessment engine, right, to do their attestations, to do their third party response, or do their risk assessments. Right?

Jada: 08:21

They're used to that flow by now. But in the Australia release, the behavior change that granular delegation less assessment owners assign specific sections to subject matter experts while retaining full ownership and submission control. And, of course, there is a full audit trail. Additionally, if you're on the business side, the assessment owners will find that they can actually edit the templates in ways that they couldn't before, including ways that affect in process assessments. Both groups need to understand the new behavior.

Jada: 09:01

Right? So this would be a discussion that we would need to have with the business. We would need to let them understand that, hey, because we have smart assessment engine enabled, this granular delegation and quick edit feature is going to be added in. And this is what it looks like and this is what it needs. This gives the business a voice to talk about how this is going to affect their process, how they need to update their procedures or their policies or standards in relation to how they conduct their assessments or attestation, but gives them that head up that, hey, we need to start putting a game plan in for when that change rolls out, that we are already ready to operate in lines of what our requirements are.

Jada: 09:49

So once we discuss the required changes that are gonna happen at the release, there are the optional changes that we can then share with the business because then they have a decision on whether or not we want to roll them out. So, for example, the control objective workflow is optional, which means that you're going to have to navigate to the policy and compliance administration section, select properties and enable it post upgrade. And then additionally, approval rules don't ship out the box. They have to be configured as well. So with this optional update, we need to discuss with the business if this is something they need.

Jada: 10:33

If they don't even understand the point of it, it's our place as practitioners and implementers to explain to them what the control objective workflow is and does. Now if the business says, yes, that sounds great, we also need to understand there are still some governing factors that need to be put in place before this feature becomes enabled. So here's the scenario. A compliance organization is three months into their annual SOC attestation cycle. The control objectives that they've been using have been finalized.

Jada: 11:11

Reviewers are at mid attestation. Audit is reviewing the evidence as they come in. Admit cycle, the platform team upgrades to Australia. Right? Some point in that conversation, it was decided that, yes, we're gonna enable control objective workflow.

Jada: 11:31

Well, the compliance team working on the annual SOC attestation cycle didn't know it was coming. So while they're working on SOCs, a different compliance manager related to a different regulatory group decides, okay. Well, this control objective is something that we're ready to make a change to. Now to them, they decide on their own that it's just a small clarification change to a control objective, whatever that meant to them. Right?

Jada: 12:05

The new workflow asked them to classify it as major or minor and a and route for approval. Well, they don't have approval rules configured. They don't know what major means in this contact, and so the edit gets stuck. Right? Now meanwhile, as the audit team for SOX is going through the organization's control objectives, they're wondering why it's saying that we're in edit status for this control objective, but this is supposed to be the control objective that flows down to our SOX entities.

Jada: 12:40

Now that leaves the business having to explain to them of a new upgrade change. Now I wanted to bring that scenario up because just because the business decides to enable an optional upgrade change to a process, it doesn't mean that everyone within the business is on board. When it comes to control objectives, it's very important that leaders that are part of the different regulatory groups are part of that decisioning. So you have the SOX PMOs, you have the HITRUST PMOs, you have the CMMC regulators, or you have the ISO 27,001 auditors, right? Each leaders from those groups need to be a part of the decision making when it comes to making optional changes live because those changes still affect them in a different way.

Jada: 13:36

And in the same fashion, governance around what is major and what is minor is also something that needs to be considered because everyone has their own definition of what's considered a major change and what's considered a minor change. So having that taxonomy defined before an upgrade is also important. So when we acknowledge the business and saying that, yes, they do want this optional upgrade, we also need to be able to share that, hey. This needs to be a part of your upgrade plan then if this is going to be in place. We don't want the organization to find itself failing a compliance assessment because of the lack of preparation on the business side.

Jada: 14:20

So as we're preparing for our release to Australia, let's try to make this more of a collaborative refrain. We have the technology teams and we have the business stakeholders come together to discuss what the release means. This is where the optional versus required distinction becomes a collaborative conversation and not a unilateral decision. For example, optional features the business doesn't want, that's an easy case. You document that conversation, you capture the business justification for not wanting it, and you don't turn it on.

Jada: 14:58

Maybe later, maybe never, but the point is is the platform flexes around the program and there's no disruptions. For the required changes, the conversation is different. The change is happening. The business doesn't get to opt out, but the business absolutely gets to be a part of the conversation about how to absorb the change. Before the upgrade, walk them through what's changing, what it means for their workflows, what evidence trails will look like differently, what questions they need answer.

Jada: 15:35

After the upgrade, validate that what you briefed them on is what they're actually experiencing and adjust documentation, training, and procedures to match that as a part of their go live plan. Collaboration before and after should be the practice. The business getting blindsided by a required change is a practitioner failure. The practitioner unilaterally deciding the business is quote unquote not ready for an optional feature without their input is also a practitioner failure. The middle path is to have that conversation and documented so we're clear on what does the business want, what does the business need, and we don't have to make that decision alone as practitioners or cause confusion.

Jada: 16:25

So as you're pulling up the Australia release notes and trying to come up with meaningful changes for your IRM stack, I have four questions that you can ponder about. And if you can't answer all four with confidence, that is where your prep work lives, not in the platform, but in the conversation with the business that uses the affected app. The release isn't real until the business has absorbed what's changed, and it's our job as practitioners to make sure they have the chance to. So the first question, does the business use this feature that is about to change? This one is simple.

Jada: 17:12

We should know that the business is using this feature or not. Question two, does the business know our required changes are going to affect them and if they have an operational plan in place to minimize business issues? And when I say this, I'm not talking about is it documented in the release notes. I'm referring to actually know in their mind and in their mouths when they speak about this release that this is coming and this is what we've put in place from the business perspective. Question three, do they truly know what the change means to their workflows?

Jada: 17:54

And not just the feature description, but the workflow change. What's different in their day after go live? This is where we show existing workflow in our test environment, then we show the new changes in the PDI and this gives a visual in the context to how does my workflow change from this update. And lastly, question four. Do they even want the changes?

Jada: 18:25

For optional features, that question has real weight. But for the required changes, the question becomes how do we collaborate on absorbing them well together? But the business input still matters. At the end of the day, we wanna make this a collaborative release process. So bringing in the business, understanding from their perspective, and also sharing the practitioners' perspectives gives us that collaborative reframe that we're looking when it comes to future upgrades, the Australia upgrades, any upgrades when it comes to working with the business as partners.

Jada: 19:05

So now on that final note, later this month, we do plan to drop another episode, and we're gonna get deep into implementation planning, the work that makes any of this actually land. I hope you enjoyed this episode, and I'll see you in our next one. Until then, let's talk later. 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.

Jada: 19:40

Head to the sassyboutique.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.