Category: Blogs

There has been a lot of consolidation and restructuring in the GRC space already in 2010 – SAI Global takes the next step by acquiring Integrity Interactive.

As an industry pundit and analyst it is always fun to play match maker. For some time I have been pontificating that SAP and CA are very complimentary in their approach to the GRC market. While one focuses on business processes and applications (SAP), the other (CA) focuses on IT management and security. I was quite excited when they formally announced that they have worked out a partnership and demonstrated an interesting level of integration.

Business today requires agility and efficiency to stay competitive. Organizations must respond rapidly to changing conditions, while managing financial and human capital costs.

Compliance processes often work against business agility and efficiency. Requirements and initiatives bear down on the business, and become burdensome and inflexible. When managed manually and/or across numerous siloed business units, compliance can slow down and encumber the business.

Risk can be a burden or a tool that enhances business performance. Healthy risk-taking drives business; however, organizations must understand whether they are taking the right risk, if risk is being managed effectively, and how to monitor risk. A cavalier and uncontrolled approach to risk will result in disaster — even for companies with strong brands.

Poorly managed risk and compliance generates complexity, redundancy, and failure. In this instance, the organization is not thinking about how controls and processes can be architected to meet a range of risk and compliance needs — nor does it gain an understanding of how risk management and compliance impact corporate performance. Too often organizations are reactive and lack a cohesive strategy. This isolated and periodic snap-shot approach to risk and compliance causes organizations to spend excessively on internal management and external auditors.

What may seem like an insignificant risk in one part of the organization may have a different impact when other risks are factored-in, either from another business process or risk category. Organizations are at-risk when they rely upon out-of-sync controls and disconnected corporate policies. Executives are becoming aware of these redundant risk-and-compliance projects, and are identifying the need for an integrated governance, risk, and compliance (GRC) strategy.

Organizations report significant issues and cost associated with manual and basic technology approaches in these areas:

• Common anomalies, malicious activity, and errors go undetected.
• Significant spend on external auditors and consultants.
• Horrendous reporting.
• Unmanageable amounts of paper and spreadsheets.
• Reactive after-the-issue fire fighting.

Success in today’s dynamic environment requires organizations to integrate, build, and support business processes with an enterprise view of GRC. While new risk and compliance issues constantly come to bear, organizations must take care to tackle the problem at its roots. A sustainable enterprise view of GRC means accountability is effectively managed and a complete system of record provides visibility across the key business processes and multiple applications.

Technology should empower business-process owners (who are also the control owners) to manage risk and compliance continuously. Technology can directly integrate controls within business processes, applications, and systems to prevent and/or detect unwanted behavior. IT should not be required to operate the control environment, which will improve the security of the audit trail. Audit does not need to be a quarterly event, but part of everyday activity and good business practices. This leads to cost savings and efficiency, while allowing the organization to remain agile.

A well-designed system of control is not necessarily a well-operating system of control. Many organizations pursue GRC with limited results as they have focused their efforts on GRC documentation. While this concept and approach to GRC is a good start, achieving efficiency in GRC requires a GRC strategy to be operating effectively not just designed (documented). Operating effectiveness is where GRC value is obtained and is built upon design effectiveness:

• Design effectiveness: Begins with understanding of how a GRC system of internal control is effectively designed. To determine this, the organization starts by documenting controls and processes. An assessment is performed, and for each risk and compliance requirement, controls and incentives that mitigate risk are identified. Ultimately, the organization must determine whether these controls and incentives and the system as a whole are designed to satisfy stakeholders and regulators while managing risk and requirements.

• Operating effectiveness: An effectively operating GRC system considers how GRC is being managed within business, and its impact on the business. The organization should determine if the system operates as-designed, and if the system supports the needs of a dynamic business in a way that increases business agility while minimizing use of financial and human capital resources.

Organizations face a complex array of risk and compliance demands that impact the business. The organization must implement control-monitoring processes and technology that streamlines GRC operations, minimizes risk, meets regulatory requirements, and supports business agility and efficiency. GRC control monitoring should exist within the context of business processes and the supporting application environments, and across all potential sources of change to those controls.

Achieving efficiency and value in GRC requires a long-term GRC vision, and shorter-term wins. The more extended and distributed the business is, the more challenging risk and compliance are to manage. A solid GRC foundation provides an extensible technology platform that is adaptable and scalable. An enterprise GRC solution does not operate as a silo unto itself, but integrates with critical business processes and applications. The goal is to:

