Transcript: GRC Technology Perspectives Around the Globe - United States

Hello. This is Kevin Donahue with Protiviti, welcoming you to a new edition of Powerful Insights. We are producing a series of podcasts on GRC programs and technologies, obtaining perspectives from Protiviti leaders and subject-matter experts around the world on GRC drivers, innovations and challenges in their marketsHello. This is Kevin Donahue with Protiviti, welcoming you to a new edition of Powerful Insights. We are producing a series of podcasts on GRC programs and technologies, obtaining perspectives from Protiviti leaders and subject-matter experts around the world on GRC drivers, innovations and challenges in their markets.

This episode features my conversation with Matthew Landers, an associate director with Protiviti based in Denver, who offers his viewpoints on GRC developments and advancements in the United States. Matt, thanks for joining me. Great to speak with you.

Thank you, Kevin. I appreciate the time and opportunity to talk to you.

Matt, to kick things off here, what are the GRC drivers you’re seeing in the marketplace right now?

Well, Kevin, from a U.S. perspective, we continue to see the traditional bread-and-butter GRC staples – your SOCs, your internal audit and your enterprise risk –continuing to be very, very common in basic needs from a GRC perspective. That said, we are seeing more and more in especially larger organisations – especially large financial organisations – focusing more on using GRC platforms for regulatory compliance and IT risk management activities.

The increase in those use cases for more deep regulatory compliance mapping and IT risk management actually works really well because as a GRC practice, we have the capability and the knowledge to stand up those platforms. We can also bring in and leverage our Protiviti subject-matter experts that work day-to-day in those areas of the business. Our regulatory mapping team, our IT risk management teams, they can help develop our client’s methodology and create a process and approach which we can then stand up in a GRC solution.

I think in summary, there are really two things that would push a client towards needing a GRC, or moving towards a GRC, solution, and one would be the size and complexity of that use case. For example, a small public company with two or three locations, they could probably complete their SOCs and internal audit requirements through brute force using things like SharePoint or the Microsoft suite of applications – Excel or Word. That said, they certainly would benefit from a GRC solution, but they may not need it. As a company gets bigger, multiple international locations, different GRC activities, audit, SOCs, IT risk management and things like that, there’s sort of a tipping point that they need to go to a GRC solution to get some of the efficiencies that they might be looking for where Excel and Word fall apart.

The other piece would be standardisation. From a multidisciplinary GRC effort, we often see clients that have various different stakeholders. We’re seeing players’ audit, SOCs, operational risk, IT risk, regulatory compliance and vendor management. A lot of times, they’re operating in silos and the organisation is looking to get a single view of risk and compliance activities across the organisation. One way to do that is to move towards implementing a GRC solution. It often gives them a way to align processes and methodologies and leverage data that each of the groups might be using.

That’s a great rundown. Thanks, Matt. It actually offers a good segue to my next question for you. What are the key tools that you are implementing in the U.S. market right now around GRC?

Yes. That’s a great question, Kevin. There’s a variety of tools that we’ve been working with in the Protiviti U.S. team. Our governance portal is one of the solutions, especially from a SOCs and audit perspective that we continue to use. We’re also working with Archer. RSA Archer is a very common tool, and we have a number of different teams implementing that. We’re also seeing Thomson Reuters. Their Riskonnect solution, rebranded recently, is another solution that we’re working with right now with a client.

One other one that has been becoming more and more popular is ServiceNow, traditionally an IT ticketing system. The vendor has actually done a lot to improve their overall GRC capabilities and is moving well beyond their traditional ticketing-system approach and having vendor risk and IT risk capabilities that we’re seeing a lot of clients move towards that. We have sandboxes where we’re helping clients design and implement their IT risk activities in ServiceNow.

We do see other vendors in the market, some of the larger ones that are commonplace, like OpenPages. To a lesser extent, we’ve seen a lot of clients where we haven’t directly implemented that. Same with MetricStream – we see a lot of clients using that but haven’t had any direct implementation experience there, but Archer, Riskonnect and ServiceNow would be the main ones.

