GRC – A Performance Management Platform or A Success Management Platform?

On May 1st French Caldwell posted a blog titled GRC Will be a Performance Platform in which he references a blueprint that provides a practical approach for identifying the goals of ERM programs in terms of strategic business objectives, and linking that to an underlying GRC architecture that can drive business performance benefits. But isn’t that too limiting?

Performance Management is merely a solution category and doesn’t do GRC platforms justice! When considering how GRC platforms span across Finance, Operations, Legal and IT providing organizations ways to manage risks, demonstrate compliance and ensure governance business performance benefits is only one output and to me only represents how an organization has done historically against business objectives. This is important but not all the benefits that a GRC Platform can and should provide a company.

When organizations use GRC platforms that also includes Big Data Risk Analytics not only will they be able to report on past performance to various levels, domains and to different audiences but they will also be able to predict the future. Future performance, future risks, future efficiencies, and most important future opportunities for success. Big Data risk analytics within a GRC Platform should model out opportunities for growth that drive success within each domain. So I think that GRC platforms will not be performance management but  “Success Management Platform”. Might this be a new category?

PS – I would have really enjoyed the panel with Paul Proctor and Network Frontier’s Dorian Cougias. Not only do I find business predictive and risk management conversations interesting I also am equally if not more fascinated by conversations with “the security geeks” of the world as they save our businesses every day. We should all find them fascinating!

imagesCAH4BEPD

Advertisements

There’s rapid payback for organizations that automate GRC

It never ceases to surprise me how many organizations still use manual processes and unstructured documents to handle their GRC activities. Relying on spreadsheets, presentations and other documents to manage all that information takes a huge amount of time and effort, but delivers very little in the way of consistency or scalability.

On top of that, there’s no ability to aggregate risks organization-wide. This makes it practically impossible to present risk in meaningful ways, and to respond effectively to audit findings and compliance requirements.

Automation changes everything

Organizations that use a software solution, such as RSA Archer, to automate GRC processes tend to see a very rapid payback. Typically, IT is the first user group, the initial aims often being to improve the rate at which secure IT projects are delivered, and to support policy management processes for information risk management.

Because IT provides the underlying infrastructure for other domains, the initial investment in the software will often provide a strong foundation for adoption by other functions, such as finance, operations, legal and HR.

Everyone starts using a common GRC vocabulary. And you get visibility of collective issues, so groups can collaborate on understanding the aggregate issue, rather than fragmenting their efforts across two or more overlapping issues.

What’s the ROI?

Information risk management staff can be more productive and do more analysis work. IT security expenditure will be better directed. The organization will be able to lower its risk exposure and reduce incidents. And ensuring regulator-ready, accurate and timely output becomes a piece of cake.

A recent Forrester Consulting report, The Total Economic Impact of RSA Archer IT-GRC, indicates a 572% return on investment within a three-year period. One company interviewed said that 97% of the ROI they calculated was based on the reporting tool alone.

RSA is hosting a webcast with Forrester on May 22nd, 2012. The webcast will feature Jeff North, Principal Consultant, from Forrester who will discuss the report findings. Also featured during this discussion will be the VP of Security and Privacy from a F500 Media and Entertainment company who will provide insight into real-world benefits they have been able to achieve using a GRC Platform. Sign up for the webcast.

If you’ve already automated your GRC processes, what have been the payback and benefits of doing so? If you’re ready to automate, where do expect to see the greatest efficiency gains, and what ROI are you counting on?

‘I don’t understand what you’re trying to tell me’: Why taxonomy is so important to eGRC

Taxonomy, the science or practice of classification, is all about specifying the relationships between entities and giving them agreed names.

I can’t count the number of times that clashing taxonomies have caused me difficulties: mis-interpreting what a friend is telling me, a boss not being on the same page, my direct reports looking at me like I’m from Mars. I remember a time when I was four years old, around the holidays, asking over and over again for ‘milk yolk’ while my mom tried desperately to figure out what I wanted. After 10 minutes of trying everything, she finally got it when I described what the drink looked and tasted like. I was after eggnog, of course.

As I explained in my last blog, when it comes to eGRC it’s critical to create common processes. A big part of this is providing consistent naming conventions so that everyone is talking the same language and there’s less chance of miscommunication. I gave the simple example of an ‘incident’ management process and an ‘issues’ management process that were identical except for what the stages in the process were called (largely just a difference in using ‘issue’ vs ‘incident’). But of course many taxonomy differences won’t be as obvious or straightforward as that example.

