Category: The GRC Pundit Blog

The GRC software space is vast with numerous vendors.  In fact, in my market models there are over 400 GRC software providers that span 28 primary categories (with numerous sub-categories) of GRC related software.  Nine of these categories encompass components of an enterprise GRC platform (though no vendor does all nine components), 19 of the categories are focused in specific business functions/processes of GRC.  Of the 400 vendors, it is under 50 that market and present themselves in the enterprise GRC domain.

How does an organization make sense of all of this? How do you know what you are buying is the right platform and right vendor for your organization?

Before I give some guidance on this – let me first state that GRC software is needed in organizations.  Using a document centric approach done in spreadsheets and word processing documents is prone to issues.  Issues in consolidation and reporting – both errors and time it takes.  Issues in accountability in audit trails – to validate that things were not changed to get someone or the organization out of trouble, or paint a rosier picture of the organization.  Issues in efficiency as document centric approaches take more resources to manage.

The issue is sifting through all the vendors with their offerings to find the one that best fits your organization.

My advice on buying GRC (and related risk and compliance software):

• Get to know the vendor.  I have spent nearly twenty years in this space.  There are good vendors and bad vendors.  There are good sales people and bad sales people.  A successful software implementation is going to require a relationship.  Make sure that the vendor and sales person you are considering doing business with is someone you want to work with.  Someone that is arrogant or pushy is going to give you headaches and make your life miserable – they will always be pushing for the next deal and expanding the platform.  Pick the vendor that appears to have your best interest in mind and not theirs.
• Understand who the vendor typically sells to – industry and role.  Every vendor in this space has a history and track record.  Some have strengths in audit or risk or compliance or information security or some other role.  Some have a history in financial services while another is healthcare.  While many vendors can serve across several roles where they have historically sold their platform into will tell you where their dominate strengths lie.
• Use caution with Forrester Waves and Gartner Magic Quadrants.  Too many organizations see whoever is in the upper right quadrant and pick them for their short list.  THIS IS A MISTAKE.  These documents have their value, but just because someone appears to be the leader does not mean they are the best fit for your organization.  That ‘winner’ may serve primarily Fortune 1000 banks, while you are a mid-size hospital.  They may be strong in risk while you are looking for a strong compliance solution. Do not assume that the leaders in these research pieces are what will be best for your organization.  There may be a vendor not even in the research that is the ideal fit for you.
• Check references.   Require that the vendor give you references – and check them.  Grill the references.  Ask questions on what they like least about the vendor and the solution. Ask them what they would change.  Many of these references have sweet deals from the vendors and are spokespeople for them – you need to grill them and look for the chinks in the armor.  I would also use social networking (e.g., LinkedIn, Twitter) to ask for experiences of others.  Talk to analysts and insist on knowing the good, the bad, and the ugly.  If the analyst does not have much to offer – go to one that has experience.
• Control the vendor.  A huge issue with GRC software projects is when the vendor sees $$$.  I have seen situations in which the sales person is striving for a much bigger sale than what the organization is ready for.  In these cases the sales person has taken it upon themselves to knock on other doors across the organization in an attempt to get buy-in to a GRC vision and fix corporate political issues.  This kills GRC projects.  Go back to the first bullet above – know your vendor and make sure it is who you want to do business with.
• Get in the drivers seat.  A HUGE ISSUE is that some vendors are great at demos.  They can find out what you need and go back and build some mock-ups that look great. When the deal closes they have not told you that they have to build out much of the functionality they demonstrated and do so on your dime.  It is important that you demo the solution and get behind it yourself.  Build scenarios of what you want to accomplish, do not give all the details to the vendor (just the general goals) and sit behind it and walk through it.  This will make your decision much clearer as the system that is easiest to use will quickly become apparent.
• Test your enterprise needs.  Some vendors work great when operating in a specific business department, but their risk analysis and reporting falls apart as you try to aggregate, normalize, and report on information on an enterprise level – as with ERM (Enterprise Risk Management).  I have had one senior executive tell me that they never want to see a heat map again as their GRC/risk vendor’s reporting was a mess and what appeared on the heat map was comparing apples and oranges.

