Category: The GRC Pundit Blog

Multiple interests require multiple threads to weave into the intricate pattern of GRC. I will keep the articles coming on Effective Policy Management & Communication but also have sufficient requests to write more on risk management. So here we begin another series (which runs parallel to policy management) on Developing a Risk Assessment & Management Process. It is in this series we will look at risk management basics, what it is, how it is done, and best practices to implement risk management within your organization.

Everything I need to know about risk management I learned in . . . drivers education. Yes – it is true. Do not leave me now, I am serious. Well sort of serious. There is a lot of depth to risk management and how to conduct it in business that drivers education did not educate me on. But the basics, the fundamentals, of risk management were there.

This past year I have had the opportunity (or should we say threat or vulnerability or exposure) of sending my first two teenage sons to drivers education. One now has his license the other is just getting his permit. The older one who got his license six months a go already has his first accident under his belt (first snow of the year led to increased risk exposure which ended up in loss).

Risk management lessons for me (and anyone else) began at a very young age. One quickly learns not to touch hot things. There is the balance of opportunity and loss. As a toddler we do not get wrapped in protective bubble away from risk. Mom and dad guide us in our achievements and growth while monitoring and managing risk around us. The goal is to be able to function and thrive in a very risky world. Just as in business, risk management is something everyone does it is part of life. It is also part of business. Judge Mervyn King of the Infamous King 2 report on Corporate Governance stated it very well “Enterprise is the undertaking of risk for reward.” Basically business is about taking an managing risk to make money.

Back to drivers education . . . while mom and dad integrated risk management training into my child rearing, drivers education class was my first introduction into a formal risk assessment/management methodology. I was quite happy when my oldest son came home from drivers education a year a go and told me about IPDE. It took me back nearly 25 years (I am 39 and in Montana where I grew up you could drive at 14 and a half). IPDE was same acronym I learned in drivers education many years a go. It got me thinking as to how this first lesson in risk management has stood the test of time. It also integrates and can be mapped into broader risk management frameworks such as the new ISO 31000 standard. It is the functional basis for risk assessment.

The IPDE process is as follows:

• Interpret. Understand your surroundings. From a driving perspective it requires you understand your internal surroundings (the car), the external surroundings (what is happening in traffic and everything else around you), and your destination (where you are going and how that applies to the surroundings). In business it is about your internal business context, the external environment that business operates in, and your strategy as to where the business is heading.

• Predict. Once you understand your surroundings – the 360-degree situational awareness of your internal and external environment – you then can identify what can happen to help or hinder your objectives. The ISO 31000 definition of risk is the effect of uncertainty on objectives. An organization wants to identify the possibilities of outcomes to what can impact it achieving objectives.

• Decide. After the range of potential possibilities is understood, the organization (or the driver from the drivers education perspective) needs to decide what to do. What is going to be the best route for the organization to achieve objectives while minimizing loss/harm. This gets into risk measurement activities of understanding inherent and residual risk while looking at risk strategies of risk acceptance, risk transfer (insurance), risk avoidance, or risk mitigation (controls). The goal is to optimize value and return while keeping risk within acceptable levels of risk tolerance and appetite.

• Execute. The final step is to take action. I have seen a lot of risk assessments done with no follow through – a waste of time and resources. The decide process means nothing if there is no execution on the decision. Implementing the risk treatment and monitoring plans.

There is a lot more depth to risk management in business than these basic steps – but they do provide the most basic framework to think of risk management within.

One more fun tidbit from my drivers education experience as a teenager. As stated earlier, in Montana you can drive at 14 and a half (at least back in the 1980’s). The risk environment in Montana was also interesting with its approach to speed limit laws/regulations. Until 1974 Montana did not have speed limits, it was at this time the Federal Government threatened to withhold highway funds so Montana created a special ticket. If you were going below 90 on a highway during the day it was a $5 ticket called ‘wasting of public resources’ and did not go on your record. A teenage boys driving paradise – but also a risky one. Oh to be young and adventurous.

In addition to this series on policy management, Corporate Integrity is also offering a full-day workshop on the topic of Developing a Risk Assessment & Management Process.

The Atlanta GRC bootcamp is going well! One discussion/interaction point was to define GRC – the group came up with some excellent points. They include:

Most organizations fail to manage the lifecycle of policies. This results in policies that are out of date, ineffective, and not aligned to business needs. It further opens the doors of liability as an organization may be held accountable for the policies it has in place but are not appropriate or is not compliant with.

Effective policy management starts with a lifecycle approach to managing policies. This is the process of managing and maintaining policies throughout their effective use within the organization. This lifecycle is defined in three primary phases:

1. Creation
   
2. Communication
   
3. Management
   
4. Maintenance

Each of these primary phases has several sub-phases.

1 – Creation. The lifecycle of policy management starts with the Creation phase, which includes the following sub-phases:

• Need. It is at this beginning that the need for a policy is determined. It may be a regulatory requirement, values/ethics of the corporation, business partner requirement, best/industry practice, awareness of potential liability, or a host of other reasons that brings the organization to the point of determining that a new policy needs to be established. An organization needs an active risk and regulatory intelligence process to identify when a policy needs to be created.

• Ownership. The next step in the Creation phase is to assign a policy owner. Every policy in the organization should have an individual or business role that is the owner of the policy. Even if the policy is applied across the entire organization, such as with Code of Conduct, it is necessary that someone be established as the owner of the policy to oversee its implementation and monitoring within the environment.

• Writing. Once an owner is established the next part of the Creation phase is writing the policy. The policy should be written in a consistent style, format, and language as all other policies in the organization. Policies are to be clear and easily understood by the intended audience.

• Approval. Once the initial draft of the policy is written, it moves into the approval process of the Creation phase. The owner sends the draft policy over to identified stakeholders needed to approve the policy before going to publication. Some stakeholders may be in the approval stage for every policy written (e.g., human resources, legal). Other stakeholders are approvers because the subject matter touches on their area of the business and they are needed as a subject matter/process expert.

The Creation phase is iterative as the approvers may send back the policy requiring changes before it is approved and everyone comes to agreement that it is the right policy for the corporation.

2 – Communication. After the Creation phase comes the Communication phase. Communication involves the sub-phases of:

• Publication. After approval, the policy then needs to be published. Publication can be in printed policy manuals or on Intranet sites. Unfortunately, many organizations have scattered systems to publish policies and procedures without a single authoritative source. This often complicates the management of policies. Multiple publication places adds to the number of policies that become out of date. Best practice is to have a single policy publication engine in which any individual within the environment can login and see all of the policies that apply to his/her specific job role in the organization.

• Training. We live in the day of YouTube. It is no longer good enough to have just published a policy. Organizations have to actively show that individuals understand the policy and what is required of them. This requires that certain policies have associated training in either online or classroom formats to validate they understand the policy(s). Surveys and testing is an integral part of training to validate that individuals understand policies.

• Attestation. Once an individual has read a policy, and taken any associated training, it is next necessary to track their attestation to the policy – that they will adhere to it. Some policies such as Code of Conduct by their nature require specific attestation to on a regular basis (e.g., annual). Other policies may be grouped together in an attestation. While some policies it may be determined do not need specific attestation.

3 – Management. After a policy is communicated it enters the ongoing management phase. The management phase of the policy lifecycle contains:

• Enforcement. The policy is monitored for compliance within the organization. Specific controls that the policy authorizes are established and monitored to determine if the policy is being complied with. Incidents of non-compliance and policy violation are noted to provide feedback when the policy is next reviewed.

• Exception management. While policies are to be complied with there are instances that arise in which the organization accepts non-compliance. These exceptions have to be documented and managed. An exception is granted for a specific time period and is to be reviewed to validate that the exception is still needed.

4 – Maintenance. The final phase of the policy lifecycle is maintenance. The maintenance phase includes:

• Review. Every policy is to have a regular review cycle. The review of a policy should be done at least annually. It is during the review process that the policy owner looks at the incidents of non-compliance and exceptions granted alongside of the business requirements driving the policy. It is in this process that the policy is either authorized as is for another management cycle, goes back into the creation phase to update and approve the policy, or is archived for retention. The updated policy then moves into the communication phase.