• Avoid issues and mitigate risk: Organizations must mitigate loss, fraud, error, and risk within acceptable boundaries. GRC automation allows the organization to detect potential or actual issues within key business processes and applications, to avoid negative or unintentional consequences.

• Reduce reporting time: Effective operation of GRC means creating efficiency in human and financial capital resources. It is critical to implement a GRC approach that reduces the amount of time spent by internal and external assurance personnel.

GRC is about protecting the business — staying within defined risk and requirement boundaries to minimize loss while optimizing performance. An organization approaching GRC proceeds through three levels of maturity:

1. Manual and isolated: The first level is a reactive approach to risk and compliance. Different issues are managed in different parts of the organization, relying on burdensome and costly approaches to managing risk and compliance. This ad hoc approach is a manual and labor-intensive process, and results in mountains of paper and electronic documents. This produces a compliance posture that is often full of holes or outright smoke-and-mirrors.
2. Documentation and workflow: The second level is documentation of GRC controls and processes. This is often maintained in document or policy-management systems that have content and workflow capabilities, but little understanding of business processes and no integration with the underlying business application environment. The focus of this level of maturity is the design effectiveness of GRC — to document the busin
   ess appropriately to satisfy regulators and stakeholders.

3. Control automation and monitoring: The third level focuses on the operating effectiveness of GRC. Here, the organization achieves economies in GRC through processes and controls connected and in-sync with objectives, policies, and risks associated with business processes and applications. Value is created by ensuring that control violations are identified immediately, minimizing loss from fraud and errors, and by greater efficiency in human and financial resources.

The most economical GRC approach focuses on automation and efficiency. The goal is to connect policies and procedures to control objectives and automate monitoring and enforcement of controls. Automated controls can span business processes, applications, and information to reduce inefficiencies in current methods of internal control monitoring and validation.

The importance of automated monitoring increases as the velocity of change steps up within the organization. Change can be good or bad. As companies expand the number of users spread across geographies, there is more opportunity for mistakes, fraud, or operational errors. Growth also multiplies the application levels within which users can make changes, for both end-users and database users. Changes can also come from third-party systems running batch processes, application triggers that are poorly implemented, or stored procedures that do not leave a transaction footprint. Accidental changes can occur during IT system upgrades, patches, or restarts.

When control monitoring becomes a background process of everyday business activities, a continuous real-time audit trail is always available. This eliminates the need for time-consuming investigations that take place when exceptions are identified, weeks or months after the fact. The scope of monitoring can expand beyond a limited subset of key controls required for compliance activities. By empowering business process owners to monitor the integrity of their operations, operational risk from fraud and errors is greatly reduced.

For audit and compliance, this eliminates or greatly reduces sample-based audits while providing a comprehensive control baseline and change history for data and processes. The scope of review can also be significantly expanded without requiring additional resources: Audit processes that were performed once every several years can be done continuously. Once validated, auditors can rely on the existence of automated controls and continuous change-tracking as evidence of compliance.

This posting has been an excerpt of Corporate Integrity’s published research, Achieve GRC Value – Efficient Business Process & Application Monitoring.

I would love to hear your thoughts on the topic of GRC Software. Please feel free to comment in this forum, or send me an email. Please comment on this blog or send me an e-mail.

While GRC is ultimately about collaboration and communication between business roles and processes, technology provides the backbone that enables GRC. To describe this technology, Corproate Integrity has defined the GRC Reference Architecture (this is closely aligned to the second version of the Open Compliance & Ethics Group (OCEG) GRC Technology Blueprint).

This model is meant to be a practical and applicable tool for organizations trying to understand and implement technology for GRC.

GRC today is akin to customer/client relationship management (CRM) in the 1980s. Before CRM systems and processes entered the organization, client information and relationships were being managed. The challenge was that there were scattered silos that created inconsistent and redundant data, with no view into the entire profile of the client and its interaction with the business. CRM systems create a single view of customer information and interaction across business processes and roles. GRC systems and processes aim to achieve the same thing — to provide an integrated picture of governance, risk, and compliance information and processes across the business. This requires an integrated view of GRC business process and technology architecture.

A high-level view of the GRC Reference Architecture comprises the following areas:

• Information architecture: Conceptualizes the interrelationship of GRC-related information that bring agility, efficiency, and effectiveness to the entire organization.
• Enterprise GRC applications: Represents solution areas that span risk and compliance roles and processes. These solutions are not locked to a single business role, function, and process, but are leveraged among all of them.
• GRC role and process-specific applications: Describes GRC-role specific applications. These are solutions designed for a specific business role or function to accomplish a specific set of tasks. These applications are typically used predominantly by one area of the organization.

A firm GRC foundation is built upon solid information architecture. The burden, inefficiency, and ineffectiveness — as opposed to agility, efficiency, and effectiveness — of risk and compliance processes results from a lack of integrated and interrelated information architecture.

An intricate relationship of information from across the organization is the heart of a successful GRC technology strategy. All policies, risks, controls, events, requirements, enterprise assets and processes, responsibilities, and objectives interrelate and support each other. When managed in information silos, each of these areas bring inefficiency to the risk and compliance processes.

For example, organizations must understand which policies set management thresholds for specific risks; which events violate specific policies, materialize risk, and cause infractions of regulatory requirements; which controls are established for specific policies and are defined to control certain risks; and which business objectives involve risk, and how their controls allow pursuit of the objective but stay within acceptable risk-tolerance levels.

Enterprise GRC applications interact, share, and leverage the information model to deliver sustainable, consistent, efficient, transparent, and accountable GRC processes. This requires the application to be used across the business as a platform that touches and interacts with a variety of business roles and information. These foundational applications must deliver on the GRC philosophy of a common architecture and collaboration across business roles and interests.

Dozens of application categories fall outside the enterprise GRC application core — these applications focus on specific business roles and functions, such as quality, environmental, health, and safety (EH&S ), and matter management. The enterprise GRC application core consists of the following applications:

• Audit and assurance management: Audit and assurance management systems manage audit cycles and output — this includes audit resource scheduling and calendaring, audit work paper management, and audit process management.
• Case and investigations management: Case and investigations management software is used to manage investigations, issues, incidents, events, or cases. It specifically provides consistent documentation and management of events — from reporting to managing and documenting the investigation, to recording the loss and business impact.
• Compliance management: Corporate compliance systems support the overall coordination of legal, regulatory, contractual, and corporate policy requirements and responsibilities with associated tasks and records of adherence.
• Control activity and monitoring: Control management and monitoring systems provide the ability to define, record, map, monitor, change, alert and report on information processing (financial and operational data). This includes the limitations or conditions applied to amounts and parties in a transaction; user access, rights, and responsibilities; and accounts, workflows, and process initiation.
• Hotline/helpline: Employee hotline and helpline systems are confidential, independent information intake and response systems for reporting potential internal fraud, negligence or impropriety by co-workers, partners or contractors. Employees can also use them to seek clarification on policies, and procedures.
• Policy and procedure management: Policy and procedure management systems help develop, record, organize, modify, maintain, communicate, and administer organizational policies and procedures in response to new or changing requirements or principles, and correlate them to one another.
• Risk & Regulatory intelligence and monitoring: Regulatory intelligence and monitoring systems monitor external and internal changes, and alert the organization to regulatory and legal conditions that can impact their business. Risk intelligence and monitoring systems monitor external and internal changes, and alert the organization to risk conditions (e.g., geo-political, economic, natural disaster) that can impact their business.
• Risk management: ERM systems mange implementation of frameworks and processes that apply parameters, indicators, measures, consequential outcomes and business scenarios related to financial and non-financial risks. Operational risk management systems and applications implement and monitor risk processes that define parameters, indicators, consequential analysis and “what-if?” scenarios that stem from performing tasks and from passive activities. Risk analytics and modeling systems help identify specific causes of risk, given the potential consequences of events and the likelihood of events occurring sequentially or simultaneously. These tools execute historical reviews, simulations, interpretations and project impacts to operations, assets, or individuals.
• Strategy, performance, and business intelligence: BI, strategy, and performance systems examine the systems, processes and applications that manage collection, integration, analysis, and presentation of all layers of planning, strategy, performance, operational, procedural, and decision-making information.
• Training a
  nd awareness: Training and awareness systems manage the learning and understanding of compliance, policy, and risk areas to employees and extended business relationships. They combine training content with learning management system capabilities.

The enterprise GRC application core provides the foundation of GRC across the business. All of these applications can be leveraged from one side of the business to the other, to provide a consistent approach to GRC across silos of risk and compliance. However, a variety of business functions and roles have specific needs that demand applications aimed at their business function. These applications plug into the broader GRC Reference Architecture.