Understanding and Approaching Compliance and Ethics Risk

Historically the compliance function did not understand and model processes for risk management. Compliance documented and met requirements, and found and resolved issues. There was limited modeling of compliance issues and risk to determine business impact and prioritization of resources. Most often compliance was reactive, putting out fires instead of actively interpreting and predicting compliance and ethics risk issues, and developing treatment plans to mitigate or avoid damage to the organization.

The CECO in the 21st century must take a risk-based approach to compliance processes. This requires the organization to take in information from the external business and regulatory environment, understand the current and future context of a dynamic and distributed business, and model risk and business impact today and into the future. In some industries CECOs are best served to use risk models that support decision tree and scenario analysis to model risk in their environments, but can also benefit from heat maps, MARCI charts (mitigate, assure, redeploy, and cumulative impact), and even quantitative approaches such as loss distributions in Monte Carlo simulations to portray loss and impact (if there is enough data to make these meaningful).

Regardless of the complexity of the analysis, the principles of compliance risk management are the same:

• Understand your risk: An organization needs to have a risk-based approach to managing compliance and ethics. This includes a periodic assessment (e.g., annual) of the exposure to the organization for unethical conduct. However, the risk assessment process should also be dynamic, done each time there is a significant business change that could lead to exposure and incidents (e.g., mergers and acquisitions, new strategies and entry into new markets).
• Approach compliance based on proportionality of risk: How an organization implements compliance procedures and controls must be based on the proportionality of the risk it faces. If a certain area of the world or a business partner receives a high risk score for ethics or corruption, the organization must respond with stronger compliance procedures and controls. Proportionality of risk also applies to the size of the business — smaller organizations are not expected to have the same measures as large enterprises.
• Monitor the risk and regulatory environment: Content and information on changes to risk and regulatory environments is critical. New laws, changed regulations, court rulings, and standards of practice all change what is required of the organization. The compliance function needs to have a defined process and be accountable to monitor risk of changes in the regulatory environment.
• Tone at the top: The compliance risk management program needs to be fully supported by the board of directors and executives. Communication with top-level management must be bidirectional. Leadership must communicate what is both acceptable and unacceptable risk, and support the compliance and ethics program. Executives and the board must be informed about the effectiveness and operations of the compliance and risk management strategy to fulfill their fiduciary obligations.
• Know who you do business with: Organizations need to know their business relationships. This requires that an established risk-monitoring framework is in place that catalogs the organization’s third-party relationships, markets, and geographies. Due diligence efforts must be in place to make sure the organization is contracting with ethical entities. If there is a high degree of risk of corruption, compliance, or ethical issues in a relationship, additional preventive and detective controls must be put in place. This goes beyond business partners: this means knowing employees, and conducting background checks where needed in order to understand if they are susceptible to corruption and unethical conduct.
• Keep information current: Due diligence and risk assessment efforts must be kept current. These are not point-in-time efforts, but must be done on a regular basis or when the business becomes aware of conditions that point to increased risk to ethics and compliance issues.
• Compliance oversight: The organization must have someone responsible for oversight of compliance risk processes and activities. This includes the authority to report compliance and ethical risk to independent monitoring bodies such as the audit committees of the board.
• Manage change in the business: The organization must monitor the business for changes that can impact its compliance and ethics program or introduce greater risk to corporate integrity. The organization needs to document changes required for business practices as a result of observations and investigations, and must implement changes through a deliberate program of change management. These changes must be monitored by compliance to actively prevent corruption.

