Sorry, no more post from me on this Blog

Those of you that have followed me on this blog, realize that my posts have substantive content on GRC topics. I shared my thoughts, ideas and personal experiences as a former Chief Compliance Officer and IT executive on topics and techniques with the hope that my readers could leverage them to help improve their own company practices.

As a result of AXENTIS acquisition by WolterKluwer/CCH last year, my position was eliminated as of December 2009. This last post is simply intended to inform you as my readers that I am no longer submitting posts for this Blog.

I am now a guest lecturer for the University of Dallas School of Management, graduate course on GRC – what a great thing to see being introduced to young business professionals.

I have also taken on some engagements solely spawned by people that know me within the GRC industry to help companies move forward in marketing, selling and improving their GRC programs and processes.

Ideally however, I would like to continue helping businesses grow and improve in the risk, compliance and ethics field in a full-time capacity which could either mean taking on a Compliance Officer type of role, a marketing and development role with a GRC solution vendor or a management consulting role with a respected provider of consulting services.

I want to thank you for reading and sometimes commenting on my posts and hope that your passion and insights have been fueled by my sharing of experiences.

Please feel free to reach out to me if you need my help and look for me to resurface in the not too distant future.


Thanks again and God Bless.

Brett Curran

Risk Assessments and Records Retention

At a recent Compliance and Ethics conference, I asked another attendee what they hope to gain while they were there. Keeping in mind, the audience has hundreds of experts in their own right and they are coming to both share their own experiences as well as learn from others.

I was quickly reminded as I listened to the reply that records retention programs and schedules needed constant vigilance – why you wonder?

The response to my questions brought back one of the key concerns that I encountered nearly 10 years ago when I was a new CCO. The company was beginning to establish risk management practices and were in the midst of performing enterprise wide risk assessments.

This attendee was in the early stages of developing an ERM program and while discussing the status of the effort with the General Counsel, she was informed that all the responses to the risk assessment questionnaires should be destroyed – fear of the double edge sword.

On one hand, you are doing the right thing by finding your problem areas so that they can be addressed in a timely manner. On the other hand, you are documenting issues that may be held against you.

In my mind, it is a matter of ethics and doing the right thing. If the tone of the company is one of the highest ethical standards, the decision is not quite so difficult. Search for risks, prioritize them, address them – you should be rewarded for your efforts.

A similar situation arises when drafting company policies. The working versions may have all sorts of statements that are changed or omitted from a final version. However, companies often worry that if they get in trouble, these working versions will be discovered and they could get in trouble as someone obviously knew about this yet, the company decision was to do something else that could have prevented a problem.

These are both valid concerns that must be researched and decisions made.

In both of these scenarios, consider the risk of having the information versus not having the information.

1) No company can go error free
2) People (even judges and prosecutors) recognize real effort
3) You must be able to demonstrate reasonable due diligence
4) Doing the right thing will pay long-term dividends
5) Regulations wouldn’t require risk assessments if companies didn’t have risk that needed to be identified and addressed.

The other thing I remembered was to make sure that these record types were included in your records retention schedules. Superseded policies, prior version risk assessments, supporting documentation, etc. should all be accounted for in your records retention program.

So ask yourself, how can you show evidence of good risk and compliance practices if you throw away all your report cards that don’t have gold stars? You should be proud of your efforts if you are truly doing the right things and only hope that you get the chance to let it protect you when something goes wrong.

I'd be interested to hear how your company is managing these types of records so, please send me your comments.

GRC: Whose Job Is It Anyway?

There is so much insight and expertise being discussed and written about these days regarding GRC, its advantages and tactical approaches that anyone even remotely close to risk or compliance management understands the concepts and value.

Most everyone also understands the pressures put on the CEO and other company executives when regulators don’t see that company business practices are what they should be.

So, whose job is it to build and execute an effective and efficient GRC program anyway?

The answer is usually, it depends. And, it depends on a number of data points such as;

1) Who has the attitude and personality to drive change
2) Who has the organization, planning and communications skills
3) Who normally gets assigned and is successful in leading significant change

From this short list of possibilities, it might be the CFO, CCO or CIO as they each have likely championed a successful enterprise change. While we all recognize that the essence of a GRC approach involves everyone in the organization having clear roles and responsibilities in sustaining GRC, it is an entirely different task in designing and redesigning enterprise change.