GRC is a federated effort. There is no such thing as one group of the organization that “does” GRC. While there may be a role in leading the collaboration, GRC must extend throughout the business. Business role and function-specific applications predominantly focus on the needs of a specific business function, process, or role in the enterprise. Applications in this area may have significant risk and compliance relevance and impact on the enterprise — but 80% (or more) are used by a specific user or role subset. The enterprise application core represents applications that span GRC business users and roles across the business.

The business roles and functions with specific need for GRC technologies and applications are scattered across the enterprise. In one sense, every part of the business touches on GRC as it relates to different aspects of performance, risk, compliance, values, and control. Primary, not all-inclusive, business function/role application categories include:

• 3rd/vendor/supply-chain risk and compliance
• Board and entity management
• Brand and reputation management
• Business continuity management
• Contract management
• Corporate social responsibility
• Discovery/e-discovery management
• Environmental monitoring and reporting
• Environmental, health, and safety
• Fraud detection and prevention
• Global trade compliance/international dealings
• Information/IT risk and compliance
• Insurance and claims management
• Intellectual property management
• Loss management
• Matter management
• Physical security management
• Privacy
• Quality management and monitoring
• Risk management – finance and treasury

These roles represent a significant but not exhaustive look at the categories of risk and compliance software solutions targeted at specific areas of the business. The applications must be able to report and feed information into broader GRC reporting systems and dashboards to maintain a 360-degree view of GRC. All are very relevant, and part of a broad GRC strategy.

The GRC Reference Architecture is a model of the technology landscape of GRC solutions. Currently there are more than 400 different technology providers delivering solutions for narrow to broad aspects of governance, risk, and compliance. The GRC Reference Architecture is part of Corporate Integrity’s broader GRC EcoSystem, which catalogs more than 1,300 technologies, professional service firms, and information/content providers. This posting has been just an excerpt of Corporate Integrity’s published research, GRC Reference Architecture: Understanding the GRC Technology Landscape.

I would love to hear your thoughts on the topic of GRC Software. Please feel free to comment in this forum, or send me an email. Please comment on this blog or send me an e-mail.

ONLINE WORKSHOP: The GRC Reference Architecture

Understanding & Approaching GRC Technology for Your Business

GRC – Governance, Risk, & Compliance. Whether you use this specific acronym or not the fact is your organization does GRC. There is not a single executive that will tell you that they lack corporate governance, do not manage risk, and completely ignore compliance. The truth of the matter: GRC has been a part of business since the dawn of business. In this 2 hour online workshop, Corporate Integrity defines and communicates The GRC Reference Architecture. This GRC Reference Architecture is part of my broader GRC EcoSystem of technology, consultants, and information providers (over 1300 firms cataloged to date). And is synchronized to the OCEG GRC IT Blueprint

The GRC Reference Architecture is comprised of: information framework, enterprise core GRC application(s), role/business function specific applications, as well as industry and geographic/jurisdiction specific applications.

The goal is to assist organizations in understanding the breadth of the GRC technology landscape, how different GRC technologies can and should work together, and provide the foundation for developing a GRC technology plan to support your organization’s risk and compliance process requirements.

ONLINE WORKSHOP – The GRC Reference Architecture

Date: Thursday, July 01, 2010 from 11:00 AM – 1:00 PM (CT)

I am amazed at the number of risk management programs I encounter that lack an organized structure and approach. So often what we know as ERM (enterprise risk management) is a hodge-podge of processes and assessments that somebody tagged the ERM label on without much thought for what they were doing. In fact, most of the ERM processes I encounter are nothing more than a slightly expanded view of SOX and financial controls: they are not truly an enterprise view of risk across the organization and its operations.

Most ERM programs lack the fundamental building blocks for a risk management program. This begins with a well written charter for ERM and a supporting ERM policy.

A recent client of mine, looking to engage me in the development of an ERM policy, asked what the main components of an ERM policy are.

MY ANSWER: ERM policies are organization specific; no two ERM policies are identical. However, there is a logical structure that works well as a starting block for most organizations. These include the following structural components for an ERM policy (note: these same components can be used for other risk management policies besides ERM such as IT/information risk management):

• Objective/Purpose. As with any policy it is necessary that the policy begin with the organization and purpose of the policy. This is nothing more than writing out the charter for ERM and establishing the authority of this policy to establish and govern the ERM program.