• The court found Frederic Bourke, Jr. was willfully blind and as an investor he should have done more due diligence and should have known that the energy company he invested in bribed foreign officials.
• The government told Nature’s Sunshine’s CFO and COO they should have had better controls over financial reporting, even though the SEC never stated they specifically knew of the bribery happening within the corporation.
• The average cost of an FCPA settlement is $50 million plus the expense for an external monitor to validate a compliance program is in place for the next 10 to 20 years. This does not include investigation expenses.
• The U.S. Department of Justice assessed nearly $2 billion in fines in 2010. Eight of the top 10 FCPA settlements occurred in 2010. BAE Systems was the third largest fine at $500 million. Daimler AG had $185 million in fines and disgorgements. Snamprogetti had $365 million in fines (the fourth-largest).
• Charles Jumet, former VP of Ports Engineering Consulting Corporation, was sentenced to 87 months in prison.
• Siemens spent $850 million in fees and expenses to investigate anticorruption. Daimler had a five-year investigation that cost over $500 million.

• Commitment
• Implementation
• Monitoring and measuring
• Continual improvement
• In addition, mandates such as those provided by the Australian Securities and Investments Commission (ASIC) and Australian Prudential Regulation Authority (APRA) broaden the scope and compliance requirements for listed organizations or those within the financial services industry.

This is the second in my series on Compliance Management in the 21st Century. The previous ones have been:

• From Finding and Fixing Problems to Compliance Risk Management 

I would love to hear your thoughts as well – please share them.

For those that cannot wait for all of my upcoming posts – you can read my thoughts and perspectives in my most recent written report:  Compliance Risk Management in the 21st Century.

Before even getting into technology and vendors it is necessary to understand what GRC is about.  I argue that GRC is nothing new – we have been doing GRC long before we had an acronym that I first started using back in 2002. The truth is organizations have governance, risk management, and compliance (GRC) practices and processes in place.  Your organization is doing GRC whether you call it GRC or not.  These processes are most likely siloed and scattered across the organization.  They may be formal processes or informal, they may be defined and written down or ad hoc.  You will not find an executive that states we lack governance, do not manage risk, and can care less about compliance.  Whatever you may call it – the truth is that GRC exists in your organization.

So why all this fuss over GRC?  There are better ways of doing things.  The goal is to make GRC processes that already exist in the environment more effective at meeting obligations and managing risk, more efficient in use of financial and human resources, and more agile to the needs of a dynamic and distributed business environment.

Thus enters technology – GRC technology is used to go bring greater effectiveness, efficiency, and agility to GRC processes across the organization.  One goal is to move beyond documents and spreadsheets that have there issues (such as no audit trail, difficulty reporting). Another goal is to share information and provide a framework for collaboration across risk and compliance roles.  Finally, a goal is to provide shared processes and technology.

I often hear the line of business screaming “ENOUGH.”  This week it is a SOX assessment, next week an oprisk assessment, the week after that a business continuity assessment, and then five others.  Several come in spreadsheets formatted differently, others in web survey tools, others in software applications.  There are a dozen of more file shares or intranet sites claiming to have corporate policies – where is the correct one? How come they are in different formats?  Who is controlling this?  Investigations, incident, and issue systems are scattered across several areas as well.

Organizations are waking up to the fact that GRC can be more effective, efficient, and agile.  Thus enters technology to enable it.  GRC technology is very much like CRM (client relationship management) technology back in the 1980’s which are a core part of business today.  Before we had CRM we still managed client relationships.  The issue is that we had out of sync data and no one had the complete picture of the client.  Sales had their view, marketing theirs, and then service theirs.  CRM systems came in to provide a holistic view of the client – one complete and accurate picture that all these roles in their respective capacities can access.  The same for GRC technology – there are a variety of roles across the business doing aspects of risk and compliance that have very similar information and process needs though they maintain their individual subject expertise.