For this, I would give the edge to the CIO as they are honed day-in and day-out to manage change and enhance sustainable processes. However, the CFO is well versed in managing cost and risk and has probably sponsored some large projects to replace a financial system or two. The CCO on the other hand, is somewhat like the CIO in that changes come in daily and they must communicate and manage frequent changes across the organization as a process.

Because GRC is a business matter and it requires various levels of participation from everyone in the organization, deciding which individual or committee will lead the execution and oversight efforts depends on who will be responsible for reporting on the effectiveness of the overall program to the board or its sub-committee.

Finance is the primary function of the CFO and providing technology services is the primary function of the CIO therefore, the primary function of the CCO is overseeing and executing risk driven compliance. However and as I already mentioned, the CCO needs the CIO and CFO by their side every step of the way as well as other members of the organization.

Often times, the CCO will enlist the services of a seasoned project or program manager from IT because those skills are essential in driving the execution activities designed under the direction of the CCO with support and input from other members of the team.

IT has a particularly significant and challenging role in the business as GRC involves IT as a business department and also as a provider of technology which is needed to support the overall program. Because the program can succeed or fail merely given the appropriate application of technology – the system needed by the CCO and other stakeholders to manage the GRC processes is critical just as the system is that the CFO uses to manage finances.

The term IT GRC has crept into our midst over the last year or two but to me, that eludes to the special needs of IT stakeholders within the larger enterprise GRC spectrum rather than the need for an entirely different solution.

You probably noticed that I omitted the Chief General Counsel from the list of possible candidates and for good reason. While company lawyers have a significant role in supporting the risk and compliance efforts of the company, you want them to provide legal advice independent of the building of the programs processes. Additionally, their training and mindset isn’t generally conducive or aligned with the particular skills sets needed to plan, develop and manage sustainable and often complex processes across the enterprise.

Whatever the title of the person appointed by the board to oversee the day-to-day execution of GRC activities, they all need to work together to evolve from the current way of doing things to a more effective and cost efficient way.

There is always room for improvement and you need a process to build and support the GRC process but having someone in charge to coordinate and report on the progress and effectiveness of the overall GRC program is the job of the CEO and the board. It’s largely about defining, managing and executing based upon clearly defined roles and responsibilities.

So do this part right, and the rest will evolve to the appropriate levels of maturity over time – taking a risk-driven approach to take care of first-things-first and keeping it that way.

Ann Oglanian, President and CEO of ReGroup LLC has put together a terrific slide deck defining the Compliance Officer that should help you in finding the right person for the this role and can be found at: Compliance Officer Toolkit

Do you have a GRC CZAR and if so, what is their title?

Best Practices: What do they mean to you?

Besides ERM and GRC, one of the other buzz words referred to is “Best Practices”. Benchmark is another interesting term but I’ll save that discussion for another time.

Being in the Enterprise GRC application vendor business for a couple years and as a former IT guy that made the transition to a Chief Compliance Officer, I’ve heard this term for more years than I care to share.

In IT, using the term best practices usually meant adapting to some well known industry standards and in the IT space, it was things like ISO 17799 (security program standards), ITIL (IT service delivery standards), COBIT (IT GRC) or something similar. When you begin learning about these types of standards or in this case, best practices, you quickly realize that it is about the processes, procedures and the carrying out of a certain company defined rendition of standards. The adoption and adaptation of the standards can be equated with best practices to provide the confidence and assurance that the company is operating accordingly.

As a result, the IT world often equates industry and discipline focused standards with best practices.

Now let’s talk about how compliance professionals might interpret the term.

While compliance professionals largely consider a similar view as their IT counterparts, there are some very subtle or perhaps not so subtle differences.

Take for example this list of typical compliance activities:

* Identifying and evaluating legal and regulatory changes
* Collaborating on the development and modification of policies and procedures
* Developing and revising training plans
* Scheduling and delivery of training
* Delivering and managing surveys and responses
* Performing assessments – distributing, collecting, evaluating
* Monitoring and reporting on issues and the effectiveness of the compliance programs

Certainly there are standards or best practices that would apply related to effective training programs or how long to keep obsolete policies or procedures and the like but, best practices around these activities should focus first on the processes. I say this because if you can’t sustain the processes, you certainly couldn’t follow standards.

