Commentary

Mike Fratto
Network Computing  

CSI 2008: The Business Case For Governance, Risk, And Compliance

There are three legs of a table that, if weakened, put your organization at risk and, if a leg is removed, let the table fall to the ground. IT governance, risk, and compliance (GRC) is fundamentally a return to the basics of information security. Regardless of technology, you need to know what to protect, when it needs protecting, and why it needs protecting. Getting ahead of the game is more effective than catching up later.

There are three legs of a table that, if weakened, put your organization at risk and, if a leg is removed, let the table fall to the ground. IT governance, risk, and compliance (GRC) is fundamentally a return to the basics of information security. Regardless of technology, you need to know what to protect, when it needs protecting, and why it needs protecting. Getting ahead of the game is more effective than catching up later.Ron Woerner, security compliance manager for TD Ameritrade, brings GRC down to the three R's: reputation, regulation, and revenue. If you're not focused on these three areas, you're not doing GRC, or risk management, for that matter. Regulation -- you get that. You have been soundly beaten over the head with regulatory compliance the last few years. If your company is in a regulated industry, then you have to comply with something. A daunting task, to be sure, but compliance alone isn't enough. A good reputation with your customers and with your partners is a difficult trust to earn and an easy one to lose. You don't lose reputation simply be having a breach. Rather, you lose reputation by your actions leading up to and after the event. And then there is revenue.

Information security always has been seen as a cost center -- something you have to pay out for some perceived benefit. The business problem with security is that when it works, you don't see it, and monetizing the financial benefit is difficult. There is no guarantee you will be attacked and if your company has been attacked, there is no way to determine you will be attacked the same way again. The vulnerabilities are moving targets.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

There are a number of ways to try to quantify risk, such as Annual Loss Expectancy (ALE), which equals the cost of a loss multiplied by the number of times the loss is expected to occur in a year. Return on Security Investment (ROSI), which factors in the avoided loss based on the purchase and deployment of some technology. A more fundamental equation called the Hand Rule, after Judge Learned Hand found that a barge captain could have averted an accident if he had been properly equipped and on board, quantifies risk as the cost of impact multiplied by the probability of an event. The product is divided by the cost to mitigate the threat of the event. By assigning values to the variables, you should be able to calculate risk, which is the likelihood that your company will suffer a financial loss.

But all those equations are about avoidance and minimizing risk and costs and is ultimately a reactive strategy. Woerner had a better analogy for the business case for information security using cars. Brakes were invented and installed on cars not to stop them, since cars at that time didn't go very fast. Brakes were installed so that cars could go faster safely. Another example is rearview mirrors. Rearview mirrors were invented so that racing teams could get rid of the rear-facing mechanic and the driver could still see behind him. The value of brakes and rearview mirrors was to let cars go faster, safely. The motivation wasn't to avoid collisions. The result was fewer collisions.

We can apply the same principle to information security. Any new IT project brings additional risk with it. Data is stored in more places. There are more ways for the data to be lost or misused. There are more points of entry. The risks are greater than not employing the IT project. If your company went back to a paper-based system, you would never have to worry about electronic attack, right? The qualitative argument is that your company will deploy new IT projects and will be partnering with external organizations. You can actively identify and manage the risks proactively so your company can move forward safely.

Michael Hannigan, manager of systems engineering and support for Electric Insurance, who I interviewed for the 2008 InformationWeek Strategic Security Survey [[registration required]], stated that his company identifies, evaluates, and manages risk on every new project because his company has to adopt new business and new processes, just like any other business does, and they can either proactively manage risk from the start, or they can reactively manage risk after the fact. Proactively managing risk is ultimately more effective and more cost effective than reacting after the fact and once you go from a reactive model to a proactive model, you move from information security to governing your IT systems.

That's your business case.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links