I will state that there is no single vendor that does all of GRC from a technology perspective.  There are over 400 vendors that do aspects of GRC.  I model the market around 28 categories of GRC software (this will be released in a few weeks in the updated OCEG Solutions Guide for GRC).  Several of these technology categories span needs across the enterprise others address needs within specific functions.

In my work in GRC market research, education/training, and advisory I get involved in over 200 interactions each year with organizations looking for GRC technology.  Most, as much as 90%, are focused on specific issues while about 10% are truly focused on enterprise GRC initiatives.  However, even those focused on specific issues want to invest in technology that can address other issues and grow and expand into enterprise GRC over time.

Looking over the past two years of interactions with buyers of GRC software, the top five GRC vendors that I see most often in RFPs/RFIs are (in alphabetical order):  BWise, MetricStream, OpenPages, RSA Archer, and Thompson Reuters Accelus.  Of these it is BWise and RSA Archer that most often come up in interactions.

This does not necessarily mean that these vendors are the best for you.  There are aspects of the 28 categories of GRC that they do not do.  Every vendor has their strengths and weaknesses.  Depending on organization size, industry, complexity, and needs the vendor you want to engage will vary.  In fact, several organizations I have interacted with have four or more GRC vendors in place doing different parts of GRC.

Other vendors that I frequently encounter include (in alphabetical order): ActiveRisk, Compliance 360, CMO Compliance, CURA, Easy2Comply, EthicsPoint, Lockpath, Mitratech, Oracle, QUMAS, SAI Global, SAP,  SAS, and Wolters Kluwer.

Beyond this group are vendors such as Agiliance, AlineAlytics, AssurX, BPS Resolver, Chase Cooper, Continuity Logic, Global Compliance, MEGA, Methodware, Modulo, Policy Technologies, The Network, Pilgrim Software, Process Unity, and RSAM.

Here I have only touched on a few dozen of the 400 vendors in this space.

If this topic interests you, I would encourage you to consider my upcoming online training on the GRC technology market.

State of the GRC Market Q4-2011 FRIDAY, OCTOBER 14, 2011 EASTERN TIME 12:00 PM – 2:00 PM / PACIFIC TIME 9:00 AM – 11:00 AM / GMT 4:00 PM – 6:00 PM

Today’s complex and competitive GRC market demands that you be at the top of your game.  Corporate Integrity is the leading GRC market research and education firm.

This webinar is Corporate Integrity’s quarterly uddate on the State of the GRC Market.  This is the summary of Corporate Integrity’s market intelligence that spans several hundred interactions/conversations with GRC technology buyers each year.  It is an excellent opportunity for organizations looking to buy technology to learn what is going on in the market.  It is a necessary educational opportunity for technology providers to understand the GRC market and refine their strategies.

Attendees will be able to answer the following questions:

• Who are the leading (most active) GRC technology providers?
• Why are organizations buying GRC technology?
• What differentiates the GRC technology providers?
• How do you categorize and define the GRC technology market?
• What is the market size of the GRC technology market?  Where will it grow?
• What are the leading risk and compliance drivers for buying GRC technology?
• What is the value that organizations have achieved by implementing GRC technology?
• Where is GRC technology headed?
• What are the different needs of GRC roles (e.g., audit, risk, compliance, IT, finance, legal)?
• Who are some of the up and comers in GRC technology that I should be watching and why?

Organizations often lack an auditable means of policy communication, attestation and training. There are various processes and approaches to tracking policy attestation and certification (making sure policy documents are read and understood), and corresponding quizzing and training. The organization must provide full visibility into who accessed a policy, accepted it, was trained on it, and passed or failed quizzes to gauge understanding — all things that provide the organization with a stronger defensible situation with regulators and in legal actions.

Organizations that approach policy without clear accountability face significant risk to their business. This accountability applies to policy owners for their ongoing review and maintenance of policy, the process of granting exceptions, monitoring incidents and violations of policies and extends to policy governance to track reading, acceptance, and training on an individual basis.

