5 critical components to a smooth IRM/GRC implementation

INTEGRATED RISK MANAGEMENT

GUIDE

5 critical components to a smooth IRM/GRC implementation

kartacorp.com

Critical steps to implementing an IRM or GRC solution Having a well-designed Integrated Risk Management (IRM) or Governance Risk Compliance (GRC) system has big benefits for organizations of all sizes. Even if you don't have one, you likely know the purpose: a repeatable, automated system of checks and balances that decreases an organization's risk exposure. Of course, there are other benefits, too, like eliminating the duplication of work and increasing transparency and accountability.

Software selection demands careful consideration; however, equally⁠—if not more⁠ important—is customizing said software to your unique needs and processes. Not to mention planning for user adoption.

There's a lot to know when investing in an IRM/GRC solution, so we've developed this guide to familiarize you with the implementation process. We hope to save you from making costly errors. And help you have the smoothest implementation possible.

Content 01 Building a strong stakeholder group

02 Creating your requirements list

03 Accurately scoping the project

04 Planning ahead for successful user adoption

05 Devising an implementation plan

1

C H A P T E R

Stakeholders

Building a strong stakeholder group

In theory, building a stakeholder group for your IRM/GRC solution deployment is simple.

And yet many companies get it wrong. The result: a longer, inefficient and frustrating process; in some cases, leading to a failed deployment.

Having implemented these solutions for over two decades, we’ve seen how impactful a well-curated stakeholder group is. But there's more to setting up your stakeholder group than simply finding the right people.

Establishing roles and expectations, and getting early executive buy-in are also critical to success. Let's examine each one of these.

Getting the right stakeholders to the table Your IRM/GRC solution will very likely be used by two or more functional areas, so your project team should include one person from each area. The decision of who should represent each function should not be taken lightly. Selecting the right person is massively important as it directly impacts the quality of the outcome, as well as the journey there.

Take these three factors into account as part of your stakeholder selection process to

ensure you have the best people at the table: KNOWLEDGE Look for people who have these two areas of knowledge: one, technical knowledge where they know the work processes within the function that will need to be built into the IRM solution; and, two, a thorough understanding of how their department is going to be transformed through the automation. Typically, they are end users or “hands-on” managers of end users. A lack of knowledge in a stakeholder can lead to a system with gaps.

DECISION-MAKING POWER Stakeholders must have the authority to make decisions on behalf of the department.

They should also hold the trust of their manager and team to avoid second-guessing and backtracking. A lack of decision-making power can eat up time and increase the project cost.

BANDWIDTH Ensure they have the bandwidth. The best way we’ve seen this done is by building a project estimate that dissects every phase and estimates each stakeholder’s role and time commitment. Beware of stakeholders deferring to someone else because they

don’t have time. This leaves a lot of room for diluted accuracy.

The organizations we’ve worked with that had strong stakeholder groups got there by having each department conduct interviews to select their representative in the group.

This approach has proven to be an effective way of finding people who are interested, who have the knowledge and also the bandwidth.

Another piece of advice we can offer is to keep your stakeholder group small; ideally one person per department. You’ll also need one project sponsor or coordinator. This person would be responsible for coordinating the project internally and being the primary liaison with your vendor.

EXECUTIVE BUY-IN Executives must participate in the deployment of the solution, too. They shape the highest-level milestones and deliverables for the project, and their vision shapes the final outcome. Ensure the executives involved have the bandwidth to contribute significantly.

At the executive level, ensure your project has more than one executive sponsor in case of turnover. Deriving all the benefits of the new IRM/GRC solution requires your executive leaders to collaborate and coordinate.

Potential pitfalls ANTAGONISTS The IRM/GRC solution you’re developing may make some people feel vulnerable because it might automate or modify part of their work. Some jobs may even get eliminated. Be aware of this and watch for stakeholders who are antagonists (someone losing power, resources or their job) as a result of the project.

TURNOVER Turnover within your stakeholder group or of someone who oversees the stakeholder may happen. The risk is the turnover can lead to a change in requirements. A best practice to mitigate this risk is to record the hierarchy of the requirements and from whom they came, to enable continuity if there are staffing changes.

Ensure they understand the value of the project since the project cannot succeed without executive support.

Define how the project will benefit the business in terms of that person’s responsibility. For example, is their primary function financial management or risk management?

How will it contribute to meeting their goals? Will it create a financial gain or free-up resources?

2

C H A P T E R

Requirements

Creating your requirements list: 35 mission-critical questions for your stakeholders

Once your stakeholder group has been formed, your next step is to have each stakeholder submit their requirements and anticipated outcomes. This is crucial for a smooth deployment.

When you compile them, you’ll have a document that captures the needs and wishes of each department that has a stake in the solution. This document is like a multitool; it can be used for the project scope of work, establishing roles, and reporting.

