eGRC Summit – June 5-7 in Chicago!

Archer GRC Summit

I have participated in the the RSA Archer eGRC Summit in the past and have seen first hand the value of bringing over 600 GRC professionals together under one roof to discuss best practices, learn from each other and also have a great time. I have just submitted to speak at the conference and hope to see all of you do the same.

You can submit your presentation idea here.

Hope to see all of you there this year.

Advertisements

‘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

Creating consistent processes for eGRC: a negotiation about change

When you’re trying to integrate and align governance, risk management and compliance, where do you start?

With processes.

This has been one of the hottest topics that the RSA Archer eGRC Community has been discussing during the recent eGRC Roadshows that I have been extremely honored to be a part of this fall. The conclusion that organizations have all agreed on is that you need to identify the key processes across your business that relate to enterprise GRC activities, find the commonalities and intersections, and make changes as necessary to create consistency across them.

This is both easier and harder than you might think:

  • It’s easier than you might think because the majority of GRC processes across the business will mostly be very similar to one another. People will use different names for things and think that they’re doing something very different from others, but in terms of underlying principles and steps, they mostly won’t be.
  • It’s harder than you might think because people won’t want to change what they’re doing. Even if it’s just a name change, eg changing an ‘incident’ to be called an ‘issue’, people will fight hard not to change what they’re used to. Processes and their naming conventions can be really personal; they frame how people think about what they do. If you ignore this and try to be dictatorial about process change, you’ll be in for a hard time. To illustrate my point I present to you two examples of pretty much the exact same process for both ‘incident’ and ‘issues’ management. As you will note, the only thing different is what you call each stage of the process. 

Issues Management Process

Incident Management Process

 

 

 

 

 

 

 

 

Negotiate change

So when you’re setting out to break down GRC silos and create common processes, you need to allow plenty of time to negotiate process change. The role of a GRC advocate or leader is to orchestrate this negotiation, not impose change on people. If you want to be successful you need to help people to their own conclusions about why the change is necessary and not as bad as they think.

This applies even if you’re just changing the naming conventions (taxonomy) associated with processes (I’ll cover taxonomy in a bit more detail in my next blog). It applies even more so if you’re improving a bad or mediocre process, ie making actual process change. Process change is important if your processes don’t reflect best practice, otherwise the danger is that the improvements you make through eGRC will just make mediocre results happen more quickly.

So to reiterate, every eGRC project should:

1. Start with process.

2. Create consistent eGRC processes across the business.

3. Improve poor or mediocre processes.

4. Negotiation change in Taxonomy.

Why GRC matters to IT security teams

 

 

 

 

 

Expectations of IT security have never been higher. I talked about this a bit in my last blog . But if you don’t believe me there’s a great paper by Enterprise Strategy Group (ESG) that nicely sums up why businesses are calling for much more sophisticated, business-oriented approaches to IT security. You can find it here (look under ‘white papers’ in the right-hand navigation area)

So if you’re in charge of IT security in your organization, what do you do to meet these expectations?

If you said ‘convince the business to invest in eGRC’ then you’re ahead of the innovation curve and are taking your program to the next level.

What happens without eGRC?

Organizations that haven’t invested in eGRC are typically mired in manual processes, trying to manage security using Word documents, spreadsheets and email. They can’t connect anything to anything and have to duplicate work all the time. One IT security manager told me that his team asks the operations team to answer questions specific to FFIEC regulations in January; and then in February asks the same questions of the same people for the purposes of SOX compliance.

This kind of thing is happening in a million different ways all the time. A recent article from Computerworld, titled “Feds want uber cybersecurity compliance standard”, illustrates this as well.

It quotes Jerry Archer, CISO at Sallie Mae, who is presenting his IT-GRC strategy at the RSA Archer eGRC Roadshow in Indianapolis tomorrow (October 13). Speaking at the SINET Innovation Summit in Boston, Jerry said his agency spent 40% of its budget on complying with regulations. “What is needed is automating compliance to reduce the bite it takes from the budget,” he said.

The kicker is the response that Jerry’s remark got from Josh Corman, director of security intelligence at Akamai. He congratulated Jerry on the 40% figure, saying: “For some it’s 100%.”

The article goes on to note that “the trouble with regulations is that they drive security architectures and prevent data loss that may have little real impact, while ignoring thefts that could be devastating.”

What happens with eGRC?

So how does GRC help? For one thing, it helps you automate compliance processes and efforts so security teams can focus attention, budget and strategy on the threats that truly matter to their business.

Organizations that have invested in eGRC (assuming they’ve adopted best practices and made careful strategy and technology choices) can:

  • Automatically map policies, control standards, control procedures, authoritative sources and assessment questions to one another and see the relations between any and all
  • Track the whole life-cycle of security incidents, reliably prioritize incidents in line with business impact and objectives, automatically assign actions to respond to incidents, and report on incidents in a way that provides meaningful business context to senior management
  • Identify gaps in compliance and satisfy common compliance requirements with a ‘one-to-many’ approach

