Integrated GRC Demands an Information Governance Approach
Governance, risk and compliance in today’s world is becoming increasingly integrated across a wide and diverse set of use cases, ranging from traditional risk management to cybersecurity, third-party management, business resilience, environmental health and safety and regulatory compliance. Fundamental to success in integrated GRC is building an information architecture that supports not only day-to-day operational processes, but also yields the metrics and analytics your organization must leverage to make decisions that improve business performance. The core objective of GRC information architecture is to establish the right framework for your organization based on tightly integrated foundational libraries of organizational elements, risks, controls, policies, vendors, products, assets, regulations, business requirements and best practice content.
GRC Information Architecture Considerations
Managing GRC information requires an information architecture and governance approach that aligns with your organization. This can be a unique challenge considering GRC information comes from a variety of sources – external feeds of best practice frameworks and regulations, threats and vulnerabilities, and internal sources such as directories, security and IT inventories and monitoring systems. Added to this are the subtleties of setting up a risk and control framework that functions at multiple levels – for example, enterprise risks at the top level reflecting key categories intended for Board and leadership review and discussion, operational risks at a middle level that describe specific business risks within various business units and say, IT or security components at a deeper level that hone in on cyber threats and vulnerabilities.
In addition, a GRC Information Architecture involves mappings to curated content that provides additional GRC intelligence – for example, mapping a section of a security policy to a regulation, as well as a common control from a source like the Unified Compliance Framework (UCF) to give context on how that policy supports requirements from say ISO, FISMA or NIST.
Setting up foundational GRC libraries requires thoughtful consideration to the use case itself, but also the larger picture of how these libraries will be built out over time to support other complementary and extended use cases that are on your GRC program roadmap.
Good Practice in Building Out GRC Libraries
What’s the best practice on how to approach this? Common questions are:
- What libraries are best to start with and what’s mandatory for a specific use case?
- How can I know that the structure and mappings I choose for the first use case will not need to be redesigned to support later use cases?
- What is the optimal sequence of library setup and what are the dependencies?
In this slideshow, Yo Delmar, MetricStream, covers seven steps that you can take that will help you build out your GRC foundational libraries in a sequence that aligns not only with initiatives on your GRC roadmap, but provides you with a sustainable, ongoing governance process that allows your organization to continuously improve and enrich your GRC information architecture.
- Information Architecture – Level setting on information governance, taxonomies, ontologies and GRC libraries
- Information Needs – Defining information required of governance bodies and day-to-day practitioners
- GRC Framework – Placing GRC libraries in the context of other initiatives across your organization
- GRC Libraries – Defining and exercising the GRC data model with specific GRC activities
- GRC Libraries and Mappings – Defining what is common and what is federated at various levels
- GRC Information Governance – Implementing a sustainable governance program for GRC information
- GRC Apps – Extending GRC libraries with each GRC roadmap work stream and app
Seven Steps to Build Out GRC Foundational Libraries
Click through for seven steps that you can take that will help you build out your GRC foundational libraries in a sequence that aligns not only with initiatives on your GRC roadmap, but provides you with a sustainable, ongoing governance process, as identified by Yo Delmar, MetricStream.
Information Architecture: A level setting on information governance, taxonomies, ontologies and GRC libraries.
The first step involves understanding key differences between what is in an abstract model and what is in the GRC technology itself. Essentially, enterprise information architecture provides overall guiding principles for interoperability, is component-based and is abstracted from the technology. While information architecture leverages processes and data models, it does not typically contain them explicitly.
A taxonomy is simply a classification scheme. While taxonomies are related to data models and processes, they typically do not include mappings or relationships between elements. Multiple taxonomies are typically related at taxonomy level.
A new concept that is increasingly being adopted in GRC is that of an information ontology. An ontology goes further than a taxonomy. It includes the formal naming and definition of the types, properties and interrelationships of entities in a domain. It often includes rules (calculations) between entities, as well as contextual information that is mapped to other data sources. An example is a risk element that contains mapping to processes and mitigating controls, risk factors and the calculations required to produce a metric or analytic.
GRC libraries, on the other hand, reside in the technology itself. Libraries are aligned with information architecture principles, and derived from ontology and taxonomy – then realized in the technology database. Libraries include mapping to content sources, and are built out over time to match use cases in the GRC roadmap. Libraries are foundational to analytics, workflow behavior and reporting in the GRC app environment, and as a result are built up as new apps are brought online. Extending library elements may have upgrade and performance constraints in the app so it is important to thoroughly understand the GRC technology data model and how it is evolving through product roadmaps.
Pay special attention to these key principles:
- Common language: Get consensus from your team and stakeholders on the definitions (or something similar that suits your organization) in order to be clear on what needs to be defined in working groups and what can be supported in the technology.
- Start with the end in mind: Get your team members thinking in terms that include structured and unstructured data – that is, what is the data model and content from best practice sources.
- Continuous improvement and sustainability: Set the stage that a GRC libraries initiative is ever-ongoing – it will start with the core use cases and be built out over time; there is no need to boil the ocean up front.
Information Needs: Defining information required of governance bodies and day-to-day subject matter experts.
In this step, it is critical to understand the high-level information needs of governance bodies that are in scope for your GRC program by looking at standard reports and dashboards used today, envisioned to support tomorrow, and available in your GRC technology apps. What are the high-level needs and what are the gaps? Are there information requirements that cannot be supported thorough GRC reports and dashboards?
For example, the Board and leadership may need a quarterly dashboard looking at the top 15 to 20 risks across the organization and have the ability to ‘drill down’ to get the context around risk for discussion – a risk size, scale and scope, if you will. Operational leaders may focus monthly on key performance indicators and key risk indicators that trigger action when metrics move outside of accepted guiderails and thresholds. Analysts and SMEs may require daily and weekly reviews of issues, threats or the results of control testing.
It is all about defining key information and metrics that business, IT and security teams need to do their jobs. The focus here is to bring the right information to the right people at the right time in an increasingly virtual, mobile and cloud-based GRC ecosystem.
Pay special attention to three main aspects of reporting, keeping the review at a high level:
- Key information needed by each governance group and the cadence required to support decision making (daily, weekly, monthly, etc.).
- High-level mappings required between libraries to support dashboards and reports – for example, risk mapped to mitigating controls, mapped to control test results, mapped to best practice frameworks and regulations.
- External feeds to systems or content to provide context to information (example: regulations, loss events, etc.).
GRC Framework: Placing GRC libraries in the context of other initiatives across your organization.
In this step, look across all the initiatives in your organization that may affect the timing of building out GRC libraries. For example, if your organization is acquiring or divesting another organization or rolling out a new business unit or set of products or services, how will that affect the organizational model? If your organization has initiatives around regulatory change management, how might that affect the way regulatory content is managed and updated? If your organization is updating policies or going through a controls rationalization project, or implementing a new technology that automates controls monitoring, how might that affect the information architecture? It’s a good idea to maintain an overall GRC framework diagram and make changes to reflect GRC needs as the program evolves.
Pay special attention to:
- In what ways is this initiative in scope for GRC?
- What is the current and target maturity in this component?
- Is there a work stream ongoing that requires interlock that your team can participate in to stay informed or provide input to the information architecture?
- Are the right stakeholders involved to commit to providing interlock in a timeframe the GRC libraries initiative requires?
- What SMEs or new skill sets will be required to support this component for GRC?
- What are the risks to GRC if this component is not supported?
GRC Libraries: Defining and exercising the GRC data model with specific GRC activities.
In this step, focus on building an information architecture – with the ontology aspect where possible, and map against key libraries in the GRC technology that are in scope for the GRC program. For example, thinking in terms of compliance activities, libraries that contain regulations, standards and requirements also leverage GRC libraries such as processes, risk and controls, to support specific GRC activities such as risk assessments, controls testing and audits. Organizations select the set of regulations that they must comply with, and use that as a basis for selecting controls that support those regulations.
On an ongoing basis, GRC practitioners may identify risks and appropriately map them to other library elements such as policies, regulations, processes, assets, suppliers, controls, metrics and organization units.
You will want to review all GRC libraries and draw the library data model and define the ontology aspects. For each library, define related libraries that will be mapped and related GRC activities. This may take multiple meetings, reviewing and exercising the data model with various stakeholder teams as you go through all the use cases in scope.
Pay special attention to:
- What relationships in the abstract data model support GRC libraries?
- What needs to change or be enhanced?
- What are key GRC activities related to each library – risk, compliance, policy, issue, audit, etc.
- What external content feeds are required as input to GRC libraries?
- How will content be mapped at the library level?
GRC Libraries and Mappings
GRC Libraries and Mappings: Defining what’s common and what’s federated at various levels.
In this step, look at what information is shared by all, and must be pristine, versus what is unique and can vary within a business unit or specific process. For example, a risk category at Level 1 and its sub risks at Level 2 may be critical for rollup and the analytics framework, whereas elements such as security threats and vulnerabilities can be a unique taxonomy that feeds in a Level 3.
GRC, by definition, involves bringing together governance, risk and compliance disciplines from across what is increasingly becoming a complex, extended enterprise with deep interlocks to customer and supplier eco-systems. While it is not realistic to expect organizations to converge on a common set of processes for GRC across this complex landscape, there is huge value in taking a federated approach that orchestrates common risk elements from each business unit, IT and security teams and management of third parties.
GRC Libraries and Mappings
Remember to reinforce that an overall library model and instantiation in a GRC technology will bring amazing benefits to your organization – reduction of response time, a context-rich view of information and a framework for metrics and analytics that is table stakes for making good decisions.
Thoughtful consideration must be given to what can or needs to be federated with unique taxonomies and workflows for specific business units and functions. The degree of federation your organization will need depends on the degree of reporting, analytics and decision making that relies on common information.
GRC Libraries and Mappings
Pay special attention to:
- What levels within each library are required to support related GRC activities?
- Who is the owner at each level?
- What are the source system(s) for this data?
- What cadence of update from source system is required? (near real-time, daily, weekly, etc.)
- What are the key fields and mandatory mappings to other library elements (risks to compensating controls, etc.)?
- What are the key fields and mandatory mappings to content? (regulations, external loss events, supplier adverse event, etc.
- For each library and GRC-related app, define what is:
o Common: What level in the hierarchy is required in this library to support this taxonomy/ontology?
o Federated: What level in the hierarchy is required in this library to support this taxonomy/ontology?
GRC Information Governance
GRC Information Governance: Implementing a sustainable governance program for GRC information.
Now that the overall libraries model is defined, as much as it can be, and your team is buying into an enterprise-wide GRC information architecture that can be built out over time, you can turn to the sticky topic of information governance. It is important not to get too deep into this step until prior steps are completed, as your team could be road-blocked with groups that may not want to participate in a larger effort where information is shared. To alleviate this concern, it is important to have a technology that permits role-based access to information so that views can be protected.
GRC Information Governance
Pay special attention to:
- Who is the information business owner and technical custodian at each level of the library?
- What is the approved standard format and naming convention for elements at this level?
- What role/working group has permissions to update or adopt a new element (e.g., introducing a new risk into the common framework at Level 1 or 2)?
- What role/working group has permissions to EOL (end-of-life) adopt an existing element (e.g., removing a risk from the common framework)?
- What MDM considerations are in scope that could get libraries/updates out of sync?
- What is the process for governance and approval?
- What is the key metric/analytic and calculations that will be used to roll up into the common framework?
- What is the governance information process to support these metrics/analytics?
GRC Apps: Extending GRC libraries with each GRC roadmap work stream.
In this step, your team applies the library model to your GRC roadmap to bring clarity to the sequencing and build-out for each library. Take time to introduce teams working on the specific use case to gain a general understanding of common framework and federated requirements. For example, if you are deploying IT or security risk management in a GRC tool, information will be required for IT/security vulnerabilities from scanning tools and may be part of the library model at level 3 or 4. The team will need to understand level 1 and 2 structure to ensure the app is feeding into the common framework at the right level of granularity. Make sure as new GRC activities are defined and refined, to tie these information flows back to the information needs from step 2 and the overall Ontology in step 4 so that your information architecture is kept current.
Pay special attention to:
- What extensions are required to this library to support this new initiative?
- What is the data migration and QA process for new fields?
- Are any of the new fields required?
- What is the impact to existing apps with new fields?
- Are any upgrades required? If so, has this been worked into the master plan?
- For each roadmap initiative, identify library and taxonomy levels that will need to be built out.
- Define explicitly, as much as can be known, specific fields and sources.
- Identify MMD considerations.
- Identify data migration considerations.
In summary, by building an integrated GRC information architecture, organizations benefit from common GRC libraries with common terms for core elements such as business units, risks, controls, products, processes, assets, vendors and people. Setting up GRC libraries helps an enterprise to maintain associations and mappings at the desired level of granularity to support business and risk and regulatory compliance needs.
GRC libraries structure a logical compliance and controls hierarchy, including processes, sub-processes, objectives, associated risks, controls and control activities. This can significantly reduce the amount of time IT and security professionals spend defining and maintaining an integrated risk and control framework. This makes it much easier to define risk management essentials, including appetite, thresholds, risk analysis methods, risk calculations for rollups, metrics and analytics.
By balancing common and federated processes for risk identification, analysis and issue management, all business units and stakeholders can participate in a common model, while supporting their unique methods and practices. Getting a sustainable GRC information architecture in place involving the right stakeholders, an evolving model, and building it out over time brings you a long way toward orchestrating GRC intelligence across your organization with a trusted system of record and version of truth.