The GRC Pundit

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.

Over the past few months we have explored together the various components of my GRC Reference Architecture. This embodies the technology end of my broader GRC EcoSystem – which to date has over 1300 technology providers, professional service firms, and content providers of GRC cataloged into the GRC market.

The components of the GRC Reference Architecture that we have looked at to date include:

1. GRC Enterprise Data Architecture and Framework,
2. GRC Enterprise Architecture Application Core, and
3. GRC Business Process/Role Specific Applications.

Today we conclude the GRC Reference Architecture series with a quick overview of the industry, geographic, and technology views of applications aimed to help manage risk and compliance and broader GRC.

There are a variety of contexts for GRC initiatives within organizations. Some are focused on putting out specific fires, dealing with particular issues, meeting a requirement, or managing a solitary risk area. Others are focused broadly on driving agility, consistency, efficiency, transparency, and accountability across a range of GRC processes. This generates the demand for both enterprise GRC applications as well as business process/role specific GRC applications. This get’s further dissected into applications that aim to help organizations achieve compliance or manage risk in other areas such as:

• Industry specific issues. There are a range of solutions on the market that help specific industry verticals with the GRC related issues they face. In my analysis of the market and catalog of vendors you have dozens of technologies aimed at managing GxP compliance in life sciences, many focused on the complexity of managing credit/market/operational risk in financial services, there are a few focused on things such as Medicare/Medicaid RAC audits, even to the point of one vendor that manages compliance for car dealerships to state car sales laws. The point is that not every risk or compliance application is focused to solve every GRC issue for every industry. There are a variety of very specific GRC solutions aimed to help solve industry specific GRC issues. Even broad cross-industry GRC technology providers may have all the bells and whistles to help with industry specific issues – but they need to know what they are up against and how to solve client issues.

• Geographic specific issues. Another way to approach the GRC market is to understand the geographic reach of a vendor. There are vendors that have a very broad GRC solution that spans industries – but they only have language support or operations in specific localities. Further, there are GRC vendors that market and sell a solution for a specific geography to deal with laws and regulations, or to manage risk, within that jurisdiction.

Putting it together . . . with the GRC Reference Architecture you are able to map a vendor to what it provides for functionality – enterprise and/or business role specific as well as industry and geographic specific solutions. These work in harmony together to define what a vendor is about. One technology solution might offer enterprise GRC capabilities in risk, policy, and audit management but really is successful at selling into the IT role. Another vendor might have a very focused solution for dealing with Medicare/Medicaid RAC audits in health care within the United states.

The final way of looking at the GRC technology landscape through the reference architecture is to understand a solution’s technical capabilities. This involves understanding the technology building blocks that makes the solution work. Specific technology capabilities include the solution’s features for:

• Content management
• Process management
• Workflow management
• Survey & assessment management
• Collaboration management
• Project & resource management
• Business intelligence
• Dash boarding & reporting
• Business rule engine
• Enterprise application support
• Enterprise integration capabilities
• Learning & training management
• Security architecture
• Identity, role, and access management
• Storage & retention architecture
• Enterprise asset management
• XML & data feed integration
• Configuration & change management
• System log management
• Records management & Retention

This concludes our high-level look at the GRC Reference Architecture. I would encourage you to review the several related newsletters and blog posts and provide feedback as I put this into a written document to be published in the next month. You may comment on my blog or send me an e-mail.

The next step, besides publishing under the Corporate Integrity name, is to integrate this into the OCEG GRC Technology Blueprint which is in revision to be finalized with these changes in the next few weeks. This is meant to be a resource in framing the variety of GRC solutions on the market today and be a guide to vendors looking for solutions to their governance, risk, and compliance problems.

Beginning next week I turn the newsletter to a new topic of looking at the disarray of policies within organizations and ways to improve policy life cycle management and management.

Happy New Year! I trust that 2010 will bring you success and direction in your personal and professional life.

First I need to state a deep thank you to all of my subscribers that have reached out to me over the past several weeks with your sympathy and prayers for my family as my father passed away. I am amazed and overwhelmed with emotion at the number of personal comforts and encouragements you have given when most of us only connect on a professional level. My father’s struggle with cancer came on suddenly at the end of May and already in June the Doctor’s only gave him two weeks to live. Two weeks turned into six months – from which we are grateful. I spent more quality time with my dad (traveling to Seattle) than I ever have – cherished memories. My clients have been great – I had to reschedule the San Jose GRC Bootcamp (I was in San Jose for it when I learned of his passing) and everyone attendee was encouraging and open to rescheduling. I have some of the greatest clients in the world!