I’ve said it before and I’ll say it again: eGRC is about enterprise-wide collaboration, visibility and control. It’s time for IT security functions to lead the charge to achieve these things. Not only is it the only way to deliver value to the business, but it will make life so much easier for you!

Recommended Reading:

The ESG Information Security Management Maturity Model, a paper by Jon Oltsik, Senior Principal Analyst, ESG (July 2011)

The pressure’s on for IT security

Pressure is on for IT Security

 

 

 

 

I was speaking to a board member of a large investment advisory firm recently about his expectations of the company’s IT security function. He said: “I just need to know that our data is protected, that IT risks are tied back to the business, that we can maintain the continuity of our business operations, and that we can effectively manage our regulatory risks.”

No pressure, then, right!?

The fact is, a lot of senior management teams and boards are getting wise to the fact that they need more closely linked security, risk management and compliance activities. This is why IT security is linked to GRC and their relationship is so important from both a top-down and bottom-up perspective.

Here are some more expectations I’m hearing from C-level executives and board members:

  • We want to understand how security events, and our responses to them, tie to our risk profile and remediation efforts at the enterprise level.
  • We want to know that our security/IT risk assessments are clearly connected to, and consistent with, our enterprise risk assessment processes.
  • We want to understand how security risks are developing so that the future doesn’t take us completely by surprise. And to minimize the chance of a ‘black swan’ event.
  • We want to be able to put meaningful metrics against security risks and controls; and define key risk indicators, key compliance indicators, key performance indicators for our security team.

In the end, GRC matters to IT security functions because to meet these expectations you need a level of visibility and control, top-down and bottom-up, that only a sustainable eGRC program can deliver. I’ll take a brief look at what eGRC can mean for IT security in a follow-up blog.

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

Business continuity as an element of GRC. Is there really any debate?

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

Is GRC business continuity’s future? This is a question posed recently by Continuity Central, an information portal for business continuity.

It won’t surprise you to hear that I’d give that question a resounding ‘yes’ and that I consider this market trend to be a positive thing. What is also encouraging is that  the majority of respondents over at Continuity Central agree with me.

I’m tempted to say that the answer is so obvious, there’s nothing to debate. But maybe that’s because I’m looking at it from the enterprise GRC perspective. An integrated approach is, after all, the whole rationale of enterprise GRC as a discipline. How can you claim to have an effective eGRC program if you don’t have plans to ensure the continuing operation of your business in the face of events that threaten to disrupt it?

Will integration destroy business continuity?

Maybe it’s not so clear if you look at it from the perspective of business continuity professionals. Maybe you don’t see what’s to be gained by ‘submersion’ of your discipline within a larger eGRC discipline and paradigm. For those commenters at Continuity Central who think that it would be a negative thing for business continuity to become an aspect of GRC, there seem to be two main worries:

  • Some fear that integration would make it harder to serve the specific needs of business continuity with the specialist skills it requires. One commenter expresses it in this fashion: “BCM is a specialist subset of risk management that should be highlighted, not submerged under some generalist classification.”
  • Some believe that GRC doesn’t work and would therefore be toxic to the established principles and practices of business continuity management. One commenter expressing this view says that the standard risk methods are based on flawed assumptions; and he or she asks: “Why not ‘governance, continuity and compliance’?”

Integration is not dissolution

To me these aren’t real objections. In my experience it’s just not true that integration of different disciplines has to make any of them less important or specialized. Nor would I ever recommend an approach that doesn’t preserve best practices within individual sub-disciplines of eGRC.

That’s why I think it’s important to leverage a single eGRC technological platform with the flexibility to have individual solutions built on it for the many functions of eGRC. The whole idea is to preserve the specifics of each function — such as business continuity management, policy management, incident management, compliance management, vendor management, etc — while at the same time giving you the visibility and control to do it all more efficiently and effectively with cross-functional relationships, workflows and reporting across all functions.

As for fears about the effectiveness of eGRC, clearly there are good and bad ways to approach any discipline. Those of us who’ve spent years developing the theory and practice of eGRC think we know quite a bit about how to do it well. And I’ve seen the difference that an integrated approach can make, including for business continuity management. If you keep an eye on this blog, I’m planning to bring you a case study that illustrates the benefits of applying the best practices of eGRC to business continuity management and how BCM can be tied to the broader risk function.

Why not governance, continuity and compliance?

For those who ask why not governance, continuity and compliance, to a certain extent it’s a matter of how we define our terms. The diagram below comes from an EMC paper on business continuity.* As it illustrates, we see risk management as concerning itself with more than the subset of risks dealt with by business continuity management. For example, if you’ve translated financial risks into IT, operational or legal terms, the information and activities that result from this financial risk management would extend beyond business continuity initiatives.

 

If you widen the meaning of the phrase ‘business continuity’ enough, so it means something like ‘successfully continuing business’, then you can see it as overlapping a lot with risk management.

But really, risk management as a discipline is much more than business continuity, especially if you use the Enterprise Risk Management – Integrated Framework from COSO(the Committee of Sponsoring Organizations of the Treadway Commission) as the foundation of your risk management program (see diagram below).