When the organization is under a 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 provide grounds for defending the organization. An ad hoc “dust in the wind” approach to policy management may expose the organization to significant liability. This liability is further exacerbated by the fact that today’s compliance programs affect every person involved in supporting the business both internally, and for third parties. If policies look different, use words with different meanings, are located in different places and don’t offer a mechanism to gain clarity (e.g., a policy helpline), organizations are not positioned to drive desired behaviors or enforce accountability which aid in improving performance, producing predicable outcomes, mitigate compliance risk, and avoid incidents and loss.

Most organizations fail to manage the lifecycle of policy, resulting in policies that are out-of-date, ineffective, and not aligned to business needs. It opens the doors of liability, as an organization may be held accountable for policy in place that is not appropriate or properly enforced. Organizations require a consistent process to develop, communicate, monitor, and maintain corporate policy and procedures. This requires collaboration across business roles with clear accountability throughout the process.

1. A well designed Policy Lifecycle Management process.
2. An organized Policy Management Committee to govern the oversight and guidance of policies and ensure policy collaboration across the enterprise.
3. An individual assigned to the role of Policy Manager to assure accountability across the policy lifecycle to the standards, style, and process defined by the Policy Management Committee.

Policy Lifecycle Management is the process of managing and maintaining policies throughout their effective use within the organization. It involves defined stages of monitoring business change for policy development, communication, and maintenance. Implementation of Policy Lifecycle Management requires a technology architecture that is rich in content management, workflow management, process management, task management, notifications, and has a robust accountability audit trail. The lifecycle is defined in five primary stages: Environment Change, Policy Development, Policy Communication, Policy Management, and Policy Maintenance.

The Policy Management Committee provides the structure and connective tissue to coordinate and drive consistency across the organization and is comprised of team members that represent the best interest and expertise of the different parts of the organization. They leverage the knowledge, charter and the authority of the committee to benefit their business areas and, at the same time, benefit other business areas and the organization as a whole.

Policy lifecycle management that addresses accountability brings integrity and value to policy management. It provides accountability to policy management processes that are often scattered across the organization. It enables policy management to work in harmony across organization functions delivering efficiency, effectiveness, and agility. In today’s environment, ignoring a accountability in policy management means processes, partners, employees, and systems that behave like leaves blowing in the wind. Policy management processes are constantly in disarray when operating autonomously, introducing risk in today’s complex, dynamic, and distributed business environment. Organizations require an enterprise view of policy accountability and collaboration that not only brings together silos, but integrates them into a common policy-management process.

Investigations management processes are enabled through implementation of the right investigation technology platform. The technology solution is crucial, because it offers the adaptability needed for the dynamic nature and geographic dispersion of the modern enterprise.

Investigation management applications are intended to manage, in one common framework, all departments, divisions, related companies and types of investigations and incidents. This investigation management platform enables investigation team members to be shared across multiple entities (companies, divisions and departments) as needed, or restricted to just one entity or set of discrete participants when appropriate. Investigations platforms offer a common and consistent approach to report incidents (e.g., hotlines), handle escalation, manage investigation processes, and analyze loss. They enable an organization to evaluate the criticality of incidents, assign investigation team members, monitor business impact, manage the investigation process, and report on loss and impact across business areas. It maintains detailed investigation history and audit trails, manages the lifecycle of investigations, links incidents to remediation procedures, and identifies trends to monitor similarities and relationships across investigations.

Organizations considering an investigation management platform should evaluate the following during the selection process:

• Organization management:Whether it is a business process, a physical asset, an information asset, a business relationship, an individual, or the entire organization, investigations apply to some structure of the organization. An investigation management system needs the ability to model the organization and map investigations to organizational structure categories — whether geographic, process, business unit, or information.
• Accessibility:Investigations generally require the involvement of multiple individuals across an organization. An investigation management system must provide secure access and a complete system of record that an individual can log into to find required tasks, evidence management, and related policies and procedures to guide investigation activities.
• Workflow:Investigations require process management through a standardized workflow. This provides the ability to prioritize, assign and track incidents from identification to resolution. Within each incident the organization should have the ability to assign a lead investigator and support staff, and notify personnel when incidents enter their case-management queues.
• Task management:An investigation management system delivers the ability to track a variety of activities at different stages of execution. Tasks are assigned and communicated based upon roles, responsibilities and incident category, providing a collective overview of each individual’s task list of outstanding work items and due dates, and prompts individuals with reminders of upcoming activities.
• Content management:An investigations platform requires a breadth of content management functionality, including content repository, version control, access management, and records and retention management. This is typically the portion of the application that will provide collection and management of evidence, as well as details about how the investigation was conducted.
• Audit trails:Every assignment, person, piece of information collected, developed, changed, distributed, archived, surveyed, notified, and read should be accompanied by an audit trail to document every who, what, where, and when. The level of audit trail needed for investigation management cannot be maintained with manual processes and ad hoc systems spread across an organization.
• Interaction with other GRC applications:When incidents or investigations occur, it is important to identify not only what went wrong, but to make changes that can prevent similar occurrences. Policy, risk, control, and compliance applications must be cross-referenced to investigations and share information.
• Enterprise loss analysis: The solution should have capability to categorize, measure, allocate, record, and report on losses across the organization. This includes analytic capabilities to model and report on loss trends — such as root-cause and trend analysis, ability to report on loss and event data to the control environment, as well as the ability to provide for loss distributions and calculations.
• Remediation management: The solution should have ability to track and manage the remediation process. Specifically, organizations must look for the ability to track and monitor the status of remediation such as recognized control gaps, audit findings, safety violations, and regulatory interactions and reporting.
• Hotline integration and reporting: An important feature is the ability of the system to integrate with the organization’s anonymous hotline/whistleblower system used to report incidents and events. The system should be able to inquire reporters (whether known or unknown) to communicate investigation status as well as ask further questions needed for the investigation.
• Security architecture: Investigations management platforms are effective only if the organization can tightly control access to sensitive information. Security is a critical element of consideration in an investigations platform — an inherent weakness in spreadsheets and homegrown databases. Organizations must select a solution with proven security architecture with features such as role-based administration of privileges, integration with directory services, secure-access incident data down to the individual field level, protection of the identity of the individuals involved, and ensuring the integrity of the organization’s confidential information.
• Reporting and dashboarding: An investigations management platform provides an easy-to-use interface for reporting and managing investigations. Specific features to consider include the ability to monitor investigation status, measure and report on impact, production of reports to track incidents by type, date, person, location, financial impact and other attributes. Dashboards provide management with real-time access to current incidents, resolution status, key metrics, and the relationship of incidents or events, to identify trends and relationships.
• Configuration flexibility: The strongest solutions support flexible configuration without code customization — configurability refers to the ability to manage structures, rules, data elements, workflow, fields, interface layout, and user-interface characteristics without customization.
• Usability: Investigation personnel should be able to use the system without being technically savvy. Organizations should select a solution that has an intuitive look-and-feel with navigation, and presentation of information that minimizes the need for user training, particularly when some investigations and participants may use the system infrequently.
• Scalability: Platforms must be able to handle multiple people accessing the systems from across a distributed enterprise that may span the globe, with many investigations occurring simultaneously and at different stages of the process.

I would love to hear your experiences and thoughts on what to look for in investigation management platforms, please follow the link to comment on my blog.

Policy management is a critical component of a governance, risk, and compliance (GRC) strategy because it describes the desired practices and behaviors of the company under specific circumstances. Too often, the organizational approach to managing corporate policies and procedures is in complete disarray and chaos. The breadth and depth of the voluminous increase in relevant laws and regulations can’t be grasped in the manner enterprise behaviors are currently directed and coordinated.

