Today's governance, risk management and compliance (GRC) software has useful features that can help organisations get a better handle on how they're managing risk, security and compliance issues.
That's a big task with a lot of moving pieces in a company of any size. Information security and risk management executives say the GRC market in general has plenty of room to grow before realizing its full potential and completely meeting the needs of many companies.
So what should users expect--and require--of GRC software in terms of future development? Two experienced security leaders point the way.
A question of focus
One challenging question right off the bat is whether GRC tools should strive to expand their capabilities in the short term--or first narrow their focus to ensure they deliver excellence in their core functions.
Depending on how it is implemented, GRC software can actually add complexity to risk management. "A solid GRC program already has a number of work flows and data repositories in place," says Jamil Farshchi, senior business leader of strategy, planning and initiatives at San Francisco-based financial services firm Visa.
"In trying to integrate and/or subsume all of these, GRC tools attempt to be all things to all people, which can only be achieved through a flexible and customizable platform. Implementing and maintaining that customized platform usually requires large, continued investments in both capital and labor."
Vendors can address the issue, Farshchi says, by improving interoperability so that organisations don't have to develop customized hooks for each disparate data set, application or system. In addition, they can tailor GRC tools to do one job really well rather than try to expand the reach to every functional GRC problem that any business might have.
Ease of use
Another key challenge with GRC tools is usability, Farshchi says. "They tend to be very complex and hard to use from a user-experience perspective," he says.
"As such, it costs a lot and requires a substantial amount of time to even train the workforce to get value from the tool. And even after being trained, users still fail to utilize the system to requirements. The resulting data tends to be inaccurate, then the tool fails to produce actionable information, which was the entire reason organisations purchase GRC tools in the first place."
That problem should be relatively easy to fix, according to Farshchi. "Vendors should take a page from Apple or Intuit and apply some user experience testing into the design of the tool interface," he says.
"By making the GRC tools more user friendly while controlling for invalid data, training is easier and cheaper, adoption is quicker and the likelihood for input errors is reduced."
Openness and APIs
Another issue for organisations turning to GRC technology is vendor lock-in, says Robert Brown, CISO at Western Bridge Corporate FCU, a credit union in San Dimas, Calif.
"The platforms that are being built by most vendors are proprietary," Brown says. "On the good side, this means that they come with a prebuilt controls library and a generic risk process. But on the bad side, this means it's generally difficult to extend or customize in any meaningful way."
Brown has two suggestions for vendors. The first is that they build the GRC platform on top of an open source content management system. "This enables a much wider array of options when it comes to modules and potential integration," he says.
"Most if not all of the GRC tools that I have seen use a proprietary database schema and customized software. This means there is no economy of scale when it comes to leveraging the work of a broader open source community."
Brown's second suggestion is to ensure that a well-documented, published, open API is available for the product. "This API should go in both directions--to enable an easy ability to get data into the system and an easy way to get data out of it," Brown says.
"A number of vendors are moving in the direction of an API, or have one already. But very few, if any, are built on an open platform."
Brown says he finds it tough to get data in or out of systems or tie it to an existing business intelligence platform. "And you are forever stuck both paying for ongoing support and maintenance and possibly extra cost for consulting, integration, customized features," he says.
"There's no one right way to do risk management, there's not one set of input or output data, and that complexity becomes a big hurdle."
[Also read IT risk assessment frameworks: Real-world experience]
This goes back to the open nature of the platform, Brown says. "If you are working on a closed/proprietary platform, it means that one of two parties is going to be responsible for all aspects of data integration and customization: the product vendor or the customer," he explains.
"With an open platform, you have a broader base of existing code to use and the ability to release your integration work to the community and gain additional users, support, and bug fixes. A collaborative, open platform helps create those economies of scale for the customer and also frees them from vendor lock-in."
More governance
One aspect of the GRC process that is not covered by products, Brown says, is the "G" in its acronym: governance. "How are committees defined and how often do they meet?" he says. "What happens once risks are identified? Once you prioritize and accept a risk, what happens next? Does this link to a project management office function to define remediation efforts? How do those efforts get funded? All of these questions are very relevant to how GRC might work, but in many cases are not answered by a GRC product, nor are they cookie-cutter for each company that implements GRC."
Brown recommends that vendors focus on educating the community at large about GRC. This includes publishing sample policies, discussing different governance models, and presenting podcasts and videos with customers discussing what approaches work and don't work.
"This information should be freely available on the Web and in social media, without a requirement to provide contact information or create an account on the vendor's website," Brown says. "The vendor could also host a collaboration forum for the community to discuss GRC, either on their own Web site or perhaps leveraging LinkedIn communities."
To address some of the issues the company encountered, Western Bridge built its own GRC tool using the open source content management system Drupal. "Software cost was zero, it has widespread community support, we tailored it exactly to our needs, there are no ongoing vendor costs, and we can integrate it however we see fit," Brown says. "It has worked very well, and most people are blown away when we even describe it at a high level."
GRC technology in many ways is a data analysis function, Brown says, and just like any other data process it's only as good as the input. "For example, to build proper linkages you need to know all of the people in your company, on an ongoing basis as it changes, all of your technology platforms and systems, your policies/standards and controls, etc.," he says. "And all of that changes with the business regularly. We initially tried GRC with spreadsheets, then databases, then a vendor product, until we finally rolled it up on our own."
The problem with the company's earlier approaches was getting timely, accurate data, Brown says. "Spreadsheets are great today, but tomorrow that IT asset you just linked could be rebuilt, virtualized [or] moved to a cloud," he says.
"Your wonderful risk models and all of the work you completed is now outdated because your business process changed. And the real value of risk management is not in chasing change in your environment, it's understanding the threats and risks based on how the environment is changing."
Another challenge companies face when implementing GRC software is staffing. "In many cases the folks who are handling GRC have other responsibilities, so whatever product is used has to be measured by how much care and feeding it needs," Brown says. "Who hosts it? How does it get patched/updated? Will the update break any of our existing content? If there is too much overhead in maintaining the software, it cuts into the time to actually conduct risk assessments."
Differentiation points
So how can vendors make GRC products more helpful for their customers?
"I really believe that products, companies and even people compete best by differentiating themselves--finding one or two things they are outstanding at, and leveraging them to outcompete all others in that space," Farshchi says. "Instead of trying to be all things to all people, GRC tools should focus in on a couple of key pain points for the IT enterprise, and offer a streamlined, standardized, interoperable solution to those problems."
Farshchi sees signs that GRC is moving in a positive direction. "First, the dashboard functionality in these tools is maturing, in that the data is more readily consumed by key users and stakeholders," he says. "Second, the notion of risk has become better reflected in GRC tools as organisations are able to set 'target' risk levels. Although the dashboards can still be improved and the applicability of the risk calculations leaves a lot to be desired, these improvements demonstrate that GRC tools are maturing."
In an ideal world, "a GRC product would work a bit like a Salesforce.com" customer relationship management (CRM) application, Brown says. "Secure, hosted software as a service, with a well-documented API [application programming interface] to enable data linkages with additional third-party tools that can easily extend functionality."
Brown thinks of GRC systems as being highly customizable and flexible ecosystems. "It should also be sold as a process, where it comes with integration services, training, governance models, sample policies and frameworks, and on-site or remote help to set up the program at a company," he says.
"Otherwise, by simply selling it as a software product, there is a high risk of the purchase becoming shelfware."
Back to the beginning
Brown's feeling on risk management in general repeats the starting point of our GRC examination: enterprise risk management/GRC is a process, not just a product.
"It takes thoughtful consideration when implementing it, educating business leaders, linking it to process and data, conducting the actual analysis, and then doing something meaningful with the results," Brown says.
"It's likely to have a different governance model in almost every company based on organisational structure, internal politics and inertia. Any GRC software product needs to be very flexible to adapt to however a company implements it, and it also needs to be able to start slowly, whereby you can turn off 95 percent of the product features at the beginning of the journey just to get the process off the ground." Follow CIO on
Twitter @cio_nz
Download CIO for your tablet here.
Click here to subscribe to CIO.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.