Matt, are these tools effective in pursuing integrated GRC, because my next question to you is, what are some of the challenges with organisations that are pursuing integrated GRC in the United States?

Yes. I think the answer is yes. They can be effective in implementing integrated GRC. They just really do need to be set up right, and I think that’s where Protiviti can provide some guidance to our clients in sharing our experience of what went right when clients are looking for multidisciplinary GRC solutions and some pitfalls and things that we’ve helped our clients fix and remediate when looking at having multiple GRC activities occur in a single solution.

I think there are a couple of challenges that organisations face, and one would just be aligning those GRC requirements. Whether it’s in a single solution, the goal is to have everything in one solution, or it’s to allow multiple solutions, there still needs to be a sort of a common understanding and agreement on the common taxonomies, the frameworks that are being used, the methodology and processes, even down to the data points and field on specific record types to ensure that there is some similarity between those solutions.

Things like risk assessment or issue tracking – frankly, every GRC solution has a risk assessment capability and issue tracking capability, but if the organisation really wants to have enterprise reporting and track issues, they need to make sure that there are really aligning fundamentally at a field level, the methodology they’re using to rank issues. The process by which they track and extend due dates for issues needs to be the same, and bringing those items together is something that is frankly difficult.

It’s difficult in a single solution because you need to get everybody to agree to play nice in the sandbox together to leverage common things while allowing for discrete capabilities for individual solutions like audit execution or regulatory mapping that can fit within a platform that’s doing SOCs and risk management, but it also needs some very bespoke capabilities for audit and regulatory compliance activities.

The other challenge with doing that across solutions is, how do you get a common reporting set? Is information brought into a central data warehouse, or is there perhaps an API that pushes data into one or pulls data from solutions into a common reporting set? It’s certainly difficult for clients to get that multidisciplinary integrated GRC within either a single solution or even a little bit more so across functions.

Well, there’s clearly a lot going on here in the market right now, which is not surprising. Matt, what innovations in GRC are you seeing right now, building on what you were just explaining to me?

Yes. I think there are a couple examples of innovation. One would be, we’ve seen and we’ve actually helped a couple clients create an interim solution, or very custom solutions. I’ll give you an example: We’ve helped a couple of clients recently that needed a risk assessment solution to help inform their audit planning and drive their annual audit plan. They had a couple different GRC solutions in place, none of which really reflected their approach and the methodology they wanted to use for risk assessment. What Protiviti did is, we helped them build a custom interim solution while they are working to explore a more long-term GRC platform that could help reflect what they want to do.

Another client, from a custom perspective, we helped build a custom regulatory mapping solution. Their ultimate GRC system of choice was Archer, but the time that that was going to take to be updated and configured and ready for use didn’t align with some business objectives of performing a regulatory mapping exercise. So we helped build them a custom solution that was used for about nine months as an interim solution to help them perform this mapping activity, and then the data was just ported into Archer as a long-term solution. That would be one innovative thing. If the complexity and needs of the business aren’t achieved by an out-of-the-box GRC solution or an out-of-the-box GRC solution that could be customised, there might be a business case to explore a more custom temporary interim solution.

Another innovative thing that we’re starting to see clients do more and more, and I think will continue, is the use of bots – RPA, or robotic process automation. Especially from a testing perspective, the capability of a bot to go out and take a complete population and test against that provides clients more coverage, more accuracy and confidence in the results of testing, but that bot, whatever they’re performing, those results shouldn’t just be documented in a SharePoint list or an Excel file somewhere.

We’re seeing that as clients develop bots to help them perform automated testing activities, they really need to consider that that bot is actually documenting the results and contextualising it in the GRC platform of choice. We’ve had a couple clients where we’ve explored with them how could this bot actually log into the system and have its own ID and document and put the results in so that as a reviewer, when I go to review a test, whether it’s a test performed by a bot or a test performed by a human auditor, it’s tracked and contextualised in the same system.