The typical organization suffers with ineffective policy structures, content, coordination, lifecycle management, accessibility, accountability, and communication. As a result, organizations have:

• Policies scattered across dozens of places: There is no single authoritative source where policies and procedures are consolidated, maintained, and managed. No single portal exists where an individual can see the policies that apply to their role, structured to support efficient access.
• Policies bound by paper: With numerous printed policy manuals, the typical organization has not fully embraced online publishing and ubiquitous access to policies and procedures.
• Policies grossly out of date: In most cases, a published policy is not reviewed and maintained on a regular basis. In fact, many organizations have policies that have not been reviewed in years for applicability, appropriateness, and effectiveness.
• Policies have no owner: The typical organization has numerous policies and procedures that lack an owner responsible for managing them and keeping them current.
• Policies lack lifecycle management: Most organizations maintain an ad hoc approach to writing, approving, and maintaining policy with no defined system for managing the workflow, tasks, versions, approval, and maintenance processes.
• Policies do not map to exceptions or incidents: Typically, an established system to document and manage exceptions to policy is missing. Further, there is a lack of a structure to map incidents, issues, and investigations to policy — the organization is unaware of where policy is breaking down.
• Policies do not map to standards, rules, or regulations: The typical organization does not have the ability to define and maintain a record of policies that address legal, regulatory, or contractual requirements. The organization does not have the ability to easily assess the impact of new or changing regulations that affect policy.
• Policies lack adherence to a consistent style guide: The organization has policy that does not conform to corporate style and templates. Policies use complex language, excessive legalese, and are often written in the passive voice, making it difficult to read.

I would love to hear your thoughts on the chaos, disarray, and hordes of policies you see scattered across organizations and corresponding GRC policy management strategies to address this issue.

Policies define boundaries for behavior of business processes, relationships, systems, and individuals. At the highest level, policies start 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, into the business unit, department, and individual business processes. Expectations of conduct are written into policies, so individuals know what is acceptable and unacceptable.

Policy, done right, articulate corporate culture, the boundaries of individual and business behavior, and personal conduct. Consider that:

• Policies articulate the governance culture and structure: Without policies there are no written standards about acceptable and unacceptable conduct. Without good policy, culture morphs, changes, and takes unintended paths without a compass to guide its way.
• Policies articulate a culture of risk: This includes risk responsibilities, communication, appetite, tolerance levels, and risk ownership. Every organization takes risk — it is part of business. Without clearly written guidance and ownership, risk governance policy will be ineffective.
• Policies articulate a culture of compliance: Policies define what is acceptable and unacceptable. This starts with legal and regulatory requirements:  communicating how the organization will stay within legal boundaries given the various jurisdictions in which it operates. Policies establish the values, ethics, commitments, and social responsibility of the organization, when it comes to matters of discretion.

It is important to be clear: Policy does not provide corporate culture, nor does it resolve the issues of  governance, risk or compliance (GRC). An organization can have a wide array of policies that are not adhered to, and end up in very hot water. However, policies are a necessary means to clearly define, articulate, and communicate the organization’s boundaries, practices, and expectations. An organization can have a corrupt and convoluted culture with good policy in place, though it cannot have a strong and established culture without it. The right policy is necessary to define and communicate what the organization is about.

Policies are the vehicle that communicates and defines culture so culture does not morph out of control. This requires policy to be adhered to at every level, exceptions to policy be governed, and violations be dealt with consistently and responsively. Because policy can establish liability, mismanagement of policy can introduce liability to the organization as a policy establishes a duty of care for the organization. Reliance upon policy violation as a duty of care can be used by regulators, prosecuting and plaintiff attorneys, and others to place culpability on an organization. It is paramount for an organization to establish policy it is willing to enforce – but also necessary to closely manage and monitor the policies that are in place.

I would love to hear your thoughts on Why Policies Matter and corresponding GRC strategies.