To help you develop your requirements and outcomes document, here are 35 questions to ask your stakeholder group. The questions are organized by disciplines that are typically involved in an IRM/GRC solution deployment. Modify the list to suit your organization.

Business resiliency & continuity What types of documents will you incorporate into the new risk management solution?

Will a formal content review process be implemented?

What notifications need to be set up?

Will business continuity planning and disaster recovery testing or a crisis event process be implemented?

Which reports would you like incorporated into your business continuity management solution?

Audit management Would you like to track project time sheets and expenses for your audit staff?

Which audit procedures and reports will be imported into your risk management solution?

Would you like to incorporate an exception request workflow to for non-remediated findings?

Do your audit project managers complete a quality assurance review checklist prior to closing each project? If not, would you benefit from one?

Do your audit project managers complete an audit customer survey prior to closing each project? If not, would a checklist be useful?

IT security & risk management How many risk questionnaires would you like to implement in the solution?

Are your questions pre-mapped to any industry regulations or best practices?

Would you like to incorporate an exception request workflow to for non-remediated findings?

Would you like to perform annual or quarterly risk reviews against each risk scenario

What reports would you like incorporated into your risk management solution?

Policy & compliance management Is your control testing process specific to SOX or more of an integrated control testing process?

How many control procedures will be imported? Do these need to be mapped to your internal standards, policies, or external regulations?

What is your current control testing process?

Would you like to incorporate an exception request workflow for non-remediated findings?

Would you like to include a SOX 302 certification process?

What types of documents will you incorporate into your IRM policy management solution?

What type of policies will be implemented?

Will a formal content review process be implemented? What is the workflow?

Are there additional authoritative sources that need to be included outside of Archer’s out-of-box content library?

What reports would you like incorporated into your policy management solution?

Enterprise & operational risk management What assets (e.g., organizational chart, facilities, applications, business processes) need to be included in the enterprise management solution that will need to be referenced by other solution areas? How are these assets stored and tracked today?

Which assets are managed in a change management database (CMDB)?

Would you like to keep the assets synchronized in your IRM solution? If yes, how can this data be extracted from your CMDB?

Do you want to incorporate a risk/threat/compliance scoring methodology across the entire asset hierarchy?

What reports would you like incorporated into your enterprise management solution?

Public sector

What types of documents will you incorporate into your IRM/GRC solution?

What type of policies will be implemented?

Are there additional authoritative sources that need to be included outside of the out-ofbox content library?

Will a formal content review process be implemented? What is the workflow process?

Do you have documented corporate objectives that should be migrated?

These questions will likely spark others, which is great. It’s worth investing time in this exercise because it can save you from time-consuming, costly backtracking and scope creep later in the project.

In your document, be sure to record the name of the author/stakeholder of each requirement and the anticipated outcome. This will ensure consistency should there be a turnover of any stakeholders or executives.

3

C H A P T E R

Scoping

Best practices for figuring out your project scope

Over the years, we’ve worked with many companies re-attempting their IRM solution after a failed design by another vendor. This has reinforced to our team that the outcome of our projects is only as good as the accuracy of the project scope and planning.

Rushing this work can be an extraordinarily costly mistake, not to mention the added challenge of getting users on board again.

There is a way to bounce back—but let's discuss how to get it right the first time.

Scoping delves into the customization and end-project required to ensure all stakeholders understand what needs to be delivered. IRM solutions are unique to each company. Yours will share the same software platform that’s used by other organizations, but it is the customization to suit your unique workflows and processes that will make it work really well.

Next, let’s go over the elements of project scoping, and best practices for determining these business requirements.

What is project scoping?

First, let's cover what scoping is. Simply put, it means defining what your organization wants to achieve with the project. This likely includes specific activities and deliverables from the project, who will benefit from the

results of the project, how you will measure success in the end and verify and/or validate the output, and more.

Identify the project needs–your what & why Documenting the "what and why" of a project may seem unnecessary, but in our experience, they are critical. Why? They are essential for making a strong business case for the project.

They can help keep the project on track if new stakeholders enter mid-way through.

They also set the groundwork for tasks to follow.

You’ll need to ensure the outcome aligns with the what and why, while also satisfying end-users' expectations, timeframe and budget.

Identify the goals & objectives of the project As you work to define the project scope, it’s helpful to follow the SMART principle as follows.

SPECIFIC Specificity means accurately stating what the project will help achieve. That is, what, why and how you will accomplish all tasks. The clarity in goals and objectives reduces the chances of ambiguities and misunderstandings, lowering the risk of failure.

MEASURABLE Are your goals and objectives measurable enough to elicit feedback, facilitate tracking and ensure accountability? What we measure, we can improve.