As an example, the process for evaluating the impact of regulatory changes might involve communicating and engaging different stakeholders but a best practice would involve maintaining the right list of stakeholders, a consistent mechanism for tracking the laws and regulations and soliciting input from various business areas, organizing and collecting responses and action plans, the ability to identify and follow-up on activities that are getting done, the ability to track the associations between the regulations, policy changes, actions taken and responsible parties as well as a number of other process activities that would be considered “best practices” in compliance management.

My point is that “best practices” may mean different things to different constituents across your organization. If you are striving to adopt and adapt best practices, you should clarify your teams understanding so you will know them when you see them and give them the right measure of priority and focus. Don’t get side tracked searching for content and standards and that you aren’t prepared to support with best practices.

For GRC, I would give the first order of importance to the strategic approach relative to organization and oversight secondly, the processes to manage the activities and last but not least, industry standards.

I would be interested to hear how other companies are going about the adoption of best practices and what you consider “best practices”.

What Do Regulators Really Want?

No surprise that legal and compliance professionals need to get out and interact with their peers in the industry occasionally, it’s like AA for compliance junkies. Like half-time for players of a sporting event, they need to head off to the locker room and evaluate what just happened, adjust their plan of attack or defense in some cases – and head back to the game with renewed vigor and enthusiasm.

It was no different when I attended a recent HCCA conference in Scottsdale, AZ a week ago. Compliance Officers escaped the confines and calamities of their normal routines to share lessons learned and stir new ideas that could improve and enhance their GRC programs.

There were numerous topics discussed however, one ingredient that that was quite obvious was the attention being given to the Federal Sentencing Guidelines, 7 elements of an Effective Compliance and Ethics Program. Whether the speaker was from industry or a regulatory body, the 7 elements were part of the presentation.

I presented a pre-conference workshop on Training and the Use of Technology and what did I use to help establish the requirements – you guessed it.

I found it particularly validating when subsequent conference sessions all mentioned the same elements regardless of the topic. If you are not familiar with them – THEY ARE IMPORTANT!

The other key takeaway for me was related to the regulators remarks during their sessions and where the rubber meets the road for companies. So, what do regulators and examiners really want to find during an audit or exam?

1) Evidence of a 7 element compliance and ethics program
2) Programs that produce desired outcomes based on their design and execution
3) Legal and regulatory requirements being met

If you periodically evaluate your program and find that you can demonstrate satisfying these expectations, you rock!

If you can’t but have built a plan that is making good progress according to sound risk evaluations, you are definitely on the right track.

If you are not in either of these categories, maybe you need to call half-time, regroup, re-plan and get back in the game.

By the way, whether more regulations begin taking the principle-based approach where outcomes are increasingly the focus or not, the three items I listed above, are.

Extended Enterprise Risk and Compliance: Managing the Approach

I wrote a blog post last summer on the topic of Extended Enterprise Risk Management and it is still a top-of-mind initiative for most companies. The highly regarded GRC visionary Michael Rasmussen, CEO at Corporate Integrity recently posted the Ultimate 3rd Party/Supply-Chain Risk & Compliance Management Platform article to his blog and makes some great points that I wanted to expand upon.

Axentis has worked with a number of customers on developing a practical approach using its single GRC application to manage risk and compliance across thousands of third-parties relative to the exposures present within those relationships.

Can the ultimate risk and compliance management platform be an enabler for improved efficiency and effectiveness? absolutely. Can lessons be learned and applied from others who have created an effective and efficient process? absolutely.

Some of the key elements of successful approaches I would add to the list to managing these 3rd Party risk and compliance challenges are;

* A process of applying risk ratings to vendors, suppliers, etc based on various criteria, like dollars paid, criticality to production, regulations supplier is subject to, etc.

* Associating various risk oriented processes, policies and procedures to them based on risk ratings

* Integrating compliance and risk management assessment functions with the contracting processes

* Integrating third-party user provisioning with compliance training

I produced a white paper last year: Managing Risk in the Extended Enterprise that more clearly articulates the elements needed to effectively manage extended enterprise risk that is still relevant today.

If you’d like to explore this solution further, take a look at the white paper I have prepared and if you like, contact me directly to discuss in more detail.