Naming conventions are important because they frame people’s understandings of what’s happening and what they need to do. They let people identify the context quickly and hand off information and activities without going through the palaver that my mom and I went through.

The issue of taxonomy often comes to the fore when you’re assigning labels to elements and workflow activities within software applications that are part of your eGRC strategy. People need to be comfortable with what things are called if they’re to use technology effectively; and it can take months to negotiate these naming conventions. Make sure you allow for this in your planning. Dealing with taxonomies effectively is a critical success factor for eGRC.

Good GRC taxonomy website:
Open Compliance & Ethics Group

Business continuity as an element of GRC. An illustration

In my last blog,  I promised to bring you a case study that illustrates the benefits of applying the best practices of eGRC to business continuity management. So here it is.

We’re looking at a financial institution that provides insurance, retirement and investment products, mainly to cooperatives, credit unions and their members worldwide. As a leader in its industry, this company takes risk management and data protection very seriously. Both its own high standards and the requirements of the regulations that it must adhere to make risk management a company priority.

Why doing the right things isn’t always enough
The company was doing the right things. It was carrying out vendor assessments to evaluate the risks presented by some 250 partners. It recorded policy exceptions, such as applications that wouldn’t support new standards for robust passwords. It was also conducting annual business continuity business impact analyses and had disaster recovery plans for all of its key applications.

Sounds pretty robust, right?

The catch is that all of these activities were standalone processes with outputs held by relevant business owners in emails, filing cabinets or limited fileshares. The company’s IT security and risk management team had little visibility of any of this documentation and had no easy way to identify emerging IT or business risks that might affect business continuity or disaster recovery plans. There was also limited collaboration between the IT disaster recovery team and the company’s business continuity team within its corporate risk function.

Senior business executives had even less insight. They just assumed that IT could get a data center up and running again in a few hours. They didn’t appreciate what might happen if a natural disaster struck. They didn’t really understand the risk or potential impact of a data breach, whether through a vulnerability of the company itself or a partner.

The company knew it could do better. It wanted to remove the various disconnects between business users, IT and senior management. “Our focus was to transition from standalone processes to a more complete company-wide view so that we could make better decisions based on the bigger picture without digging into details first,” says the company’s chief information security officer.

What happens when you integrate and share?
So now the company has implemented a central solution that supports both business continuity and other risk management activities.*  It has an integrated tool through which to gather, process, store and report on risk- and infrastructure-related information, including business impact analysis surveys and disaster recovery plans.

Everything is in one place and consistent processes and workflows can be applied to all business areas. Vendor assessments, policy exceptions and other risk-related documentation can all be accessed, reported on, and used to inform business continuity teams and risk management activities. Data from business impact analysis surveys can be combined with metadata about systems gathered through a different process, enabling the company to tie together its system, server and database dependencies. Disaster recovery plans developed with application owners are consistent and, instead of being treated as independent items, can be orchestrated into an overriding plan with priority given to applications based on their criticality.

Senior executives have direct access to a reporting dashboard and can quickly see open risks, vulnerabilities and whether disaster plans have passed their tests. There’s no longer a gap between their perceptions and reality. This visibility has given the IT security and risk management team the ability to justify appropriate investment to fix problems.

And there’s more

The impetus for this company was always the desire to protect its customers and prove itself a trustworthy partner. But it’s also saving a lot of time: a couple of hundred hours from efficiencies in conducting impact analysis surveys; and a 75% reduction in the number of people needed to perform vendor assessments.

So I hope I’ve illustrated my point from the previous blog: a siloed approach to business continuity or risk management is not the way forward; an integrated approach is the only way to get your organization into a best-in-class status among the business elite.

* In case you’re wondering: the solution referred to, which holds all the company’s critical disaster recovery information, is itself backed up to an active offsite instance so that it remains accessible in the event of a disruption taking out the primary tool.

Resources:

Large Financial Services Business Continuity Case Study
Large Telecommunicaitons Company Business Continuity Case Study

‘I didn’t see you!’ or, why visibility and control are vital to eGRC

By Alex Bender, Director, eGRC Programs and Strategy, EMC