ACHIEVABLE Realistically, can your project’s objectives be achieved, given the resources on hand? Don’t set yourselves up for failure by setting unrealistic expectations of your team and project without investing enough into them.

REALISTIC Are the goals and objectives within reach? Be considerate of potential complications you might be up against. Will any slight hurdle (often inevitable) reduce the overall quality of the project’s outcome and/or cause overspending and stretching the set deadlines?

TIMEFRAME Can you meet your project goals and objectives within the allocated timeframe? Is it a critical requirement to meet these deadlines?

Pen the project scope description A fulsome project scope includes both functional and non-functional requirements.

Be sure to clearly define both types of requirements. These are the bedrock upon which you'll build subsequent features of a product or service.

2 TYPES OF REQUIREMENTS Functional requirements are capabilities that the product/ service must exhibit for the project to be successful for end users, including user expectations and acceptance criteria.

Non-functional requirements address qualitative needs that are implicit and technical; for example, performance, scalability, availability and reliability.

Identify restraints, assumptions & risks Roadblocks are a fateful reality for complex projects like these. We can minimize their impact by identifying the potential hurdles upfront. Whether these hurdles are rooted in assumption or uncertainty, looking out for them throughout the duration of the project further reduces your risk of failure.

This said, sometimes change is inevitable and necessary. If it happens during your project, we strongly advise avoiding rework of the project scope. We say this because doing so will eat up more time, money and resources.

Instead, where possible, address the perspectives of customers, stakeholders, and employees involved in the project. Be sure to document assumptions and risks as they will minimize disagreements and misunderstandings, should you introduce change later on.

KARTA ASCEND: HELPING YOU TRAVERSE RISK Karta Ascend is the formula we use to consistently deliver well-designed solutions on time and on budget. It's how we've earned and sustained a stellar reputation for our work.

4

C H A P T E R

User adoption

How to maximize user adoption of your new integrated risk management software

In 2021 at the Tokyo Olympics, just before crossing the finish line, American Isaiah Jewett and Botswana’s Nijel Amos became entangled and fell. They’d put so much into making the podium only to stop a few meters short. We’re no Olympic athletes, but those of us who are part of deploying an IRM/GRC solution can fall victim to a similarly tragic fate: spending months planning, developing and launching a solution only to have it stumble and fall when the users don't adopt it. This fatality is not uncommon, which is why we say it's critical to bake user adoption into your planning.

Change management People struggle with change. It's a fact. This is why change management has become common practice. Simply put, change management means taking a structured approach to introducing a change. And it starts on day one with planning how you’ll present the project.

The crux of it is understanding end users’ reservations and motivations and taking their input and feedback seriously.

Clear, proactive communication helps a lot.

This includes communicating the "what" of the implementation and the why behind it.

Repetition is key to this: the goal is to have it “stick” in people’s minds. When your stakeholders share the same vision, goals and strategy, success is far more likely.

Having a good IRM/GRC solution in place is essential for working efficiently, protecting your environment, customers and reputation, and avoiding fines. But you must pay equal attention to adoption. Read on for tried-andtrue ways to win in the user adoption game.

Stakeholder buy-in Let’s delve deeper into stakeholders. Who are they? Everyone whose buy-in matters— from senior leaders who could kaibosh the project part way in if they don’t understand the value of it—to the end users who will either use it or dig their heels in and do it “the old way”.

This is another reason why it's important to have one lead from each functional area.

They can solicit input from their team and play a role in the buy-in process right from the start.

Platform selection Of course, the solution itself will impact user adoption. No two platforms are alike, but

over the years, we’ve come to recognize that two features impact user adoption the most:

FLEXIBILITY The software should have the functionality and flexibility to mirror your existing (or desired) processes. The greater the magnitude of change, the more friction it creates. At Karta, when we develop an solution for a client, we spend hours and have workflows dedicated to customizing the solution in order to eliminate this friction.

USABILITY A platform that is intuitive to use and that makes the job easy is one that users will be likely to adopt because it flattens the learning curve. Ask your IRM partner about the interface and user adoption. Perhaps they can provide a reference from a past project who will share their firsthand experience with the interface.

At Karta, we run a usability check by building a test solution for users and getting their input on it before we deploy the full solution.

This step ensures we have understood the user requirements and properly built them into the IRM solution.

Training users Even the simplest of software requires user

training, so be sure to include mandatory training sessions in your implementation plan. Make them fun with humour, prizes and games. And record them for use when onboarding new employees in the future.

People are most willing and excited in the beginning of their job–so this is your greatest opportunity for success.

Find out what training and resources your IRM/GRC vendor will be providing. Is there live training, recorded sessions, or simply written documentation? Also, schedule follow-ups with users between sessions to ensure they’re applying what they’re learning and not experiencing any issues.

