Yo Delmar's GRC and Beyond Blog

GRC Framework - Stable Stakes for Good Management

Why a GRC Framework?

Good governance, risk, and compliance management has become a key-operating imperative for many organizations, both large and small. Boards and executives alike struggle to gain better visibility into their true risk and compliance profile in order to prioritize spending on remediation of risks. Having a coherent, integrated GRC management framework is table stakes for good GRC program management – and can really accelerate an organization’s ability to respond to increased pressures to gain real visibility into its true risk and compliance profile.

A Simple Framework

Here’s a simple diagram (well, maybe not so simple….unless you just look at the headings) that covers the main elements of GRC Framework.

Let’s look at each of these layers and try to get at the essential elements and value:

1. Organizational Framework and Governance model – An active governance structure that drives accountability into the day-to-day operating fabric ensures business owners have the proper degree of granular visibility into risks that really matter.  Armed with options on what to do about them, business owners can make intelligent decisions on what remediation efforts to fund. 

2. Risk Profile and Reporting Framework – A set of rationalized processes for the prioritization of key risk and compliance requirements supports GRC reporting across the organization, and to the board. A practical categorization of risk types, threat communities, information, and data classification brings context to risk reporting and decision-making. 

3. GRC Diagnostics – Qualitative and quantitative assessments that follow a common risk and compliance identification and analysis process, supported by consistent controls reviews and testing, provide objective diagnostics required for meaningful decisions on treatment strategies.

4. Risk and Compliance Monitoring Program – Monitoring policies, controls, threats and vulnerabilities against standards and acceptable thresholds provides visibility into risk and compliance profiles on a consistent basis. Key Performance Indicators (KPIs), Key Risk Indicators (KRIs), Key Control Indicators (KCIs) provide early warning alerts that permit organizations to be proactive in their response.

5. GRC Program Optimization – Continuous improvement, communication and awareness programs drive adaption as the external environment presents new and emerging risks and compliance requirements.  Knowledge sharing across stakeholders on the appropriate best practices supports evolution to a target maturity level that is optimal for the organization.

6. Technology Enabling Platform and tools - A technology eco-system that supports a central, secure repository of requirements, policies, control standards, risk analysis, and control test results provides a solid foundation for streamlined workflow, analytics, and reporting.

A well-designed and coherent GRC Framework helps organizations prioritize and respond to risks and compliance requirements with a collaborative and efficient governance process.

Call to Action: An exercise I often use with clients is reviewing the framework, element by element, and marking it up with red, yellow and green to see where your organziation is weak – and then looking at what elements will be key enablers for your GRC Program. Using a GRC Framework model in this way helps prioritize what you need to focus on now in order to deliver real value.

Try this: Review this GRC Framework (or something like it) with some of your key stakeholders and get their assessment of what’s truly important, what they would like to see good progress on, and how they can help. At the very least, you’ll get another perspective on priorities and needs - that will keep you driving your GRC program in the right direction.

 

GRC and Risk Appetite formulation – A critical skill that executive management must develop to thrive in today’s climate.

If there is one element of a GRC framework upon which all else depends, it is the correct formulation of risk appetite, and the translation of appetite into tolerances, thresholds and limits that the organization must operate within. Without this, it’s simply impossible to manage risks effectively.

Risk appetite can be defined as the quantity and types of risk that an organization is willing to assume in pursuit of its strategic objectives.  Boards are typically responsible for setting risk appetites, and executive teams then implement them into the business by translate those appetites into more granular risk-taking limits within the most fundamental operating processes.

This is a huge challenge, and most organizations struggle to do it effectively. Those who do it well know it is a bit of art, a bit of science, and a mix of qualitative and quantitative approaches.

Everything depends on the right formulation of risk thresholds –policy, controls and ultimately, what is expressed as a risk, or not.

However - with the right collaboration, and properly managed process, risk appetite and thresholds can be defined.

GRC teams can work with executive and management to establish meaningful thresholds, or tolerances of acceptable loss, compromise, disruption, disablement of key material business processes, people, or information.  Tolerances describe, in tangible terms, the limits around which risk and compliance teams can manage their efforts.