• Risk Governance Structure. It is critical that the organization establish the governance structure for risk management. This is a big area of failure for most ERM programs when it is often the case that risk management operates as an island with very little to know interaction with the board and executives. A solid ERM policy will identify how the board and its committees interact with ERM as well as senior executives.

• Roles & Responsibilities. Once the governance structure is in place, the policy should get into specific roles and responsibilities for ERM. This includes a clear understanding of the roles of a Chief Risk Officer, executive management, business operations, risk management staff, and the role of audit in the assurance oversight of risk management.

• Risk Culture. The single greatest hurdle to successful ERM is articulating and integrating risk management into the organization’s culture. In one sense risk management is part of the culture no matter what is articulated in policy – an organization can have a cavalier approach to risk taking, a structured approach to risk taking and oversight thereof, or anywhere in between. The organization needs to clearly spell out how the organization approaches risk taking, management, and ongoing monitoring of risk in the organization.

• Risk Strategy. Following on the heels of risk culture, the ERM policy should next deal with how ERM aligns and integrates with corporate performance, objective, and strategy management. ERM often is disconnected from these areas which makes it of little practical use to the organization.

• Risk Tolerance & Appetite. The next logical sequence in the ERM policy is to establish the boundaries of risk taking in articulating the organization’s approach and boundaries to risk tolerance and appetite. It is hear that the policy discusses what is acceptable and unacceptable risk. This provides the high-level boundaries and approach to risk taking, though most of the specifics on these boundaries will be found in supporting policies (e.g., credit risk policy).

• Risk Taxonomy. The ERM policy needs to authorize and give authority to the development and ongoing maintenance of the organization’s risk taxonomy. The highest level structure for risk management should be included in the policy – such as the establishment of risk oversight for areas such as financial/treasury, operational, and legal/compliance risks. The policy should reference and give authority to the establishment of another document that defines the depth of the structure of risk categories that the organization recognizes and manages.

• Risk Ownership. You cannot hold anyone accountable for risk unless clear ownership of risk id defined. While specific ownership of individual risks are found in supporting risk management policies (e.g., vendor risk policy, privacy policy, credit risk policy, information risk policy) – the ERM policy should state the ownership of risk at the high-level categories defined in the risk taxonomy. It should also be clear on the point that the risk management function does not own risk, the business and process owners are the ones that own risk. The ERM process is there to communicate and provide the infrastructure to manage and monitor risk to support the risk owners across the business.

• Risk Assessment Process. The ERM policy is to authorize the formation of risk assessment processes in the organization. The policy itself should outline the expectations of required periodic assessments such as an annual ERM assessment process, and is to authorize the establishment of more specific risk assessments that are established in supporting risk management policies. This section of the policy should identify the approval needed to establish a risk assessment, what structure is provided, and how the assessment gets communicated and integrated into the ERM structure.

• Risk Infrastructure, Documentation. & Communication. Documentation of risk, risk taking, as well as assessment, management, and monitoring activities for risk are critical to a successful ERM program. An organization cannot hold individuals accountable for risk taking if there is not clear documentation on the risk. This section should authorize the establishment of an enterprise platform to monitor ongoing risk management processes across the organization. It should also establish a warning against the use of technologies such as spreadsheets for risk assessments that lack proper audit trails.

• Mitigation & Response. The ERM policy should articulate the proper response plans to risk such as risk transfer, risk acceptance, risk mitigation, and risk avoidance. While much of the details of this will be worked out in supporting risk policies, it is in the ERM policy that the are defined at a high level.

• Key Risk Indicators. Ongoing monitoring for risk is critical to a successful ERM program. This involves the authorization and establishment of a process to gather metrics on Key Risk Indicators that are further defined in supporting policies. The ERM policy should provide guidance on how KRI information is collected, how often, and establish that KRI’s are to be relevant to the business and mapped to Key Performance Indicators of the business.

• Risk Training. Everyone in the organization has some role in risk management – it is necessary that risk culture, risk taking, and risk responsibilities be clearly understood at all levels of the business for the various business roles and the risks they encounter and manage. The ERM policy establishes an ongoing risk training and awareness program to communicate and educate risk to employees, stakeholders, and business partners.

• Risk Budgets/Funding. The ERM policy should establish and authorize the financing for risk management and oversight activities. This ties into other sections of the ERM policy as well as supporting policies to clearly define what budget areas various risk activities will be financed from.

