GRC - Lessons Learnt From Failure

GRC Tooling - Lessons learnt from failure
ISF - UK Spring Conference 2020
Matt Davies - Product Marketing Director at SureCloud

Agenda
• Why would you be considering tooling?
• How to reduce the risk of failure?
• GRC failures and how to avoid them
• Lessons learnt when implementing GRC
Stand 6

3
Why would you be considering tooling?
 Processes are fragmented:
The tools/processes already in use by your teams are fragmented and
different in each area and location.
So why is this a bad thing?
All the information sharing, lessons learnt, and insights aren’t shared
from location, function or risk disciplines
This often means the at data produced for decision making is
inaccurate as its not comparable and up to date
www.surecloud.com © 2020 SureCloud. All rights reserved.Stand 6

4
 Processes are fragmented
 Using a combination of tools e.g. Excel, PowerPoint etc:
Your current risk and compliance processes are ran using a
combination of tools (Spreadsheets, Word Processors and
Collaboration tools)
So why can this clause issues?
Multiple stakeholders change and make updates to key document
and its often difficult to track updates and maintain data integrity
Other than by email it’s very hard to evidence the review and sign off
is of key assessment or document
Tracking remediations and exceptions is very hard to keep on top of.

5
 Processes are fragmented
 Using a combination of tools e.g. Excel, PowerPoint etc
 Require a lot of manual effort to operate:
Your processes require a large amount of manual effort to
operate
So what are some of the things you may be starting to notice in
your organisation?
Reporting is very difficult as it requires people to bring together
multiple data sources which may require manipulation as they
aren’t in the same format or using the same methodology
Often there are duplicate efforts as people are unable to see and
reuse data from the wider business.
So why is this so important its worth understanding that these are
the common things that tooling will try and resolve but it’s not a
given that it will automatically do that.

6
How to reduce the risk of failure?
 What will the system be doing?
So, let’s look at how you can reduce the risk of failure? So, taking into the account
the point raised previously
I am going to walk you through a set of questions you should consider to fully
understand what you want out of the solution.
• What will the system be doing?
Will you be letting the business access the tool? Or is it a central reporting tool?
• What is the scope of the solution?
Is it a risk solutions will it be used for IT, compliance, third party, Internal Audit etc
As its worth understanding the scalability and scope upfront as you don’t want to
invest and end up needing a new tool in a few years.
Single vs Multi Use Case
- Single start 90%

7
 What information will be shared and reused?
• What information from the tool can be shared and reused?
How do you want to use data e.g. central repositories of risk and
controls or do you want each team to create their own data?
Will each of the risk domains share information e.g. a compliance
breach or incidents links into risks and controls to effect ratings?

8
 What additional information will you need?
• What additional information will you need to support your Risk and
Compliance initiative?
So for your assessment what context do you want to use?
• IT Assets
• Business Processes
• Org Structure / legal entities / geo locations
• Products and services
• Policies
• Regulations etc
Is all of the information already updated and ready to be put into a tool? Or does
the data need to be reviewed and updated prior to been put in the tool?
How much of the data is needed on day one?

9
 What part of the process will the tool be supporting?
• How much of your current process will the tool be supporting?
If your moving to a tool for the first time do you want to move everything into a tool?
Do you want to replace human interactions with a system?

10
 What processes will the tool be supporting?
 What reporting is needed?
• What is the Reporting that the tool needs to support?
Work backwards ensure that all the information needed for reporting is in
the tool?
Do you want to produce all your reports out of the tool? Or do you want to
manipulate the data outside the tool?

11
 What processes will the tool be supporting?
 What reporting is needed?
 What support and embedding is needed?
• What support and embedding is needed?
- Post go live who is going to support the system?
- Who is going to embed this into the business?
- Training
- Etc

12
GRC failures and how to avoid them
 Insufficient flexibility and technology driven
So, let’s move on to the common pitfalls and failures and then how you
can overcome and avoid them.
• Insufficient flexibility for your organisation and the design
decisions are technology driven
Example – of this:
Client reviewed a GRC solution loved the look and feel then realised
during implementation it couldn’t support their current workflow for
RCSA’s
Resolution
Focus on the flexibility of the tool
Ensure the tool is right for you don’t like the technology limit your
design decision
Ensure its agile and flexible as the ever changing business environment
likely means you will need to make changes

13
 We didn’t get what we thought we were getting:
Lack of clarify around the outcomes and requirements of your organisation
Example:
We visited a client to do a system review and they said we didn’t get what we asked
for the in RFP. When we reviewed the requirements, they were too high level e.g.
• Ability to document a risk
• Ability to assess a risk
• Etc
Resolutions
Ensure you have a clear understanding of what you want to achieve
If you need to implement something quick make sure the solution is aligned to
industry best practices;
COSO, ISO 27001, 31000, IRAM etc
Ensure you have a clear understanding of the reporting an outputs of the tool.

14
 We didn’t get what we thought we were getting
 Implementations teams has limited GRC
knowledge:
• Implementations teams have little risk and
compliance knowledge
GRC tools aren’t like normal technology implementations
You often require people with the business context and IT
background
As people focus on technology rather than the business
outcomes you desire.

15
 Implementations teams has limited GRC knowledge
 Incorrect modules were positioned:
• Incorrect modules were positioned for your requirements
Often people end up buying too many modules and show little or no
progress
The modules position were by someone who didn’t understand risk
management

16
 Incorrect modules were positioned
 The solutions is too complex and we can’t use it:
• The solutions we implemented is too complex and we can’t use it
Example - Client built a 14 step loss workflow 12 months after deploying it and
getting push back from multiple teams saying it was unusable they had to
rebuild the whole thing
Resolutions
Start simple you can always make it more complex
Ensure you have extended testing people forget to understand the usability of
the tool.
I had a client who created a 9 step processes for loss events and 7 for
compliance breaches . After 12 month they asked us to simplify this after
spending a substantial amount of money.

17
 Incorrect modules were positioned
 The solutions is too complex and we can’t use it
 We can’t get the business to use the system:
• We can’t get the business to use the system
- People always forget to focus on Embedding the tool into the system
- Implementing the tool is only half the battle
- Need to ensure you get users involved and begin to embed the system
and process in the system
- Training
- Link to job titles
- Champions

18
Lessons learnt when implementing GRC
 Clearly understand your requirements, objectives and outcomes
upfront
 Start simple and develop the solution over time
 Give yourself the adequate time to test and review the solution
 Focus on improving outputs as part of the design
 Budget for embedding and support for the system
See more about SureCloud’s
GRC tools here.

19
Carry on the conversation...
www.surecloud.com © 2020 SureCloud. All rights reserved.
Visit Stand #6 at ISF Spring 2020
Get in touch
- @surecloud
matthew.davies@surecloud.com
Stand 6
Matthew Davies - Product Marketing Director at SureCloud
Experience at PwC and Deloitte implementing multiple GRC
tools: RSA Archer, ServiceNow, Bwise, OpenPages, Aris GRC

GRC - Lessons Learnt From Failure

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

GRC - Lessons Learnt From Failure