However you choose to define your terms, my point still remains that a siloed approach to any continuity/risk management discipline is not the way forward. And again, watch this space for a case study that illustrates this beautifully.

 

Recommended Reading:

* Getting Your Business Back: Pulling Together Business Continuity, Crisis Management and Disaster Recovery, an EMC Consulting paper

A General Lack of Compliance Cooperation – Article Post

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

Recently I had a discussion with Mike Vizard who is one of the leading reporters on GRC and how IT works with the multiple domains across the organization. He wrote an article titled: A General Lack of Compliance Cooperation. In the article he presents some of the recent findings in a recent survey/study of over 191 GRC practitioners from the RSA Archer eGRC Community.

My favorite finding in the article is that it is clear that risk assessments, policy management and controls assessments are widely implemented. Through my countless interactions with enterprises around the world these elements are essential in implementing a solid eGRC strategy. Top companies implement these core GRC elements to also monitor, assess and validate 3rd party organizations adherence to policies and to uncover risks. As he pointed out…monitoring 3rd party risks is one of the key issues that companies are dealing with today and the companies who are not doing it are in jeopardy.

I urge you to read the article and download the survey from The Ponemon Institute.

EMC and the Ponemon Institute will also be presenting the results of the eGRC and Privacy Management Survey during a webcast on July 12th at 10am Central US. Click here to sign up and I look forward to all of you asking Larry Ponemon questions as well as participating in our webcast polls.

What the board of advisors really want from IT

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

As many of you know the Gartner Security and Risk Summit was held this week in Washington D.C. at the Gaylord National. The event was excellent with many great sessions/discussions on business continuity, privacy in the enterprise, advanced persistent threats and security in the cloud. One of the best session was held on Wednesday titled: Enterprise and Operational Risk Management: What the Board Wants which was moderated by Dale Kutnick and French Caldwell. In this session there were 4 board members representing different perspectives due to their past experiences as well as the industries they serve. The concept was to provide the members in the audience, comprised mostly of IT professionals, a chance to hear what the board perceives as the value of IT to an organization and the information that IT needs to provide a board to make strategic decisions.  Here are a few highlights as to why I thought the session was so great:

During the session a poll was given to the audience that provided real-time feedback capability via text. There were over 110 people in the audience that responded to the question: What IT risks should be communicated to the board?

The category and results of the poll were very revealing:

  • Data Protection – 30%
  • IT Risk to the Business Strategy – 23%
  • Continuity of Operations – 21%
  • Regulatory Risks – 16%
  • IT Investment – 5%
  • Mobility Risks – 4%

I interpret these results in a variety of ways. The most obvious is that the fact that data protection topped the list is due to the numerous privacy issues that have dominated the world over the last several years and that IT thinks too much about ……. well IT. Shocker right? The conversation that ensued was that the board didn’t think that data protection was the top issue. They wanted to know about IT risk to the business. In fact one of the board members stated “is our data backed up and protected? Great…that is your job and that is all I need to know.” They also mentioned how IT wants to talk speeds and feeds about how they protect data and the board could essentially care less. All the board wanted to hear was how IT protected data to keep the name out of the headlines which brings me to the following two additional observations which are…

  1. IT Wants to Talk about the Complexities of Their Job vs. Providing Business Context: One of the board members stated they don’t care about the complex nature of how data are stored, the technology behind securing the data and what the day-to-day tasks are in IT. There is a huge language barrier at play and it has existed over the last 11 years that I have been in security, risk and compliance industry which is we always want to make things so complex/complicated. IT leaders need to put their responsibilities and organizational efforts in simple terms that mean something to the business decision process. The organizations that address the language barriers between IT and the business are starting to be the most successful in their approach to solving real problems for the business.
  2. Top Down vs. Bottoms Up Approach: Organizations as a whole that take a top down approach to driving awareness in the organization on security, risk and compliance issues are the ones that struggle the most. A bottom up approach is needed. If everyone in the organization embraces and understands the risks then the company as a whole will be able to manage, mitigate and preempt risks more efficiently. In many cases avoid major risks all together. This is where an extremely powerful training and awareness program can make or break a security, risk and compliance program. Also when you couple the training program with a simple yet effective communication program you can gain critical mass with your most valuable assets….your people.

I recommend to everyone in IT to seek out all the material you can on what a board wants to hear about and how to understand the value that IT brings in business terms. Also, know how your organization can work with the leaders in business to deliver against the broad set of corporate objectives and not think so much about the complexities of IT. Because if you align IT to the broader set of strategic objectives that are important to the enterprise and communicate the value and risks effectively you are actually delivering what your boss and the board really wants.  I also recommend the board of advisors for all companies start learning more about the value IT can bring vs. thinking “it is too technical”. You are supposed to be a smart set of individuals and want to ensure shareholder value is increasing. By learning more about technology and what IT is doing to support the business you will fund it appropriately and appreciate that part of the business a lot more that you do today.

Recommended Reading:

Bridging the CISO-CEO Divide

Ponemon Institute Research – The Role of Governance, Risk Management & Compliance in Organizations