GRC Beyond governance, risk, and acceptance
GRC gets a bad rap from some CISOs and CIOs for being overly complex and not a core IT responsibility. Stephen Lawton reports on where GRC fits in the overall structure of data security and business management.
This editorial product was produced by the SC editorial team and underwritten by Informatica. It is part four of a four-part series.
If you ask 10 CISOs what the primary goals of their governance, risk and compliance (GRC) programs are, you might well get 10 different answers. The reason for that, experts say, is that GRC is such a wide-ranging practice of information security, it almost is too broad for a simple description.
Unlike the majority of data security considerations, many of the basic constructs of GRC come from the business management side of the enterprise rather than information technology, says Mark E.S. Bernard, CEO of Secure Knowledge Management, a Canada-based information security consulting firm.
Governance, he notes, is related to overarching oversight by senior management, generally for a specific group of responsibilities. Risk, he says, generally is a financial determination while compliance combines legal, financial and human resources disciplines with the technical side.
“It's just hard to wrap your brains around everything,” he says. Technology executives generally are more familiar with the operational aspects of GRC, he adds, rather than the management side. As a result, they can explain in detail how to be compliant with various regulations, what various architectures will cost and what they will do to protect the company, but they might not be able to build the business case for why a less secure approach might be more desirable to a risk manager than another, more secure network design.
Christopher McClean, vice president and research director at Forrester Research, says GRC is often associated with the Sarbanes-Oxley Act of 2002 (SOX) so companies that are not involved with the investment community tend to overlook or underestimate its importance. “GRC is a decision mechanism [and] not just for SOX,” he says.
GRC should be implemented in steps, he says, rather than trying to build out a fully functional program all at once. You cannot protect data or other assets if you don't know what you have and where the assets are located, McClean says. As a result, GRC needs to be rolled out so that assets can be identified and risks can be assessed.
GRC goes beyond just technological and financial compliance and risk management, he adds. Human resource policies and procedures can be identified, such as training employees on the fair use of company assets and for identity and access management. Cultural issues also can be addressed as they apply to HR legal requirements.
For multinational companies, GRC becomes essential for ensuring that personally identifiable information of employees and other protected data do not traverse political boundaries in violation of local laws. This aspect of GRC came under greater scrutiny earlier this year when the high court of the European Union tossed the 15-year-old Safe Harbor rules for moving data among Europe, the United States and other non-EU nations, he says.
While most IT executives think of GRC in terms of complying with industry and government standards – such as the Payment Card Industry Data Security Standard (PCI DSS), the Health Insurance Portability and Accountability Act (HIPAA), Health Information Technology for Economic and Clinical Health Act (HiTECH), and the aforementioned SOX, it also deals with such day-to-day activities as backup, business continuity and access controls.
Sometimes, however, GRC can identify situations where laws in different countries can contradict each other, resulting in situations where compliance with one law (e.g., data privacy rules) can be in direct conflict with those same laws in another country. The overturning of the Safe Harbor ruling in the EU is a perfect example. In order to not violate compliance regulations, Forrester Research's McClean recommends companies document all discussions and actions taken to meet the local requirement and any compensating controls they put in place. This, he says, will show regulators that the company was aware of potential non-compliance and acted in good faith to meet the contradicting regulations.