I’d be interested to hear about similar approaches that you have taken or other effective ways you have constructed to manage and oversee your extended enterprise risk.

Will the Real GRC Please Stand Up?

Just 8 Years ago, no one had heard of the term “GRC” yet today, there are more experts with analyst firms, consulting companies, and software vendors than I could have ever dreamed of. When I began planning and organizing my “Integrated/Federated GRC Environment” in 2001, the only vendor that came even close was Axentis. Remember, I had been in IT for almost 25 years to that point and knew something about technology. GRC had no commonly understood acronym and there weren’t any vendors, consultants or analysts providing guidance let alone technology solutions to help manage the administrative aspects of the myriad of people, processes and information.

So how have all these providers of GRC services and solutions become experts so fast? In many cases they have just expanded marketing of their already in place point solutions referring to themselves now as a GRC solution rather than be burdened with the stigma of a purely point-solution and presumably miss the GRC revolution. Without a clearly defined benchmark to be measured against and being a new term, they have created their own visions and definitions of what GRC means and henceforth, how it should be solved – adding to the confusion.

The reason for this is obvious however, solving the problem is a much more difficult task.

I think it’s about time those of us in the business of GRC, start to confront the confusion we have all created around what G, R and C mean. I won’t name names but I can tell you as I get around and talk to various experts on GRC they may agree on concepts but in practice the solutions are from completely different books not just different pages.

In addition to the GRC practice guidance that OCEG is helping to create, they and their members are working on the whole concept of a GRC technology ecosystem. This will eventually help categorize solutions in a more accurate position within the ecosystem of “GRC solutions”. With guidance from OCEG and the community of contributors from industry Chief Compliance and Risk Officers, Chief Ethics Officers, General Counsels, leading consulting firms and GRC application vendors - we will have real useful information and benchmarks to define the real GRC.

Analyst firms don’t all see GRC the same way either. Their understanding by in large is led by the types of inquiries they receive from their customer base. If their customers are primarily IT focused, the technology requirements for GRC reflect the needs of IT. If they are auditors, they tend to reflect the technology needs of auditors and so forth with other roles across the GRC spectrum. What this promotes is an unbalanced view of what GRC is, what solutions are needed and how solutions compare. It stands to reason that, the guidance and research done by analyst as to the key elements of GRC often target the view from a specific discipline rather than the broad spectrum of stakeholder needs – Enterprise GRC. Not always the case, but how does a buyer or solution vendor really know without the experience of working with a variety of stakeholders or having industry benchmarks from which to measure?

If the company approach to risk and compliance management is unbalanced towards risk or compliance, they are likely overspending and/or underachieving. The application solutions to support these processes need some degree of balance or at least, need to work well within the over-arching technology ecosystem and should make clear where they stand.

I think we have to get real, especially with what “R” means and what “C” means. I am not focusing on G because in some ways R(C) = G (I know this is not exactly true), but lets focus on R and C for now.

“ C” stands for compliance which for many means obeying laws and regulations. That is true but not the whole story. It also means following internal directives, departmental policies and procedures and other requirements based upon management decisions. In other words, compliance is adhering to whatever the process rules are and getting people to follow these rules on a daily basis.

Everyone should recognize that C is a subset of R which is a subset of G. That’s why it’s called GRC, not RCG or CGR or RCG. But one can’t have G without R and it follows one can’t have R without C and that’s my point.

One cannot properly manage risk without managing compliance. If one is simply creating a control framework and assessing or auditing whether procedures and processes are being followed, I guess this is someone’s definition of managing compliance, but in order to assess if something is being done according to the rules you have to tell people what the rules are in the first place. And in order to tell them you have to write it down (we can call that a policy). So in order to really manage risk, sooner or later there are people involved and those people have to be told what they are supposed to do and if they aren’t doing it then someone needs to do something about it and THEY need to know they are supposed to do that. So first comes a requirement and control, then comes a bunch of compliance policy definitions and communications, then comes audit, then comes compliance exception remediation, which auditors don’t do, they are the internal cops, but the process owner in the authority hierarchy needs to be monitoring on their own and also do the remediating, might be a functional person or someone in the legal department, who knows.

My point is, running C isn’t easy, and you can’t run R without it. Now I will bet you are really confused.

I’d like to hear your perspectives on the state of GRC confusion from the solutions and approach perspectives.