• Archival. Every policy, and version of a policy, is to be archived for referral at a later point in time. When an organization becomes aware of an incident or a regulator has a question it is necessary to have a full view into the history of a policy – the owner, who read it, who was trained, who attested and on what version of the policy.

This provides a quick summary view of the policy lifecycle. Over the next several weeks we will dive into specific portions of the lifecycle, including:

• What is the right number of policies?
• Establishing policy ownership and accountability
• Providing consistency in policies through consistent style and language
• 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

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.

We now turn our attention back to my series on Effective Policy Management & Communication.

In the previous posting we looked at the disarray and chaos of how policies are managed, maintained, and communicated within organizations. Often inconsistent, poorly written, out of date, lacking consistency, developed with no style guide, and ineffectively managed and communicated – corporate policy management in most organizations is a mess. Now we will turn from our flogging of the corporate policy mess to constructively developing an effective policy management process.

The first point to clearly understand – policies, done right, articulate the corporate culture.

Unfortunately, most organizations have not connected the world of policies to how they influence and establish corporate culture. Granted – corporate culture is there with or without policies. However, without policies there are no written standards as to what is acceptable and unacceptable conduct. Culture is allowed to morph and change without policies. The organization can quickly become something it never intended.

Policies provide a definition of the boundaries of the organization. At the the highest level it starts with the Code of Conduct laying forth ethics and values that extend across the enterprise. These filter down into specific policies at the enterprise level, down into the business unit, then department, and to individual business processes. Policies are supported by procedures. Both policies and procedures at the statement level establish and authorize controls by which the organization is closely managed and monitored.

Policies articulate the culture of compliance. They define what is acceptable and unacceptable. This starts at the ‘Mandated Boundary’ level of communicating what is right or wrong legally and how the organization will stay within legal boundaries within the various jurisdictions that it operates in. Policies then extend to the ‘Voluntary Boundary’ level to articulate what is acceptable and unacceptable when it comes to matters of discretion – ethics, values, code of conduct, corporate social responsibility, and other areas. Both the mandated and voluntary boundaries are written into policies so that individuals within the organization and its relationships know what is acceptable and unacceptable. It should not be open to broad discretion and interpretation.

Policies articulate the culture of risk. Every organization takes risk, it is part of business. Without clearly written guidance as to what is acceptable and unacceptable risk the organization is like a ship without a rudder. Policies provide clear guidance on what is acceptable and unacceptable risk, define risk acceptance and tolerance levels, and establish who owns and manages risk.

Please do not misunderstand me – policies are not a magic answer to culture, governance, risk, and/or compliance. Not at all. An organization can have a wide array of policies that are not adhered to and end up in very hot water. Policies ARE a way to clearly define, articulate, and communicate what the boundaries, practices, and expectations of the organization are. While you can have a horrible culture with policies, you cannot have a strong and established culture without them. The right policies are necessary to define and communicate what the organization is about.

Culture itself is broader than policies – policies are the vehicle that communicates and defines culture so that culture does not morph out of control. This requires that policies be adhered to, exceptions closely managed, and violations dealt with.

Over the next several weeks we will continue to look at Effective Policy Management and Communication. We will specifically explore:

• What is the right number of policies?
• Defining a process lifecycle for managing policies
• Establishing policy ownership and accountability
• Providing consistency in policies through consistent style and language
• Communicating policies across extended business relationships
• Tracking policies attestation and delivering effective training
• 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

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.

Business is complex and dynamic, and requires agility to stay competitive. Market leadership requires the organization be quick to respond to changing conditions – to pause means loss. Governance, risk, and compliance (GRC) processes often work against business agility. Requirements and initiatives managed across numerous silos, using manual or varying technology approaches, burden the business. The lack of a common process and technology architecture comes at a significant management cost.

Whether the enterprise uses the “GRC” acronym or not, the fact is, every organization practices 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 is, GRC has been a part of business since the dawn of business.

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

The bottom line: Organizations spend more money on risk and compliance than they should, because of inefficient GRC processes.

Organizations have relied on manual and basic technology to manage risk and compliance processes. The cost to the business of inadequate GRC approaches is significant. Some areas where organizations report significant issues and cost include:

• Excessive paper and spreadsheets.
• Limited and fragmented reporting.
• Files and documents out of sync.
• Significant spend on external auditors and consultants.