Risk Appetite sets the bar – and the buck stops at the bar. You’ve got to work with the business to understand how much risk is the organization willing to take in a particular area.  How high is the bar? Once set, policy, controls and reporting can be calibrated to feedback the right indicators that allow management to make decisions to avoid, treat or transfer risk – efficiently and effectively.

Risk Appetite Definition

• The quantity and types of risk that an organization is willing to assume in pursuit of its strategic objectives.

What you can leverage

• Organizations tend to be fairly good at understanding thresholds in a few critical categories, such as financial liquidity requirements or business resilience and availability thresholds, which are typically defined in terms of business impact of disasters or service interruptions.
• Regulatory compliance thresholds have been formalized through control standards by Regulatory bodies and Professional Standards Organizations.
• Leverage expertise gained in these processes to build competencies at the next level.

What you need to do

• Clearly state the amount and types of risks that the organization is comfortable taking.
• Define maximum tolerable limits, both qualitative and quantitative, based on stakeholder expectations, constraints and strategic objectives.
• Identify actions that need to be taken when the organization’s’ actual risk profile is outside of tolerances.

What to watch out for

• Risk appetite and thresholds being set by security and risk analysts, rather than the board and business executives.

Risk tolerance calculations ensure that the organization is able to adhere to adopted risk appetites and implement the right escalation procedures. Utilization of Key Performance Indicators (KPI’s) and Key Risk Indicators (SRI’s) help risk and security teams understand how the organization currently assesses risks to the business. 

Call to action: Find out how your organization formulates risk appetite and thresholds, and build that process into your GRC framework. 

 

Risk Framework: Managing Content – What’s the best practice governance process?

The last two posts have dealt with Risk Ontology, why we need one and what it contains; and Risk Framework – what it contains, and five key steps to get started. This post is about how to manage that information once it is defined.

What’s the best practice process and governance for managing a Risk Framework?

Managing updates to the Risk Framework can be a bear if you don’t have good governance around that information once it is defined.

Basically, we have three phases to the process, outlined below. Many GRC Technology platforms (shameless plug, yes, RSA Archer does this) support this type of process, but word of caution: you still need to define the Risk Framework that makes sense for your organization, and work through the step by process for each stakeholder community, and of course, train people on it, and implement the governance process to support it.

1. Risk Framework – That’s what we talked about last post – With the Stakeholder Community, define the risk hierarchy of classes and types, identify risks through residual rating, and associate metrics to risks.
2. Risk Remediation – For all risks with an inherent risk that is above the threshold, go through a remediation cycle. Some of these activities will be part of a regular risk assessment – but need not be.
3. Content Review - Use the Stakeholder Community as a Review Board for Risk Content. New risks will emerge through audits and assessments, so make sure you have a regular review and governance process in place to accept new risks into the framework, and prune risks that are no longer relevant for your organization.

If you follow this type of best-practice process, you will go a long way to implementing a GRC ontology that gives your organization the visibility and control of risks that really matter.  

Risk Framework: Five Easy Steps (yes, you can try this at work)

Last post, we went into what a Risk Ontology is, why we need one and what it contains. In this post, we look at Five Easy (some may say not so easy…) steps to get started. Remember that core to GRC is adopting a coordinated, coherent approach to risk management across the organization, built on a common risk ontology. And, at the core of a risk ontology, is a risk framework.   

Quick review: Risk Frameworks provide risk management programs with better:

• Coordination - Provide a basis for coordinating risk across  many activities in the organization

• Consistency - Since all activities across the organization involve risk, a Risk Framework can be consistently applied to an entire organization, at its many functions, projects and activities

• Visibility – While no single definition of risk exists, adoption of consistent concepts within a comprehensive framework can help the organization improve visibility into the true risk profile

• Governance – Risk Frameworks can help the organization establish governance and manage risk more effectively, efficiently and coherently both internally and externally with 3rd parties

• Flexibility – A Risk Framework, probably designed, can support variations of approaches, definition of threats and risk criteria across internal organization functions, partners and customers

• GRC Technology Platform Value – Risk Frameworks are essential for driving value out of GRC technology platforms and enabling tools; they are only as good as the underlying frameworks, processes and procedures that define their use.

What’s in a Risk Framework?

Here is main things you want to get defined in a risk framework - this is a subset of the GRC Ontology; the core or ‘engine’ of risk management.