The other day I saw a car accident. It made me think back to an accident I had years ago, which involved a car appearing so fast I didn’t see it until we were about to collide. The only thing I could do was to swerve wildly to avoid the collision, thereby losing control of my car and crashing — but at least not into the other car.

Thinking back to that accident and the aftermath — the hours spent on a litany of phone calls to my insurance company, getting repair quotes, getting the car to the garage, making alternative arrangements while I was without my car — I couldn’t help but think about the importance of visibility and control in business, as much as in life. The impacts of the lack of visibility and control are extremely apparent in the car accident example – life changing.

See more, act faster, spend less

When you have visibility you can see where you’re headed and plan appropriately to get there. When you have control you don’t have to just react wildly to changes in your environment; you can act with efficient deliberation to avoid situations that are harmful to your organization.

Lack of visibility and control, conversely, can result in a car crash for your organization; and the crash itself is just the beginning of the toll taken on time and resources. If, despite your best efforts, you’ve been unable to avoid an incident, then visibility and control play a vital role in helping you to respond effectively to the aftermath: to minimize the time and money spent identifying what went wrong, fixing the problem and dealing with the legal, operational and financial fallout.

Requirements for visibility and control

In a previous ‘two-part’ blog I wrote about the importance of collaboration across departments for effective eGRC. Well, visibility and control are the fundamental enablers of effective collaboration. So the question becomes: how do you achieve them? You can’t just wave a magic wand. Organizations of all sizes and types are struggling with eGRC issues precisely because they don’t have the visibility and control they need.

I think that for any strategy, approach or tool to give you eGRC visibility and control, it needs to have three attributes:

  • Integration. As long as information relating to eGRC is held in disparate and disconnected systems or dealt with through disconnected processes (probably using ad-hoc tools, excel spreadsheets, word docs and many times just quick conversations), you can never get a clear view of what you know, what you’ve don’t know, what’s happening and how it all relates. Conversely, if you can bring everything together in one place, not just as a central dumping ground but in a way that lets you connect it in meaningful ways, then you’re most of the way to having the visibility you need — to be proactive, rather than always firefighting, and to see the big picture that lets you take a strategic approach to solve your business needs.
  • Automation. One of the difficulties in achieving integration and in dealing with the results is that there’s just so much to integrate and manage in a manual way. Too much to have a hope of doing it effectively without technological help. With the best will in the world, spreadsheets won’t cut it. Manually pulling data from hundreds and or thousands of systems won’t cut it.

To avoid being swamped by information and actions, to be able to act and respond in a controlled way, you need tools that will help you up the eGRC learning curve and that will automate processes wherever possible. But you do not want to automate a bad process since that will just make bad things happen efficiently. Sometimes it is important to revamp a process while you are implementing your eGRC solutions and strategy. Questions to ask yourself are:  Do you have to respond to each new policy or regulatory requirement from scratch or do you have access to eGRC content that prevents you from having to continually reinvent the wheel? Do your processes depend on someone remembering to email someone else or do you have workflow management tools that automatically enforce standard processes? It’s obvious which answers suggest an organization more in control of eGRC.

  • Usability. However integrated and automated your eGRC efforts are, it will be of little avail if it’s too hard for people, especially non-experts in eGRC, to understand what’s going on or what they need to do. Usability is a critical requirement because visibility is only valuable if people understand what they’re seeing; and control is only valuable if people are willing to pick up the ball and do something useful with it. So you want the flexibility to be able to adapt automated processes to fit the way you work; you want to be able to present information to busy executives in ways that they understand; you want to make it easy for people to collaborate, not put them off with impenetrable technology.

When you’re looking at approaches to eGRC and assessing tools that might help you develop eGRC strategies and processes, keep these criteria in mind.

Recommended Reading:

OCEG – Red Book 2.0 (GRC Capability Model)

Don’t we all work for the same company? Part 2

By Alex Bender, Director, eGRC Programs and Strategy, EMC

Yesterday’s blog started talking about how important collaboration is to eGRC issues such as privacy of information. I asked you to consider any kind of information breach and looked at why IT and legal will inevitably be involved and have to work together. I recently spoke to Barb Mosher about the Ponemon Survey and she wrote a great article titled: GRC Initiatives Critical, Yet Enterprise Strategy, Collaboration Lacking which outlines the key issues I have described in this blog series. Let’s now look at the other two key functions to get drawn in: operations and finance.