A common GRC architecture makes risk and compliance efficient and manageable. Inefficiencies, redundancy, errors, and potential risks are identified, averted, or contained. This reduces risk exposure, and enhances business agility and performance.

Organizations require an enterprise view of GRC that not only brings together silos of risk and compliance, but integrates them into a common GRC architecture.

Robust GRC systems contain multiple applications, such as risk management, policy management, audit management, and document management. The individual functionality of each GRC application is key to achieving the desired results.

A less obvious and often overlooked key to GRC success lies in the integration and consistent design of each application. GRC systems lacking a common architecture (backbone), common user interface, and consistent processes and functional behaviors seldom deliver the full value and benefits sought by the organization. In fact, use of a collection of disparate GRC applications has been repeatedly demonstrated – in real-world settings – to actually reduce visibility and increase risk.

Business requires GRC architecture with a common user experience and seamless application and data integration across GRC modules. Specifically, value and economies are achieved when the GRC suite of applications delivers a common:

• User and role-centric experience: The GRC application should meet the needs of each user accessing it, with relevant information, tasks, and processes specific to the business role.
• Business-process orientation: A GRC application needs to automate business processes through workflows and elimination of information redundancy. Consistent risk and compliance management is essential to achieving value.
• Environment focused on flexibility: A common GRC architecture not only allows for consistency, but also provides business agility in adapting GRC processes to a changing business.
• Collaborative and information-rich experience: Business requires a GRC architecture that facilitates collaboration across business roles and presents information with respect to intricate relationships and within the appropriate business context.

In summary, business today requires a common GRC architecture that is context-driven and adaptable to a dynamic and changing business environment.

Simply put, a common architecture can enable a better-performing, less costly, more flexible solution. Organizations should not assume that all software platforms labeled “GRC” deliver a common technology architecture. Some solutions are assembled without a consistent strategy – a stream of mergers and acquisition activities compounds the problem, as the organization ends up with several code bases and data models.

A software system with a common architecture has the following:

• A common user interface (screen design) for all applications.
• A common workflow engine throughout the applications.
• A common security model to protect applications and data.
• A common programming language used to build the applications.
• A common database used to run the applications.
• A common enterprise architecture (a method for describing the departments and divisions within the organization).

Not all GRC software platforms are created equal. Some are a hodge-podge of technology because of a history of mergers and acquisitions; some are rushed to market without a common application and information architecture.

Delivering value and economies in GRC requires the application is built on a common architecture. With a common GRC architecture, the organization achieves business agility, consistency, efficiency, transparency, and accountability across GRC processes.

When investigating GRC solutions, Corporate Integrity encourages you to ask your technology provider the following five questions to expose the risks of a potentially flawed architecture:

1. Which portions of the current solution did you build, and which did you buy or obtain through acquisition?
2. Which portions of the system were developed by a third-party development firm?
3. Are all consultants and trainers certified in each application module?
4. Describe how the data for each application is stored in the database(s)?
5. If you change the architecture of an application or consolidate architectures for multiple applications in the future, will you guarantee:
   
   • No loss of current features or functionality?
   • A full migration to the new architecture at no additional cost?

For the full text on this – please download my research piece: The Value of a Common Architecture for GRC Platforms. I would love to hear your thoughts, experiences, and approaches to GRC Technology. Please comment on this blog or send me an e-mail

When you think you have heard everything . . .

One of the attendees at the San Jose GRC Fundamentals, Strategy, and Technology Bootcamp today shared an interesting conversation she had.

In pursuing discussion with other organizations that have implemented GRC strategies, one told her that they actually had to get a psychologist involved. That is right – a psychologist. 

It appears that the firm had so much disagreement and pull in different directions they brought a psychologist in to help the different factions work through their issues and come to common agreement on a strategy (which actually came down to two strategies when implemented).

So in the world of the GRC EcoSystem there is a new line of professional services – GRC psychologist. Build a room full of couches.

The question before you – do you need GRC consulting or GRC counseling?

The San Jose GRC Fundamentals, Strategy, & Technology bootcamp is underway with terrific interaction. The bootcamp is comprised of implementers of large down to medium sized organizations, professional service firms, and a few technology providers.