1)       Risk hierarchy; which includes Class and Type
2)       Mitigating Controls (and procedures)
3)       Risk Scores, and
4)       Metrics. 

Risks Scores (inherent and residual) will come as a by-product of assessments and can change.  

What are the key steps to follow in building a Risk Framework?

The diagram below shows five easy :-) steps to follow in building a risk framework. Step 1 is pre-work – you need to get a skeleton defined of risk classes and types, and gather as much as you can from stakeholders. The holes in the hierarchy should become apparent during step 1.  In steps 2-4, work with key stakeholders to further develop the hierarchy, and associate risks with policies and mitigating controls, risk scores and metrics if you can. At the end of the process you should have a reasonably good ‘tree’ and eliminated overlapping or redundant risk and controls. Top tier risks, those with High ratings, will surface to the top of the hierarchy. You can use those to recalibrate metrics to ensure you are focusing on the right things. Active risks in the framework become part of your organization’s risk register.  Most all GRC technology platforms automate this process, and the mappings between essential elements (shameless plug: RSA Archer’s Risk Management solution does this well)

Next post, we’ll show a best practice governance process flow for updating content in a Risk Framework. 

 

GRC Fundamental Component: Risk Ontology

At the heart of GRC is adopting a coordinated, coherent approach to risk management across the organization, and core to that objective is developing and adopting a risk ontology.

What is Risk Ontology?  
In the information sciences, ontology “formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts. It can be used to reason about the entities within that domain, and may be used to describe the domain”.

Some people think of ontologies as simply a nomenclature – but an ontology is much more than a shared index, vocabulary or taxonomy.  A Risk Ontology, for example, would include a model with the definition of objects and concepts, and how they relate to one another.  It would include rules about how concepts interact, and provide a basis for calculations and analytics.  It would provide a basis for establishing consensus on the meaning of risk terms, and a model that explains their use.

Organizations manage risk by identifying it, analyzing it and then evaluating whether the risk should be modified by risk treatment in order to satisfy their risk criteria – those concepts, and definitions of risk criteria – most importantly appetites, thresholds, rating schemes – can be part of a risk ontology shared by everyone.

Why do we need Risk Ontology?
We need Risk Ontologies to provide a basis for coordinating risk across the many activities in an organization:

• Since all activities across an organization involve risk, a Risk Ontology can be consistently applied to an entire organization, at its many functions, projects and activities
• While no single definition of risk exists, adoption of consistent concepts within a comprehensive framework can help organizations can improve visibility into the true risk profile
• Risk Onotologies can help organizations establish governance and manage risk more effectively, efficiently and coherently across an organization and externally with 3rd parties
• Risk Ontologies can support variations of approaches, definition of threats and risk criteria across internal organization functions, partners and customers
• Risk Ontologies are essential for driving value out of GRC technology platforms and enabling tools; they are only as good as the underlying frameworks, processes, and ontologies that define their use.

What does Risk Ontology contain?
A complete Risk Ontology would contain:

• Objects: These are the basic ‘objects’ – a person or thing found across your organization – for example, an object may be a person – a risk or control owner, or technical steward. Or on object may be an specific risk determined by applying risk criteria to potential events and consequences: a MEDIUM risk exists that intellectual property associated with the Aurora Project will leak from the Sharepoint site due to absence of data loss prevention policy and controls.
• Classes: These are concepts or types of objects – for example, reputation risk, strategic risk, financial risk, security risk, technology risk, health and safety risk, and so on. A very important class is the Risk Register – a list of all risks of importance to the organization. Classes might also include role, process, information, policy, control, asset, threat, vulnerability, and impact or treatment types.
• Attributes:  These are aspects, properties, features, characteristics, or parameters that objects (and classes) can have – for example, risk criteria such as a risk source, or criteria such as appetite, or a consequences such as a likelihood or impact rating.
• Relations: These are ways in which classes and individuals can be related to one another - for example, a threat source has a relationship to specific vulnerabilities.
• Function terms: These are complex structures formed from certain relations that can be used in place of an individual term in a statement – such as a risk equation, R = Likelihood x Impact, or R = Severity x Frequency.
• Rules:  These are statements in the form of an if-then (antecedent-consequent) sentence that describe the logical inferences that can be drawn from an assertion in a particular form – for example, if a regulation xyz applies to our operations in country, we must abide by it.  Or, as a specific output of a risk equation, rules may look like earthquake strikes our California operations there is a high likelihood that our mission critical processes for order to cash will be impacted for 3-5 days at a cost of $1m revenue per day. 
• Events: These are the changing of attributes or relation – for example, geo-political events effecting the threat landscape, economic indicators, exchange or interest rates.

