Compliance is a necessary evil for financial institutions, but it's nothing new. From the first days of Gramm-Leach-Bliley Act (GLBA), financial firms have been subjected to periodic audits to ensure they have implemented security controls that protect private customer financial data.
Assembling and presenting data to auditors in a cogent fashion can be more than a full-time job. Many large financial firms devote considerable time and resources to gather data, make sense of it, and then build reports. Considering the number of governance, risk and compliance (
In concept, GRC software is about automating the compliance reporting process. Let's first examine what that means. Basically financial firms need to report on a few things to keep an auditor happy:
- Know where private financial data resides. This can be accomplished with network and
data center diagrams. More importantly than knowing exactly where the data is, auditors want to
know that a structure is in place to keep track of that data.
You can't protect what you don't know about. Thus, one of the first roles of the GRC tool is to make sure the organization can map where its most important data is and can present that in a reasonable fashion.
- Track controls, or the policies and defenses in place to protect private financial data.
This can be as simple as a repository for policy documents, as well as a place to store network,
security and system device configurations.
Don't forget to detail who has access and what can they access. This will give the auditor perspective on how the data is being protected. Additionally, one of the key techniques used during an audit is a survey where the organization assesses its own capabilities, and the auditor then verifies them. To that end, a GRC suite will need to be able to gather this data in an automated way.
- Track vulnerabilities and attacks. The GRC software should take feeds from an enterprise's vulnerability management systems and change management systems, as well as aggregate log information from devices.
- Map data to regulations. Enterprise GRC software should have an underlying workflow and project-management engine that can figure out what data elements are important for which regulations. Thus data is gathered, once, but multiple reports can be generated for any of many different regulations. Since the big payback from investing in GRC is automation, especially at large financial firms, making sure there is an underlying process at work is critical to having a systematic and repeatable compliance reporting process.
GRC software for companies large and small
The definition of GRC has been muddled by a whole bunch of different vendors trying to stake a claim in the space. Thus, it's hard to understand what GRC really means and whether a "new" type of offering is needed to meet your organization's needs.
The reality of the situation today is that the needs of large financial services firms are totally different from those of smaller financial organizations. While the sheer data aggregation ability for a global bank makes the payback of these tools a no-brainer, that assumes the tools will save time in gathering data and generating reports.
The fact is most large financials tend to be among those experimenting with cutting-edge security and compliance tools. So in many cases, these firms already have a tool in place to do what many GRC-specific products promise to do; you just may not know it as GRC. Things like identity management, SIMs and reporting engines usually comprise a bulk of the GRC functionality. It makes sense for these larger organizations to put together a matrix of the tools already in place and weigh those against the capabilities of one of these so-called GRC tools to really understand the overlap.
The first generation of GRC software suites tends to be big, expensive and take quite a while to implement. Since automation is all about getting a better return on your time investment, if the solution costs too much or takes to long to receive value -- then it's not worth the effort.
For smaller financial organizations, I recommend a "poor-man's" GRC. True data integration and common compliance reporting may not be worth the time or the effort. Leveraging a log management data and cross-referencing it with information from more proactive tools like vulnerability scanners can handle a bulk of the audit preparation for much less money. Is it as automated as a fancy GRC suite? No. But it enables precious budget dollars to be spent on other projects. Remember, passing an audit doesn't help a financial services firm to gather more assets, close more M&A transactions or lend more money. It allows a company to keep the lights on and focus on all those other things it does well. After all, GRC boils down to spending as little cash as possible by making sure an organization isn't duplicating its efforts.
One last word of caution for financial companies of all sizes: stay focused on the difference between security and compliance. A GRC suite can help an organization pass an audit, but it doesn't do much to protect data. Documenting the organization's security strategy and processes will put it in decent shape for an audit. Not vice-versa.
About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at) securityincite (dot) com.
This was first published in May 2008