• Risk Activities (calendar). The
  ERM policy should establish what activities are required of ERM on an ongoing/calendar basis. This should include monthly/quarterly/annual reports and assessments, the individuals responsible for them, and who they get communicated to. One of the best examples I have seen of this is at Microsoft in what they have called ‘The Rhythm of Risk’ in which risk management is aligned to the needs of the board and executives based on their quarterly and monthly calendars.

• Definitions. Finally, as with all policies, a section is needed that clearly defines definitions related to risk and risk management. I highly encourage the use of standard definitions such as those in ISO 31000:2009 and ISO:IEC 73.

As I stated before, no two risk management policies are alike. What I have provided here is some guidance on the sections I most often include in developing an ERM policy (as well as supporting risk policies). There are other standard sections to policies such as revision history I have not included for the sake of simplicity.

I would love to hear your thoughts on the topic of ERM policies. Please feel free to comment in this forum, or send me an e-mail. If anyone seeks further help in writing, reviewing, and/or revising their risk policies please do not hesitate to contact me.

My response to Steven Minsky’s blog on: ERM vs GRC? SEC Says No to Myopic Approach: Costly Example from Goldman Sachs

Whether you use the term or not – the fact is organizations do GRC. You will not get one organization to stand up and state they lack governance, do not manage risk, and can care less about compliance to mandated (e.g., regulatory) and voluntary (e.g., social responsibility) boundaries.

The question is: are your organization’s GRC related processesresponsive (agile), efficient (lean), and effective (sound)?

One of the most common questions I get: is there a GRC professional certification? Unfortunately my answer to date has been: none that I endorse.

In fact, there has been only one GRC certification offered that I am aware of. This has been done by a training/education firm to promote their training. Unfortunately this is not the proper place for a certification to belong.

A good professional certification will be based on two requirements:

1. It has to be established and maintained by a non-profit organization focused on advancing the area of expertise.
2. It has to be based on a publicly vetted common body of knowledge.

To date there has not been a non-profit organization offering a professional GRC certification based on a comprehensive and vetted GRC common body of knowledge.

The good news: OCEG is in development of a GRC professional certification. This certification is based on the Red Book 2: GRC Capability Model: the only comprehensive GRC common body of knowledge available. It will compliment and not conflict with domain specific certifications offered by other associations that specialize in areas of GRC such as audit, compliance, risk, IT, and others.

OCEG will be launching the full certification this summer. In the meantime, those attending theOCEG/Corporate Integrity GRC Fundamentals, Strategy, & Technology Bootcamps (based on Red Book 2) will have the opportunity to help define the scope of this certification, contribute to design of its test, and be among the first to receive this important professional designation. OCEG will be engaging GRC Bootcamp attendees to propose test questions and format.

A firm foundation of knowledge is the critical element for a professional certification. The landscape of governance, risk management, and compliance initiatives is broad and littered with a variety of specific standards and frameworks. Each of these specific frameworks may be good at what they focus on – but they fail to link GRC together and put everything in context with each other. Risk management, security, corporate governance, control, security, compliance, audit, quality, EH&S, sustainability – all have their respective islands of standards. This makes putting a GRC strategy in place that bridges these silos difficult as language, implementations, and approaches are quite different. In fact – organizations trying to get an enterprise view of risk and compliance desperately search for a GRC “Rosetta Stone.”

There is only one framework that brings this universe of GRC into a common language, process, and architecture – that is the OCEG Red Book (v2) and its GRC Capability Model™. Although various standards and guidance frameworks exist to address discrete portions of governance, risk management and compliance issues, the OCEG GRC Capability Model™ is the only one that provides comprehensive and detailed practices for an integrated and collaborative approach to GRC. These practices address the many elements that make up a complete GRC business architecture. Applying the elements of the GRC Capability Model™ and the practices within them enable an organization to:

• Achieve business objectives
• Enhance organizational culture
• Increase stakeholder confidence
• Prepare and protect the organization
• Prevent, detect and reduce adversity
• Motivate and inspire desired conduct
• Improve responsiveness and efficiency
• Optimize economic and social value

The GRC Capability Model™ describes key elements of an effective GRC architecture that integrate the principles of good corporate governance, risk management, compliance, ethics and internal control. It provides a comprehensive guide for anyone implementing and managing a GRC system or some aspect of that system. The OCEG GRC Capability Model™ is organized in eight components:

1. CULTURE & CONTEXT. Understand the current culture and the internal and external business contexts in which the organization operates, so that the GRC system can address current realities – and identify opportunities to affect the context to be more congruent with desired organizational outcomes.
2. ORGANIZE & OVERSEE. Organize and oversee the GRC system so that it is integrated with and when appropriate modifies, the existing operating model of the business and assign to management specific responsibility, decision-making authority, and accountability to achieve system goals.
3. ASSESS & ALIGN. Asses risks and optimize the organizational risk profile with a portfolio of initiatives, tactics, and activities.
4. PREVENT & PROMOTE. Promote and motivate desirable conduct, and prevent undesirable events and activities, using a mix of controls and incentives.
5. DETECT & DISCERN. Detect actual and potential undesirable conduct, events, GRC system weaknesses, and stakeholder concerns using a broad network of information gathering and analysis techniques.
6. RESPOND & RESOLVE. Respond to and recover from noncompliance and unethical conduct events, or GRC system failures, so that the organization resolves each immediate issue and prevent or resolve similar issues more effectively and efficiently in the future.
7. MONITOR & MEASURE. Monitor, measure and modify the GRC system on a periodic and ongoing basis to ensure it contributes to business objectives while being effective, efficient and responsive to the changing environment.
8. INFORM & INTEGRATE. Capture, document and manage GRC information so that it efficiently and accurately flows up, down and across the extended enterprise, and to external stakeholders.

OCEG’s GRC Capability Model™ is the Rosetta Stone framework that brings a holistic enterprise view of GRC together. It works from the board of directors down into the management and process of an organization. It’s goal is not to replace other frameworks and standards but to give them a common language and context to operate within and thus provide enterprise collaboration and communication across governance, risk, and compliance.

I sat on the OCEG Steering Committee (with over 100 other contributors) to define this valuable work and am encouraged by a number of global organizations that are using it and and seeing benefits achieved. There is nothing else available in scope and practicality to implement a GRC program around. For those interested in rolling up your sleeves further – whether an organization implementer, technology provider, or professional services provider – I encourage
you to get involved with OCEG, Red Book: GRC Capability Model, and the GRC professional certification.

Please reply back with your feedback and thoughts. How do you see organizations bringing together an enterprise view of governance, risk, and compliance? In today’s complex business environment a failure to get an enterprise perspective on this is a recipe for disaster.

I would love to hear your thoughts, experiences, and approaches to effective policy management. Please comment on this blog or send me an e-mail.

BOOTCAMP: GRC Fundamentals, Strategy, & Technology

Join Corporate Integrity, LLC in a three-day basic training exercise in GRC Fundamentals, Strategy, and Technology. Attendees will receive value in understanding and defining a GRC strategy. This bootcamp is authorized and endorsed by OCEG. The objective of this bootcamp is to provide attendees with the knowledge and hands-on practice necessary to efficiently design a GRC program. Attendees will learn about defining a GRC Strategy aligned with Red Book 2 through lectures and practical group interaction, discussions, and exercises. Others, such as technology providers and professional service firms, also benefit from understanding the issues and approaches to GRC challenges that organizations across industries are grappling with.

Chicago, IL, USA – GRC Fundamentals, Strategy, & Technology

Date: Wednesday, April 21, 2010 at 8:00 AM – Friday, April 23, 2010 at 5:00 PM (CT)

London, UK – GRC Fundamentals, Strategy, & Technology

Date: Monday, June 7, 2010 at 8:00 AM – Wednesday, June 9, 2010 at 5:00 PM(GMT)

San Diego, CA, USA – GRC Fundamentals, Strategy, & Technology

Date: Wednesday, June 23, 2010 at 8:00 AM – Friday, June 25, 2010 at 5:00 PM (PT)

New York, NY, USA – GRC Fundamentals, Strategy, & Technology

Date: Monday, August 9, 2010 at 8:00 AM – Wednesday, August 11, 2010 at 5:00 PM (ET)

Good research and information is the core of a successful strategy. As organizations seek to understand how their corporate compliance program stacks up against others it is necessary to get good data. Good data allows you to compare the direction of your current corporate compliance initiatives to others.

To compliance officers/managers understand how their programs stack up, Corporate Integrity invites individuals who are responsible for managing a compliance program to participate in a survey being undertaken by OCEG Fellow & CCEP – Michael Rasmussen of Corporate Integrity, LLC.