How Do I start to create one?

Use your governance structures and processes to help you with developing a strong Risk Ontology, which may take many months to fully complete. Start with the very basics and work outwards from there. It takes real collaborative work, but you really can’t get to value-based GRC without it.  Set up working sub­committees of your Risk Councils to get the right people involved with this important work. Some of the core questions that have to be addressed are below. Over upcoming posts we’ll go into more detail about practice models and best practices to leverage in doing this.

• How is risk defined and calculated in each business unit and for each discipline?
• How do you aggregate risk across activities?
• What best practice frameworks are being used now for enterprise or operational risk, compliance, legal, audit, privacy, IT, security or business resilience?
• What are the key entities, attributes, relationships & constraints for risk and compliance?
• What are the key risk sources, criteria and consequences for risk?
• What metrics are required by each stakeholder group?
• How will these metrics be shared/leveraged by other programs such as Operational Risk Management, Audit, Legal, Privacy and Enterprise Risk Management?

Why do we need GRC? Five Forcing Functions - Video!

Why do we have governance, risk, and compliance? Many write it off as a marketing term, assuming there is no need for it in organizations that already have internal audit, enterprise risk management, and information security. Oh, if it were only that simple…

Rather than write an extensive post on the subject, let’s try something a little more interactive – a video! Here’s my input on why GRC is so important supported by an overview of the 5 forcing functions of governance, risk, and compliance. Enjoy!

 

GRC Forcing Function: The Digital Universe

EMC has been sponsoring the annual IDC Digital Universe Study for five years – and we’ve been saying the horrendous growth in information is one of the main Five Forcing Functions driving growth and adoption of GRC. The 2011 Digital universe Study is in – and the numbers will shock you. Here's a taste:

• Digital information in the world is doubling every two years.
• In 2011, the amount of information created and replicated will surpass 1.8 zettabytes (1.8 trillion gigabytes) - growing by a factor of 9 in just five years.
• Growth is not keeping pace with staffing - by 2020 we will have only 1.5 times the number of IT staff we have today.

Trust, which is really shorthand for GRC, is a big factor here.  The amount of information that needs to be secured is growing faster than our ability to secure it. When we consider the ‘digital shadow’ – how personal information is expanded through mobile device apps and social networking – not to mention corporate information that is stored, replicated, and transformed - it is even more difficult to manage privacy and protect sensitive information – we simply don’t know where it all is.  At the same time, online data collection is on the rise as we move into a world where analytics and big data can be the difference between knowing your customer, or not.

 What to do?

• First of all, read the study.
• Second, get started with Information Governance and Classification policies and schema and build this as a foundation of your GRC program. Understand what information, structured or unstructured, is sensitive, and build automatic or user driven classification into your information landscape as much as possible.
• Third, conduct an Information Risk Assessment leveraging technologies that scan for information by keywords and see where it resides, and where it is moving. You’ll be surprised by what you find.
• Fourth, start enforcing policies at the point of use with technologies for data loss protection, blocking sites and other “Information taming” technologies that drive down the cost of creating, capturing, managing and storing information.
• Fifth, build Information Governance and Assessments into the operating fabric of your organization – regulators, employees and customers are beginning to demand that you demonstrate you are in control of corporate and personal information privacy and protection.

Digital Information is going to continue to grow. As an industry, although we’ve come a distance in driving down the cost of creating, capturing, managing and storing information—one-sixth the cost in 2011 versus 2005 – we have a very long way to go.

 

Privacy and GRC – What the New Ponemon Study and the GAPP is Telling Us

