5 critical components to a smooth IRM/GRC implementation

Criticalstepstoimplementing anIRMorGRCsolution

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

Buildingastrongstakeholdergroup

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.

Gettingtheright stakeholderstothetable

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

Potentialpitfalls

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.

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.

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

H A P T E R Requirements

Creatingyourrequirementslist: 35mission-criticalquestionsforyourstakeholders

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

Businessresiliency&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?

Auditmanagement

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?

ITsecurity&riskmanagement

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&compliancemanagement

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&operationalriskmanagement

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?

Publicsector

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.

Scoping

Bestpracticesforfiguring outyourprojectscope

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

Whatisprojectscoping?

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

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

Identifythegoals&objectivesoftheproject

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?

Pentheprojectscope 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

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.

2 TYPES OF REQUIREMENTS

Identifyrestraints, 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.

KARTAASCEND:HELPINGYOUTRAVERSERISK

KartaAscendistheformulaweusetoconsistentlydeliverwell-designed solutionsontimeandonbudget.It'showwe'veearnedandsustainedastellar reputationforourwork.

Useradoption

Howtomaximizeuseradoptionofyournew integratedriskmanagementsoftware

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

Changemanagement

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

Stakeholderbuy-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

Platformselection

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

Trainingusers

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.

Userguidelines

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.

plan

A to Z GUIDE TO IRM

Devisinganimplementationplan

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

Whyanimplementation planiscritical

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

Componentsoftheplan

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

BUSINESS REQUIREMENTS

Business area, division, etc

Service time – global time zones if you work across borders

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

The scope of work

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

Business tasks and changes

Rollback implications

Dependencies

TECHNICAL COMPONENTS

Vendor-by-vendor checklist if multiple integrations are involved

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

IMPLEMENTATION SCHEDULE

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

A timeline of the activities

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

Checkpoints

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

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

CHECKPOINTS

Communication of real-time task progress and problems for transparency

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

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