Operations in the firing line

The effect of a breach on an organization’s operations will very much depend on the nature of the breach and the organization’s business. As data-breach notification laws become more common, every breach will at least require customers to be informed — especially those customers directly affected. Many breaches will also have a direct effect on the organization’s ability to continue to deliver its products or services, whether because a network or website must be taken offline, product functionality must be reengineered, or a back-office process must be suspended until the issues have been investigated and remediated.

If an organization is lucky, any disruption to business-as-usual will be brief; but we’ve seen that it can take weeks to restore affected services, giving customers more to complain about and reporters and bloggers more to write about. Collaboration between IT and operations is critical to managing the timelines for service restoration or product remediation, and for the related task of managing customer expectations.

Customer (and media) communications following a breach are fast becoming a minefield for organizations, with the potential to explode no matter what they do. Pressure is mounting for notification to happen as soon as an organization becomes aware of a breach, whereas even a year ago it was not unusual for months to pass between breach identification and notification. This new demand is perfectly understandable: if private information relating to you has been compromised, you’d rather know sooner than later. But it means that organizations may not have time to understand what’s really happened before they have to tell customers; which in turn may necessitate embarrassing corrections as the picture becomes clearer. It’s really not unusual for the investigation of a breach to reveal that it’s more serious than the organization first realized.

If pressure continues to mount to speed up the notification process, it will become more vital than ever for IT, operational and legal teams to work together to clarify understanding across the organization of what’s known, what isn’t known, and what might be subject to further discovery and possible revision.

Finance in the command center

Ultimately, organizations need to know what the total financial implications of a breach are, because risk management is ultimately about weighing the cost to prevent a risk against the likelihood of it happening and the cost to the organization if it does. When a breach happens, the finance department needs accurate information in order to validate the organization’s approach in relation to this kind of risk, or to adjust it going forward.

Reporters will pounce on any movement of a company’s stock price in the days and weeks following a breach. If the price drops, it will be loudly proclaimed as a sign that the company’s brand has suffered as a result of the breach. We may never know how far that is true. Just as one cold winter doesn’t imply anything one way or the other about the reality of global warming, so a momentary stock price movement can’t really tell us anything about whether a company’s reputation has been significantly or permanently damaged. But in measuring the true financial cost of a breach, organizations do need to find ways to measure the effect on customer, investor and shareholder perceptions and behavior; as well as the more obvious costs of investigating, reporting on and remediating the breach, financing legal battles or settlements, and meeting the cost of fines or other sanctions.

To be able to accurately assess these costs, the finance department needs to be able to see and clearly understand what effect the breach is having on IT, legal, operations and other functions across the business.

So what department do you work for?

Thinking through the implications of any privacy-related incident, it becomes apparent that privacy is no longer (if indeed it ever was) purely a legal issue or an IT issue — no matter who is regarded as being its ultimate ‘owner’ from an organizational point of view. And as with privacy, so it is with most eGRC issues.

So the next time you need to talk to someone in another part of the organization to respond to an eGRC initiative, and someone asks what department you’re from, say you’re from the ‘legal unification department’ or the ‘IT unification department’ and your responsibility is to work across the organization to get everyone headed in the direction the organization as a whole needs you to go.

Further reading:
1. The Ponemon survey


 [S1]Or ‘My last blog’ or ‘Tuesday’s blog’ or whatever. And link to it.

Don’t we all work for the same company? – Part 1

By Alex Bender, Director, eGRC Programs and Strategy, EMC

Have you ever been in a situation of having to ask yourself: ‘Don’t we all work for the same company? Why can’t we work from the same playbook, speak the same language and head in a similar direction that gets us closer to the destination we’re all supposed to be aiming for?’

IT vs. Legal? Operations vs. IT? Finance vs. Legal?

Collaboration between divisions within an organization has never been more necessary. In fact, why do we call them divisions? It’s a divisive word; we should call them ‘unification departments’ and put people in charge of doing just that: unifying!

Why is unifying so important? Let’s take the example of information privacy. In a recent survey by the Ponemon Institute that polled over 190 eGRC professionals, it was found that the number-one owner of privacy issues in companies is the legal team, with IT coming in a close second. It was also found that collaboration is the number-one issue organizations have when setting out to achieve a goal or execute against a program such as privacy. Given the importance of such programs today, it’s never been more important for the teams that play a major role in achieving them to collaborate.