As with most digital adoption, expect a high uptake in the beginning with a fall-off after that as people revert to their old ways. To combat this phenomenon, hold occasional ongoing training sessions. Your new hires will benefit immensely from these.

When looking for your IRM/GRC vendor, be sure to ask if they provide e-learning or an online learning management system (LMS).

LMSs are great because they give unlimited access to content in one location, and track user progress.

User guidelines Here's a valuable mantra to share with your end users: Garbage in, garbage out. It's a big crass, but that's why it's memorable.

Knowing that poor data quality can tank your IRM/GRC solution is the first step to avoiding it.

We’ve seen companies get bogged down with bad data, which leads to incomplete reports, miscommunication and other frustrations. To avoid this pitfall, establish and document data requirements.

Your stakeholders can help to make this happen. Here's how: Assign a monitor who occasionally performs quality checks to make sure inputs are high-quality so that resulting analytics and insights are yielding, too. An ideal time to run these quality checks is just before team training so that the findings can be shared with the group.

Given the growing complexities in the regulatory environment, using an IRM/GRC solution as the backbone of your compliance effort is a no-brainer. A well-devised solution puts checks and balances in place to avoid human errors. However, implementing an IRM/GRC is a people-led process, so you also need to invest in user adoption, too. Look to your solution partner for guidance and support, and be sure to follow these best practices.

5

C H A P T E R

Implementation plan

A to Z GUIDE TO IRM

Devising an implementation plan

An implementation plan is like a well-devised travel itinerary in that it: Gives the starting point and schedule.

Lays down the entire journey with the checkpoints and maps.

Conveys alternate routes and destinations you might visit.

Your IRM/GRC implementation constitutes a big part of your total purchase so a very dangerous pitfall is going into the project without being clear about what will happen during implementation. A lack of insight here can mean misplaced expectations and treacherous bumps in the road.

While each vendor has a different process for implementation, some parts and best practices are critical to success. One of these is making it a collaborative effort by your business and IT teams so that your vendor can do their work swiftly.

When researching vendors, find out what's involved in their implementation phase (the phase that follows planning and configuration). This phase will be the final step before your team begins using the system.

Why an implementation plan is critical The implementation phase ends with delivering and deploying the configured software into your environment. This process should be guided by a detailed implementation plan, whether the project involves decommissioning an existing solution or deploying an IRM/GRC platform for the first time, so that: You are well-informed of, and prepared for, the business maintenance window.

The elements that deserve space in the plan, including the schedule, checkpoint meetings and rollback actions, are defined.

Your vendor has a ready list of the stakeholders, project resources, support resources, vendors, etc., for proper people and project management.

You’ve identified the impact of successful or unsuccessful implementation on your business processes and people’s roles.

Ultimately, it will save you from surprises and setbacks during the implementation phase.

Your role is that of an informer and

coordinator on the part of your company.

You’re responsible for providing details about your environment and provisioning access so that the implementation team can roll up their sleeves and set it up.

TECHNICAL COMPONENTS

Vendor-by-vendor checklist if multiple integrations are involved

Components of the plan The IRM/GRC implementation plan should include the following key components:

BUSINESS REQUIREMENTS

A technical task list of the expected changes in your environment, including the data integration

Business area, division, etc.

IMPLEMENTATION SCHEDULE Service time – global time zones if you work across borders

Expected disruption to business service times – avoid and account for operational downtime

A list of activities and milestones and the people/groups accountable for them

A timeline of the activities

The scope of work

Go/no-go decisions that teams will need to make on-the-fly

Business tasks and changes

Rollback implications

Dependencies

MAINTENANCE WINDOW REQUIREMENTS

A list of expected downtimes so business units that might be impacted proactively take steps to ensure system availability.

ROLLBACK PLAN

A plan of action to revert to a prior state in the event that something gets delayed or doesn’t go as expected.

A communication plan associated with the rollback event. The aim is to prevent surprises if something goes wrong.

A description of the trigger event;, Checkpoints ie. when to enact the rollback plan.

CHECKPOINTS

Communication of real-time task progress and problems for transparency

Checkpoints should create transparency that will help avoid delpays caused by escalated issue and reactive decision-making.

Creating an implementation plan aims to outline the what, when, where and who of the implementation, in addition to defining a plan of action in anomalous situations. It should remove the guesswork and eliminate surprises while ensuring you are prepared for success.

In addition to creating this plan, your vendor should manage the sequence of events inside the plan.

The implementation must happen one step at a time, in a controlled manner that allows for go/no go decisions to be made at each checkpoint.

Compliance is complex, but the implementation of your IRM/GRC solution can be straightforward given the right provider.

Now that you have an understanding of the stages of an IRM/GRC implementation, you are much better prepared to interview vendors and understand if their process is fulsome and likely to lead to a hiccup-free implementation experience.

kartacorp.com

V 230322