Finally, the last piece or point on innovation is, I talked about how clients are often coming from or already have multiple GRC systems in place, and we’re starting to see this concept of what we would call a GRC ecosystem. It’s not that you have to have a single solution if that’s in place and everyone can agree to get on the same page and work in the same environment. That’s great and it works well, but that concept of a GRC ecosystem allows that end customer, whether it’s first-line-of-defense or specific second-line or third-line folks, to have a more tailored, unique experience while using native applications.

That first-line user might be accessing a SharePoint list that is integrated into the issue tracking module of their GRC, so they’re not logging into the GRC. They’re simply going to their own SharePoint page and saying, “Oh, these are my open issues. I can reply to them here,” and that’s being fed into the GRC so that first, second and third line can track and understand, “Hey, this issue is being updated by the user, but that user is not having to go into the specific GRC system. They’re using their normal day-to-day activities,” which often is the SharePoint.

Using that in that concept of that GRC ecosystem to say that there’s GRC data across the organisation that could be HR data – it could be audit data, or it could be CRM data from a marketing team – all of that information can be housed and sourced from their unique solutions and then brought together perhaps through reporting in something like an enterprise data mart where you can pull and can gather data from these systems to get a more holistic view.

Matt, again, great rundown on some of these innovations that are happening within the GRC tools and the overall market. One final question for you as we wrap up our discussion today – we talked about innovations you’re seeing in GRC, but then I’m also thinking about innovations happening throughout organisations. We’ve heard a lot about digital transformation, organisational transformation. Things are changing in the enterprise. How are those changes, like digital transformation practices and so forth, how do you see organisations incorporating those changes into their GRC programs?

Great question, Kevin, and I think that sort of dovetails into one of my answers on innovation, which was that concept of a GRC ecosystem. That concept allows our clients to think digitally and focus on that customer engagement. So, what is that customer experience? That might be that first-line-of-defense person, the process owner, and the control owner going to their SharePoint and having an integrated view where they can very easily go to a dashboard or a list of remediation items or audit issues they might be assigned to. Rather than logging into a separate platform, having those things be integrated and focusing on having that GRC application or applications, being part of that enterprise digital profile, that’s going to provide companies a view against taxonomies and data across the organisation and leveraging some best-of-breed technologies, really focusing on “What does that end user need in using those types of digital tools?”

I have one final question here. Is it safe to assume that it’s best for – call it the GRC team, to be engaged early in these digital transformation initiatives or efforts underway?

I think it’s certainly helpful. We’ve seen clients move forward with different GRC initiatives and realise that there are two or three different work streams all exploring, “Hey, we need a solution, and we need something” and then hitting the Pause button and saying, “We’re all moving in the same direction. We all broadly need the same thing. What is that end goal that we would be looking for, and can we go about this together, and is there some benefit of teaming up and aligning our efforts?” especially because a lot of the information and the data, it’s providing a view of risk across the organisation. Whether that’s IT risk focusing on the IT areas or vendor risk focusing on vendors, those IT applications, those vendors, those impact entities, businesses and the functions that are being performed, so it needs to be accounted for.

Just making sure that there’s a clear organisational taxonomy is certainly helpful in making sure that you justify the cost, the effort, to implement a solution and implement the right solution that allows you to grow and even consider that maybe this function isn’t going to be part of the initial implementation, but we know that this solution can grow and we can expand and involve other stakeholders.

Well, once again, Matt, thanks for joining me today. I appreciated your insights into these GRC programs and innovations happening in the United States. Thank you.

Thank you.

Thank you for listening today. You can find more information and the podcasts offering perspectives on GRC from around the world at protiviti.com/grc. I also invite you to subscribe to our Powerful Insights podcast series wherever you find your podcast content.