2010 is proving to be an interesting year for the reorganization of the GRC space. It kicked off with the public announcement of the EMC/RSA acquisition of Archer Technologies. Shortly thereafter you had the announcement of the merger of BPS and Resolver.

I just passed the Certified Compliance & Ethics Professional (CCEP) exam from the Society of Corporate Compliance & Ethics (SCCE). While I meant to do this years a go – I never got around to it.

Policies are a critical component of a GRC strategy – but often the most overlooked or neglected component. It amazes me the number of companies I go into that have complete disarray and chaos in their approach to managing corporate policies and procedures.

Simply put – organizations cannot ignore policy management. Consider that:

• Policies establish the culture, value, ethics, and tone of the organization.
• Policies establish boundaries for risk taking.
• Policies define how the organization complies with regulations and requirements.

Mismanagement of policies and procedures can introduce liability to the organization as a policy or procedure can establish a duty of care. Improper policy management can be used by regulators, prosecuting/plaintiff attorneys, and others to place culpability on an organization.

The typical organization suffers with ineffective policies, management, and communication. The typical organization has:

• Policies scattered across dozens of places. The typical organization has numerous portals and binders in which policies are published. There is no single authoritative source where all policies and procedures are consolidated, maintained, and managed. There is no place where an individual can see all the policies that apply to their specific role in the organization.

• Policies bound by paper. The typical organization still suffers with having numerous printed policy manuals and has not fully embraced online publishing and access to policies and procedures.
• Policies grossly out of date. The typical organization has policies that are published at some point and time and not reviewed on a regular basis. In fact, I regularly encounter organizations that have policies that have not been reviewed in years for applicability, appropriateness, and effectiveness.
• Policies that lack an owner. The typical organization has numerous policies and procedures that lack an owner that is responsible for managing them and keeping them current.
• Policies that lack any lifecycle management. The typical organization has an ad hoc approach to writing, approving, and maintaining policies with no defined system for managing the workflow, tasks, versions, and approval process.
• Policies that do not map to exceptions or incidents. The typical organization finds that it has no established system to document and manage exceptions to policies. Further, there is a lack of a system to map incidents, issues, and investigations to policies – this helps to understand where policies are breaking down and need to be addressed.
• Policies lack adherence to a consistent style guide. The typical organization has policies scattered across the organization with no through to the consistency, style, and template as to how they are written. The language and format of policies vary significantly within organization policies and procedures.

These issues are further compounded when organizations approach technology for policy management in an ad hoc manner and begin publishing policies through various content management systems (e.g., SharePoint sites) with no process to manage consolidate, manage, and keep policies consistent.

In summary, organizations are in a complete disarray in managing corporate policies and procedures – policies are out-dated, scattered across parts of the business, and not managed consistently. The recent trend in legislation and regulatory guidance is to demonstrate training and not just attestation. Policies establish the culture, values, ethics, and duties of the corporation and its agents. Organizations that take an ad hoc approach to managing and communicating policies face significant risk to their business.

When the organization is under the microscope – having a detailed trail of what policy was in effect, how it was communicated, who read it, who was trained on it, who attested to it, what exceptions were granted, what other incidents violated the policies all can provide grounds for defending the organizations. An ad hoc ‘dust in the wind’ approach to policy management may very well expose the organization to significant liability.

To consistently manage and communicate policies organizations are turning toward defined processes, workflow, and technologies to manage the lifecycle of policies. The policy management lifecycle involves several stages from definition, approval, communication, awareness, training, attestation, maintenance, and archiving. This is supported by a technology infrastructure to manage the content and process of policy management.

In the generation of Web 2.0 and YouTube it is no longer enough to simply make policies available, organizations need to deliver training and establish that individuals understand policies and procedures. Delivering interactive policy training modules has become just as important as presenting a written policy and tracking attestations.

Over the next several weeks we will look at Effective Policy Management and Communication. We will specifically explore:

• Defining a process lifecycle for managing policies
• Establishing policy ownership and accountability
• Providing consistency in policies through consistent style and language
• Communicating policies across extended business relationships
• Tracking policies attestation and delivering effective training
• 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

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.