There are four key business domains that need to work together systematically to achieve eGRC objectives: IT, legal, operations and finance. Let’s stay with the issue of privacy to see why this is the case. I’ll cover legal and It in this blog; operations and finance tomorrow.

IT caught in the headlights

Think of any recent data breach to hit the headlines. The initial focus of news stories is on the number of people whose personal information has been leaked, the type of information leaked, and the technological or process failures that allowed the breach to happen (a security loophole exploited by hackers, third-party vendor negligence, a lost computer or other device holding data).

Internally, most of the initial action will probably occur in the IT and legal departments. Even if the breach isn’t a compromise of network defenses — maybe it’s due to an employee losing a backup tape or someone in operations inadvertently sending customer information to the wrong recipient — the incident may well highlight a failure of IT security policy and will have the department scrabbling to identify what happened and pull out all the stops to fix it and ensure that it doesn’t happen again.

Legal under the spotlight

Either in the same breath as reporting the breach, or immediately after, the news will be full of calls for more to be done to protect people’s rights to privacy. Opinion pieces will focus on how this breach will drive further regulatory activities relating to data protection and breach notification in the relevant country/ies or industry.

Internally, IT finds that it can’t just focus on the breach from a technological, process or policy point of view, but needs to be able to help the legal team figure out what’s happened from a compliance perspective and how the company must legally respond. As well as responding to regulators, legal teams will increasingly find that they need to defend their organization against official sanction as governments start issuing fines for data breaches. The legal ramifications of the incident may last for years as it becomes more and more common for lawsuits to be filed on behalf of individuals whose privacy has been compromised during a breach.

Further reading:
The Ponemon Survey

Next time:
Part 2 of ‘Don’t we all work for the same company?’

Unpicking the concept of eGRC

By Alex Bender, Director, eGRC Programs and Strategy, EMC

I was reading an article in The Economist today titled “Taking Credit”, which at one point says: “Rules are now in the works resulting from the Dodd-Frank financial regulation law which will require a bank, which would in the past routinely sell off 100% of a newly-originated mortgage, to keep at least 5% of it unless the customer, among other things, manages a down payment of at least 20%.”

How do you stay upright in a shifting landscape?

This sentence leapt out at me because of the words ‘Dodd-Frank’. Those words have a lot of banks and financial institutions wanting details that they’re not getting yet. They’re left filling in the blanks with guesswork while lawmakers are still drafting the rules of an Act that represents the most sweeping change to financial regulation in theUSsince the Great Depression.

This situation perfectly illustrates an all-too-common business challenge: how do companies position themselves as government regulators continue to assert control upon organizational practices through tighter regulation? How do they respond to an ever-shifting regulatory landscape without continually spending time and money that they can ill-afford? It’s even harder for companies that act on the global stage, which introduces more points of vulnerability and exposure. And no organization is an island; growing regulatory oversight makes demands on business partnerships that call for stronger controls within business relationships.

eGRC as a business strategy

It’s in response to these kinds of pressures that the concept of enterprise governance, risk management and compliance (eGRC) comes to the fore. In my previous blog I laid out my philosophy about eGRC; I said that eGRC is about an organization’s ability to manage enterprise risk and compliance issues as closely related strategic initiatives that have a direct impact on business objectives. I hold this view for at least two reasons:

Firstly, governance, risk management and compliance are clearly closely related issues. As such, taking a siloed or ad-hoc approach to them is highly likely to result in wasteful duplication of effort and spending, unresolved conflicts, and gaps in coverage.

Secondly, although eGRC first became a ‘hot topic’ with the passing of Sarbanes-Oxley, focusing too narrowly on compliance as the driver for eGRC ignores the potential for creating business value through improved decision-making and strategic planning. It’s only through a wider strategic approach to eGRC that organizations can change compliance from a burden — and one that can only grow as the regulatory landscape shifts about — into an opportunity to add value.

That’s why I believe that successful governance requires clear definition and communication of business objectives, not just applicable regulations, polices, procedures and standards. Managing risk requires identification, prioritization and remediation to protect the organization from excessive risk, but should also remove barriers to growth. And demonstrating compliance should not just be about the ability to prove adherence to laws, regulations, policies, contractual obligations and industry standards, but should be about assuring partners, customers and investors that their trust in your organization is well placed.