My purpose of this newsletter is to communicate my upcoming research agenda and direction in 2010.

The GRC market in 2010 is already proving to be interesting – particularly with the EMC/RSA acquisition of Archer. I am already seeing a lot of interaction from large Fortune 1000 companies down into small to medium sized organizations to define a GRC strategy and resolve cumbersome risk and compliance processes. There will be a lot of consolidation of the market in 2010.

The greatest shift is that I am doing more training and education worskhops/bootcamps. Since first creating the GRC market (eight years back) I have been continually frustrated in the lack of good GRC training and understanding on what it is. I continue to partner with OCEG to provide the best risk, compliance, and broad GRC training available. This is being offered in three day bootcamps, as well as very topic specific workshops (e.g., policy management, risk management).

I am kicking off the New Year with my Online Workshop: 2010 GRC Drivers, Trends, & Market Directions. In this workshop I am communicating the shape, size, and direction of the GRC market as well as best practices, approaches, and trends in a two-hour online format.

As for my upcoming research agenda:

• GRC Reference Architecture. Representing the Technology end of my GRC EcoSystem, the GRC Reference Architecture will be wrapped up in blog/newsletter format this week with another newsletter coming into your inbox on the business/role specific GRC applications. I will tie all of this together in a Corporate Integrity research piece on the GRC Reference Architecture by the end of January and will incorporate this into the revised OCEG GRC IT Blueprint as well for review and approval by the OCEG Technology Council.

• Investigations Management. I have been working for the past three months on research covering investigations management platforms – the market, players, feature/functionality, and best practices in investigations management. I originally planned to publish this by the end of December but my family circumstances put this into January. This will be published in the next month as well.

• Policy Management. After I wrap up the GRC Reference Architecture newsletter this week I will begin a newsletter series on effective management and communication of policies across the organization. This ties into the full-day workshop training I am doing on this subject at the end of February. I am also working on a book on policy management in 2010.

• 3rd Party/Supply-Chain/Vendor Risk Management. In a few months I am going to take up the topic of managin risk and compliance across extended business relationships. This area has been keeping me very busy for the past two years and want to do more writing on this topic.

• Risk Management and ISO 31000. With the release of ISO 31000 I plan on doing more writing, expository, and training on risk management to align with this important standard in 2010.

• Economic Value Proposition of GRC. 2010 will also bring more focus of my research on the economic justification and reasoning for GRC processes and solutions. I am frustrated with the amount of money companies waste on manual, paper-based efforts for GRC or ones that are encumbered by email instead of workflow and spreadsheets for assessments that have no integrity, audit trail, or scalability. GRC processes and solutions make sense because they improve business agility, consistency, efficiency, transparency, and accountability.

My upcoming 2010 events (those that are planned out to date for the next few months) are as follows:

ONLINE WORKSHOP: 2010 GRC Drivers, Trends, & Market Directions

Thursday, January 14, 2010 from 11:00 AM – 1:00 PM (CT)

 

OCEG BOOTCAMP San Jose: GRC Fundamentals, Strategy, & Technology

Wednesday, January 27, 2010 at 8:00 AM – Friday, January 29, 2010 at 5:00 PM (ET) San Jose, CA | Hotel Valencia Santana Row

 

OCEG BOOTCAMP Atlanta: GRC Fundamentals, Strategy, & Technology

Wednesday, February 17, 2010 at 8:00 AM – Friday, February 19, 2010 at 5:00 PM (ET) Atlanta, GA | TWELVE Atlantic Station

 

WORKSHOP: Effective Policy Management & Communication

Wednesday, February 24, 2010 from 8:00 AM – 5:00 AM (CT) Delafield, WI | The Delafield Ho
tel

WORKSHOP: Developing a Risk Assessment & Management Process

Wednesday, March 31, 2010 from 8:00 AM – 5:00 AM (CT) Delafield, WI | The Delafield Hotel

 

OCEG BOOTCAMP Chicago: GRC Fundamentals, Strategy, & Technology

Wednesday, April 21, 2010 at 8:00 AM – Friday, April 23, 2010 at 5:00 AM (CT) Chicago, IL | The Ambassador East Hotel

Additionally, my social networking has continued to increase. This newsletter goes out to over 6,000 subscribers. My Corporate Integrity LinkedIN Group now has nearly 1900 members. And I have over 650 followers on Twitter. And my blog continues to get significant traction and reference.

That concludes my 2010 update – now back to serious GRC strategic planning and work