How to Make Sure the Periodic Review Gets DONE

/

There’s merit in the old cliché, “If it ain’t broke, don’t fix it.”  Frankly, it makes sense to leave the pieces of your program that are running effectively alone.  After all, there’s always something that needs attention, so why bother reviewing things that are doing just fine?

Why?  Because of regulators.  In the DOJ’s Evaluation of Corporate Compliance Programs guidance, variations of the word “periodic” appear 12 times in 20 pages.  In the UK Ministry of Justice’s Guidance on the UK Bribery Act, variations of “periodic” and “review” appear 37 times. Prosecutors expect a periodic review of how your program is operating.  Specifically mentioned is a periodic review of:

  • The criteria used in risk assessment

  • The risk assessment process

  • How lessons learned have altered the program

  • How investigations/reports have altered the program

  • How effectively the investigations process is working

Human Nature Gets in the Way

If we know that regulators expect a periodic review of how various pillars of our program are operating, why don’t we do it?  Human nature directs our attention to things that aren’t working, rather than spending time memorializing things we decided are fine. 

But human nature is a poor defense when sitting across from a prosecutor trying to explain that you did think about whether your risk assessment criteria was good enough, but since it was fine, you didn’t memorialize that conversation with yourself.

Program Review or Periodic Review?

It’s important to note that the review we’re discussing is specific to various program elements as opposed to the program as a whole.  Holistic program review (whether internally performed or done by an outside consulting group like Spark Compliance) is very important.  In this blog, we’re discussing how to systematize and document an annual review process that will check the adequate procedure boxes and ensure that you’ve got your ducks in a row if the government comes calling.

The 5-Step How-To

Here’s how to get this done. 

STEP 1: Choose a date

Choose a date to perform your review, then create a calendar reminder annually for the next ten years.  Pick a day of the week as opposed to a specific date.  The third Thursday in June will always be a good choice, while June 23 may fall on a weekend some years. 

STEP 2: Give the Review a Name

People name important processes.  Give your review a name.  One client calls it “the annual check-up.”  Another calls it “the Spring refresh.”  You can go with a fun or serious title, but either way, name the process.

STEP 3: Define the Review

Make this easy on yourself.  Define exactly what you’re looking at so it can be regularly checked.  You can include:

  • The criteria being used for your risk assessment

  • The frequency of your risk assessment

  • The criteria for your holistic program reviews

  • The frequency of your holistic program reviews

  • Whether your approach to third-party risk management is adequate or needs updating

  • Whether the current policies and procedures are adequate in responding to risk

  • Whether the whistleblower process is working well

  • Whether the investigations process is working well

  • Whether your resources (human, technological, financial) are adequate

STEP 4: Perform the Review

You can make the review process as lengthy as you like, but it’ll be easier if you simply have a conversation with yourself and memorialize that you considered each area.  Some may want to bring in their whole team to discuss, and that may be a useful exercise.  But the more people you involve, the easier it will be to put off the review.

The review can be done on a simple spreadsheet like this:

Periodic Review Graphic.PNG

STEP 5: Keep it all in One Place

Keep one spreadsheet that you update each year.  It’ll make it easy to find if you ever need it.

Is it reasonable for regulators to expect you to document your analysis of the minutia of your program?  Probably not. But proving that you had a thought without contemporaneous documentation is usually impossible. 

Capturing your considerations will likely make your program stronger in the long run.  And that is a win/win.