Many organizations get their first taste of the promise and power of a GRC program when they begin to implement a Privacy Program. Why? Because privacy is an enterprise issue that spans legal, IT, compliance and business operations. Privacy regulations vary by jurisdiction, and at times may be in conflict.  In fact, privacy regulations are expected to get tougher, with additional breach notification requirements. With the increase in cloud computing, mobile devices and social networking, we are seeing growing demands from individuals and governments that organizations proactively build in ‘Privacy by Design’.  Privacy is a core GRC use case that is broad in its application, constantly evolving, delivered through many channels, and as a result needs to be managed as a program. 

Ponemon Survey on eGRC and Privacy

Surveying one of the largest eGRC practitioner communities at the RSA Archer eGRC Summit recently, a new Ponemon study reveals that “as eGRC continues to emerge as a top C-Suite priority, only 20% of large organizations have a clearly defined eGRC strategy that pertains to the entire enterprise and 33% admit they have no clearly defined eGRC strategy at all. Regardless of their industry, all organizations report that managing privacy regulations by geography and in accordance with country or state laws are a driving factor in their organization’s move to an integrated program that supports IT, Legal, Operations and Finance.  Respondents identified their top two privacy challenges as 1) ensuring data shared with third parties will remain safe and secure and 2) complying with all appropriate regulations.”

 If you want to see more about this, read RSA’s press release on the topic here.

Managing Privacy as a part of a GRC Program

Privacy programs have multiple facets, all of which fall into fundamental processes in GRC. Building common processes such as policy management, incident management and risk assessments to support not only privacy, but your other GRC challenges, make sense, creates efficiencies and provides an integrated foundation for managing risk across the enterprise. Here are some of the basic elements of a Privacy Program – all of these can be shared with similar programs such as security, regulatory compliance or controls testing.

• Policy Management from life cycle management, through communication to personnel and third parties
• Personal Information identification and classification
• Risk Assessments, to identify real exposures
• Privacy incident and breach management
• Training and Awareness of privacy policy and controls
• Choice and Consent in the collection of privacy information
• Use of private information for an identified purpose
• Retention and disposal of privacy information
• Access to, physical and virtual, and protection of privacy information
• Monitoring and Enforcement of privacy policies and controls

What can you do now?
If you are finding this a bit overwhelming, know that there is quite a bit you can do now to get started on building a strong, integrated Privacy Program. If you want to get some insight into the maturity state of your privacy processes, check out the Generally Accepted Privacy Principles (GAPP) from the IACPA here. 

What you are likely to discover is that beyond the program itself, you will need technology to help you manage such a broad spectrum of requirements. Yes, you’ll probably need an open GRC platform that can manage the collaboration privacy policy development, dissemination and attestation requires, and the automation of controls testing – through continuous controls monitoring or questionnaires.  Privacy management is supported by most GRC platforms (see RSA Archer here as an example) that do a great deal to help monitor risk and compliance related to the use of personal information.

What is for sure is that privacy challenges are NOT going away. They are only getting more intense. Time to get moving! If you are one of the two-thirds that are in need an enterprise GRC strategy - use privacy as your first use case. It’s bound to move you up the curve quickly and provide real value to your organization.

 

 

Five Simple Questions Core to GRC Program Success

 
As I work with customers on their journey to a unified GRC program, it often seems an insurmountable task.  But, as they say, every journey begins with the first step. And, often the first step is about sitting back and taking the time to really ask yourself, what is it that we need to accomplish? What’s the desired end state? From that introspection comes a set of questions, that when answered, form the basic building blocks of a GRC program:

• What is our end-to-end GRC program and what do we need to invest in to achieve our goals?
• How can we align business requirements with our policies and day-to-day operating processes?
• What is our real exposure and what controls need to be implemented to contain risks?
• How can we leverage technology to manage GRC holistically across the enterprise?
• How can we govern our GRC processes across silos and stakeholders?

Let’s take them one by one.

What is our end-to-end program and what do we need to invest in to achieve our goals?

This question begs us to build a strategy, a plan, a roadmap. Here maturity assessments are essential – they help us focus the lens on high priority initiatives that will get us to the target state.  It forces us to define the scope of the program – across what business units – IT, Operations, Finance or Legal? It’s about adopting the right principles to drive GRC – process efficiency, visibility, transparency, accountability. This question leads us to consider how we will measure success, what metrics are important. And to examine and be realistic about constraints – such as how the program can be funded. It raises issues of prioritization and what is and is not on the roadmap.