If you are responsible for managing compliance within an organization Corporate Integrity invites you to do two things (preferably both):

1 – A personal phone interview. If Corporate Integrity could have a half-hour of your time to ask you some open-ended questions about the trends, directions, and technology needed to execute on your compliance strategy it would be appreciated. In fact, Corporate Integrity will return the favor by offering an additional 30 minutes for you to ask questions on best practices and approaches Corporate Integrity is seeing in its research of successful corporate compliance strategies.

2 – Online web survey. Please take the related online survey 2010 Compliance Trends & Directions.

All those who take the survey will get a summary report in the next few weeks so they can compare how their program, trends, direction, and approach stacks up against others. Any data you contribute to the online survey or phone interview is held as confidential and is used in aggregate – your company will not be identified in the report.

For more information contact:
Michael Rasmussen, J.D., CCEP & OCEG Fellow
Risk & Compliance Lecturer, Writer, & Advisor
Corporate Integrity, LLC
+1.888.365.4560
[email protected]

I have stated it before and I will state it again: the typical organization is a mess when it comes to managing policies and procedures. Organization size does not matter – I have seen small to large organizations that have horrible policy management practices. Policies are scattered across the business, reside in a variety of formats ranging from printed documents to Intranet sites, are out of date, not integrated into other GRC processes such as investigations or risk management, and are poorly written.

Policies articulate culture, they establish a duty of care, define expectations for behavior (for individuals, processes, and business relationships), and establish how the organization is going to comply with regulatory and contractual requirements. Policies are an integral part of corporate governance, enterprise risk, and compliance management. They support a range of other GRC processes: corporate social responsibility, legal, human resources, business operations, security, environmental, health & safety, quality . . . .

A significant short coming in policy management is the failure to define a style guide. A style guide for policies defines standardized:

• Taxonomy. Policies are to have a logical relationship to each other following a hierarchical categorization taxonomy – this is usually done through a numbering system mapped to policy areas across the business.

• Format. Policies are to have a consistent look and feel. Anyone should be able to see a policy and recognize that it is a corporate policy without reading the document.
• Structure. Related to format, policies are to have a consistent structured arrangement of the headings/sections.
• Language. Policies are to have consistent language. Good policies are easy to read and written in the active voice. This includes paragraph, sentence, punctuation, and word guidance for policies.
• Definitions. Policies are consistent in how they use words. Terms used in policies are to be used consistently across the organization with a common understanding of what they mean.
• Process. Policies are to be written and revised following a standardized process. The style guide should outline roles and responsibilities for writing, editing, and approving policies.

Leading organizations are establishing a policy manager responsible for the style guide and consistency of policies. One major brand, who attended my Effective Policy Management & Communication Workshop, has established the role of “Internal Policy Manager.” This person is responsible for managing the development and maintenance of all policies to assure their consistency and relevance to the organization. This role does not own or write policies. In fact, this role has only written one policy – the policy on how to write a policy (in other words a style guide).

BOTTOM LINE: Policy writing that is wordy and confusing is damaging to the corporate image and costs time and money. Every organization should have a policy style guide in place to provide for clear and consistent policies. Leveraging a style guide increases effectiveness.
Good policy writing:

• Articulates corporate culture
• Demonstrates professionalism in the organization
• Shows the organizations cares
• Avoids expensive misunderstandings
• Provides consistency across the organization

This provides a quick summary view of the need and implementation of a style guide for policies. Over the next several weeks we will dive into specific portions of Effective Policy Management & Communication, including:

• Policy writing best practices
• What is the right number of policies?
• Establishing policy ownership and accountability
• Communicating policies across extended business relationships
• Tracking policies attestation and delivering effective training
• Managing policy incidents and exceptions
• Monitoring metrics to establish effectiveness and/or issues with policies
• Relating policy management to risk, issue/case, and other GRC areas
• Using technology to manage and communicate policies

Previous blogs on this topic are:

• Corporate Policies in Disarray and Chaos
• Policies, Done Right, Articulate Culture
• Defining a Policy Management Lifecycle
• Providing Consistency in Policies Through Consistent Style and Language

In addition to this series on policy management, Corporate Integrity is also offering a full-day workshop on the topic of Effective Policy Management and Communication.

I would love to hear your thoughts, experiences, and approaches to effective policy management. Please comment on my blog or send me an e-mail