Collaboration and control

When you take a strategic approach to eGRC you also realize that it’s about multiple roles and responsibilities across the organization — legal, risk, audit, compliance, IT, ethics, finance, lines of business and others — working with a high degree of collaboration to provide visibility and control. It’s about sharing information, assessments, metrics, and responsibility for dealing with risks, investigations and preventing losses. It’s about recognizing the complex nature of risk and compliance in today’s distributed business environment and being able to understand and manage this complexity. These themes are explored in an EMC paper that gives a great overview of the emergence of eGRC as a strategic business imperative and what you should be thinking about in addressing eGRC. I’ll also be further addressing them in my next two blogs.

Further reading:
EMC white paper: Enterprise Governance, Risk and Compliance: A New Paradigm to Meet New Demands

Next time:
Don’t we all work for the same company?

What have years of exploring eGRC taught us?

By Alex Bender, Director, eGRC Programs and Strategy, EMC

Those of you who know me from the world of enterprise governance, risk management and compliance (eGRC) will know that I have a particular view of eGRC, which is rooted in what I’ve learned from the hundreds of customers I’ve worked with over the course of my career. For those of you who don’t know me, I’d like to introduce myself by sharing my overall philosophy with you and giving you an idea of what I want to achieve with my blogs.

eGRC: led by technology or strategy?

There are many vendors who are using the phrase ‘enterprise governance, risk management and compliance’ as a catch-all to create a market for their technologies. Let me put my stake in the ground: eGRC can’t just be about technology. To be effective, it needs to be a tightly woven strategy for leveraging people, processes and technology to achieve business objectives.

Specifically, we’re talking about business objectives shared predominantly by four enterprise domains: IT, finance, operations and legal. Focusing on technology is not a bad approach, but is myopic when considering how people and processes across the enterprise need to be engaged in the program.

Is your organization struggling with eGRC silos?

Here are some typical indications that your organization hasn’t yet taken a strategic approach to eGRC:

If you’re in IT, do you find yourself thinking: “I’m so busy with day-to-day IT activities, I have no idea whether my role provides business value; I just hope it does”; or “I work in IT; how can I truly affect our business objectives or increase shareholder value”?

If you’re outside IT do you find yourself thinking: “the key objectives on my plate don’t pertain to IT. Sure I use systems, applications and devices; and IT is great at supporting me. But when we’re opening a new site or trying to launch a new product, IT gets in the way.”

If you’re outside IT and engaged in some form of risk management, do you believe something like: “For me to do my job in the financial risk management group, IT needs to do what IT is meant to do…serve us!”

In most cases, views like these indicate a complete disregard from senior management for the importance of investing in both top-down and bottom-up eGRC objective-setting. They reflect a lack of visibility of how the work of different business functions links together — or should link together — to drive towards the end game. They show a distinct lack of collaboration, which is a theme I’ll return to in later blogs. This is particularly evident in the view of IT having no strategic role to play in risk management, which is isolationist (and in many cases egotistical) thinking that just gets in the way of the business achieving its objectives.

Or are you doing it right?

For those of you who do know me and have already taken the initiative within your organization to transform your business, much of what I’ve just described has already been sent to the waste-basket or kicked to the corner. I know so many companies who’ve done it right and who are well on their way to true strategic and collaborative eGRC across the domains of IT, finance, operations and legal. And when we asked Ovum to research the status of eGRC across seven countries in North America and Western Europe, their results agreed.

eGRC is personal

The great thing about this approach is that the people I’ve worked with have created an amazing upward professional path for themselves and can point to their eGRC efforts as game-changing in their career. Ultimately eGRC is all about you! It’s about enabling you to have the right visibility and control so that you can make better decisions, act faster and ultimately spend less.

eGRC is about trust

I look forward to sharing with you many of my stories and will hopefully provide a forum for us to really get things out on the table. I would like this blog to be about trust. Trust between you and me. Trust that we can agree to disagree. Trust that when I’m wrong, you’ll be constructive in your feedback. Isn’t that ultimately what eGRC is all about? Trust.

GRC Resources:
EMC eGRC resources

www.emc.com/grc
RSA eGRC resources  

http://www.rsa.com/node.aspx?id=3732

Next time:
Unpicking the concept of eGRC