Q&A: Best Practices for GRC
Where should an enterprise begin when undertaking a governance, risk, and compliance project, and how can IT avoid common project mistakes?
In an increasingly regulated world, governance, risk, and compliance (GRC) is a key part of any enterprise strategy. However, what's often overlooked is the difference between GRC as it applies to the business and GRC for IT.
To distinguish these dimensions, and explain how an enterprise can avoid common GRC project mistakes, we spoke with John Capobianco, CEO of Lumigent Technologies, Inc. John has over 30 years of experience in the IT industry and has grown the business and brands of several large companies, including HP, SAP, and CA. In our conversation, he explains why GRC is so labor intensive, how to evaluate GRC solutions, and how to solve communication issues between business users and IT.
Enterprise Strategies: What is GRC and what are the major pain points around GRC for the enterprise?
John Capobianco: GRC is really the fusion of three distinct but interrelated disciplines -- governance, risk management, and compliance. You have to differentiate between enterprise GRC concerns and those facing IT. IT GRC tends to focus on such elements as security and general computer controls and privileged user access.
The pain points around enterprise GRC, however, revolve around the business processes and include business-level controls, application-level controls and policies, and the audit reporting needed for compliance reporting to internal and external auditors. That’s just one level. Another level is the analytics for trending and forecasting based upon risk mitigation strategies and identification of risk. The third level is executive guidance assistance, usable by the executives and the board and the audit committees to provide directional analysis and recommendations.
Enterprise GRC tends to be more interested in addressing issues for the business users, focusing on how they can make their company more profitable and productive and how they can deal with their company directionally. That requires automating manual processes, including data gathering and compliance reporting.
In a recent article you wrote that enterprises should start to tackle GRC by first focusing on the "C" – compliance. Why start there?
Compliance (especially compliance reporting) is an obvious corporate cost that has no benefit to the business. Most companies are performing most of their compliance reporting tasks by hand, which is really expensive. Compliance reporting has no obvious benefit to the customers, the products, the services organizations, or the shareholders. It provides visibility, yes, but it has no other intrinsic business benefit.
One of the things you want to do is automate compliance efforts so they cost as little as possible. To complete compliance reporting, you must acquire the data needed to feed the GRC stack. Although you are starting with the compliance solutions, they are serving as a data acquisition layer, gathering compliance information during the testing and monitoring of controls and data. With that foundational data layer in place, companies can begin managing risk with analytics solutions that interpret the compliance information and generate options for mitigating identified risks. Finally, governance solutions can be introduced to evaluate the available options, determining the most appropriate course of action.
Everyone complains about the manual labor GRC requires. Can you give us a few examples of these draining tasks?
From my personal experience and the experiences of most of the organizations that we engage, the auditors show up and ask a bunch questions as they investigate potential deficiencies and material weaknesses. The finance department has to sample data and controls over the reporting period, every quarter, so the auditors can ascertain 1) whether controls are in place now, 2) whether they were in place, and 3) what happened throughout the system. In turn, the auditors can certify in their audit and issue an official opinion confirming the proper business controls were in place. Of course, the auditors might determine that the controls weren’t in place, and these are the material weaknesses for the company that need to be addressed.
The real work for the finance department lies in the tremendous amount of sampling and testing associated with the audit. It eats up lots of time. To demonstrate that a particular control or business process is in place or has been in place over time, you typically have to scrub transaction logs and run manual tests against the system. Technical users have to develop and run targeted, one-off tests to determine where the control source is and gather the data. If the auditors have any questions, you do it all over again.
For instance, auditors might want to see the value of a particular vendor address every day throughout the month. You have to dig through 90 days of general ledger reports, reviewing them day by day. After you’ve sampled and validated that particular item, the auditors could inquire about any transactions that could have changed the vendor address. Now, you have to dump the transaction registers and look at them. Not only have you manually reviewed all the daily reporting and logs, but you’ve also manually reviewed the transaction logs. That’s a lot of work just to answer one question.
There are so many suppliers and providers available for GRC, what are important approaches companies should consider when evaluating a solution for them?
First of all, don’t expect one vendor to handle all facets of GRC. Second, there are lots of GRC vendors because it’s a fairly ill-defined market -- a superset of often loosely coupled disciplines. Companies need to focus on how they’ll get the G, the R, and the C -- specifically and distinctly, because typically G, R, and C are each done separately by maybe a handful of vendors.
Third, make sure that you clearly define what you want from a GRC solution, based on your needs as a financial user or other business user. Remember, enterprise GRC addresses business issues that don’t fall under the domain of IT GRC, yet a vast majority of GRC providers are focused on IT GRC. Yes, security and privacy and other IT GRC issues are important enterprise issues, but IT GRC simply isn’t designed to answer questions about quarterly audits of the finance system in the finance department.
Fourth, make sure you’re addressing the business needs of compliance reporting, whether you custom build your own solution or buy a pre-built application that does sampling and testing and has subject matter expertise baked into it. Does sampling and testing make the most sense, or is continuous monitoring more persuasive? Does it make sense for you to be a maverick running a homegrown system, or do you want to use a standard reporting application that can simplify the process for yourself and for IT, providing relief from the on-going maintenance chores associated with upgrades and regulatory revisions and additions?
I hear a lot about IT and business executives talking different languages when it comes to GRC. What kind of miscommunication occurs, and what are your recommendations to solve this?
I think there’s a realization that many organizations have attempted to solve some of the IT GRC problems -- especially security and privacy -- and that’s the vast majority of implementation of GRC that has been done to date. There are also vendors who have wonderful dashboards and the ability to monitor certain sets of controls and policies that they custom build and put in place. There are analytics vendors who provide a good basis for risk mitigation with forecasting and trending analysis.
Most of the data that everybody is working from appears to be coming from the transaction side of the business. Although that has value, it’s primarily in the world of security and privacy issues. What transaction data cannot do is the baselining and continuous monitoring of application source data and key business controls that’s required for persuasive evidence, according to Committee of Sponsoring Organizations rules. That persuasive evidence provides the foundational underpinnings and the data acquisition model that will actually feed all the rest of the GRC processes.
We have such a wide variety in IT and business discussions about GRC because GRC is not very well defined in terms of its three, big component categories. Instead, G, R, and C get balled up into one fuzzy, disorienting ball. When you get down to the business providers, most of them are doing transaction capture. SAP, for instance, is producing international shipping compliance reports that are required for international businesses. That’s terrific, but no transaction-based analysis system can provide all of the SAS 70, SOX, or DCAA compliance reporting required for the actual, business-focused compliance audits that the CFO deals with every month, every quarter, every year.
What are the biggest mistakes the enterprise makes when addressing GRC?
The biggest mistake is that they don’t let the business unit managers, the CFO, the VP of finance, or the compliance officer who works in the finance organization define the challenges they’re trying to overcome, e.g., what automation they need, what business processors they need, what audit requirements they need to simplify. Instead, IT winds up focusing on the IT GRC requirements, as well they should, but they don’t have the subject matter expertise to create the business level reporting necessary for Application GRC. IT goes out and buys the platforms and tools and typically does the security and transaction monitoring that’s required for IT compliance reporting. The business users continue to scurry around for every reporting period, doing their compliance reporting by hand. The tools must serve the business user too, not just IT.
IT compliance reporting is a good thing. You need privileged user access, segregation of duties, and so on, but it’s not what the business users need. The business users need business-focused compliance reporting. The typical IT department, however, doesn’t have the subject matter expertise to understand what the CFOs, controllers, and other business-oriented users need from an audit reporting package in terms of controls and policies around the business processes. As a result, the enterprise winds up reacting to what the industry analysts are identifying as things that can be done with the tools and platforms that are available, but it’s mostly from an IT GRC perspective. There’s very little attention paid to the business GRC needs, and there’s a lot that can be done inside the enterprise from a business process standpoint. That’s what needs to be addressed.
What best practices can you suggest to avoid these common mistakes?
I’m not saying organizations are making mistakes when it comes to IT GRC per se. Rather, I’m encouraging them to expand their understanding of GRC beyond IT to address the business overall. That includes using best practices and industry-standard detail around required compliance reporting and building business applications that will assist the financial staff in meeting the needs of the auditors. The best practices themselves will vary by business process, by industry, and, of course, by regulation.
What products or services does Lumigent offer to help enterprises take on GRC tasks?
We produce automated GRC control systems that continuously monitor the source data and key business controls for financial applications. Today, the primary focus of our AppGRC solutions is compliance reporting. We can also serve as the data acquisition platform that feeds established, third-party risk management and governance solutions. First and foremost, AppGRC is a business solution. It’s pre-built and includes all the subject-matter expertise related to the business application it reports on as well as the relevant regulatory issues. We’ve built the solutions that financial organizations need to do compliance reporting. Nobody else is doing that.