How can we align business requirements with our policies and day-to-day operating processes?

This question is really about how we align business processes and procedures with policies and controls. It forces us to look at our policy framework and how it is enforced.  Do we take an information-centric approach to risk and a risk –centric approach to security?  Do we take a pragmatic approach to do the right things well, such as enforce policies at the point of use? Do we have a strong training and awareness program in place to keep a culture of risk awareness growing in our organization? This question makes us to look beyond our boundaries, to other stakeholders, including regulators and third parties that are critical to our business to ask how we ensure our policies are embraced by our partners and customers.

What is our real exposure and what controls need to be implemented to contain risks?

This question has us reflect on the value of our assessments and audits – in what way do they help us understand our most critical business processes and most sensitive information? How do we put boundaries around real exposures that matter the most to our organization? This is the heart of risk management, compliance and controls testing. This question makes us think about risk monitoring and reporting – do we know what they are and are they prioritized in a hierarchy and risk register? This question makes us consider how we leverage common methods in evaluating risks, what rating schemes we use and how we can harvest risk information from performance management and quality systems that provide us insight into KPIs and KRIs.

How can we leverage technology to manage GRC holistically across the enterprise?

This question forces us to look thoughtfully at the entire GRC technology eco-system in play with the organization, and extending to through virtual environments to our customers and partners. We contemplate its architecture and how it will need to evolve over time to meet ever-changing business requirements.  Do we have a single version of the truth, a central platform for managing GRC? How can we leverage technology to ‘test once, analyze across, report many’?

How can we govern our GRC processes across silos and stakeholders?

Finally, we consider governance – what is the accountability framework for making decisions on risk, and who in the organizations truly has decision rights? Who owns risk and what is the organization’s appetite for risk? What nomenclature is used, and how to we strive to inculcate a common language to talk about, understand and act on and remediate risk? Finally, how do we monitor our environment, what metrics do we use and how do we respond to incidents? This question compels us to improve operations and incidence response – so that we are prepared in the event of a crisis, disaster or breach.

Whether it is trying to understand the end-to-end program and what investments need to be made, or diving into the detail of aligning business requirements with policies and day-to-day operating processes, or responding to incidents - implementing a unified GRC program forces us to move up the maturity curve. 

Call to action for you: Take some time to think about these questions. Share your thoughts with your colleagues. You may find yourself starting to work on these building blocks together, and building a solid vision for comprehensive end-to end- GRC program – and find it is not such an insurmountable task!

 

Japan Disaster: Reminding us why we need GRC that integrates Business Resilience, Risk and Incident Management

Japan's devastating earthquake, subsequent tsunami and current power plant threats remind us that we live in a world where the combination and cascading effect of threats raises risks beyond what we consider a reasonable threshold.  It is these apparent ‘black swan’ events that really set us back.  In times like this we see clearly the tight relationship between business resilience, risk and crisis management.

 As we watch the Japan disaster unfold, GRC and Business Continuity professionals the world over are abuzz with what this means back home.  Many organizations will take this an opportunity to look at their own best practices to understand their real exposures and plans to protect people and critical processes in the event of a disaster.

Centralizing approaches to business continuity, disaster recovery, risk and crisis management is a pure GRC use case.  And increasingly an urgent one. It seems impossible, and actually is, without a strong GRC program and good solid technology platform that cover the basics:

• End-to-end risk management process with a common nomenclature and processes for assessing risk on a near-real time basis
• Consensus between the business and IT on risk appetite
• Complete understanding of business process criticality, RTOs  and RPOs
• Visibility into the technology eco-system internally, and across the hybrid cloud - and how it supports the business
• Online access to business continuity and disaster recovery plans in the event of a crisis or business disruption.
• Centralized reporting and management of crisis events that impact employees, customers, stakeholders and mission-critical operations.

I have seen few platforms that can do all of this – but they are emerging.  RSA Archer Business Continuity is one, and there will be more entering the market in the short to medium term. It’s worth looking into these unified approaches –taking a proactive approach could save your organization in ways you can’t even imagine today. Who would have predicted we’d been looking at what we are now in Japan?  It is people, processes and technology, orchestrated in a way that is trulyresponsive, that in the end, makes all the difference.