In Praise of the Paper Program 

You gotta feel sorry for paper. It’s so often maligned in the compliance world, as are checkboxes (or tick boxes if you’re on the other side of the pond) that arguing against them has become a cliché. The constant railing against the “paper program” and “check the box exercise” means that it sometimes feels that we should avoid paper programs and box-checking exercises altogether in favor of vaulted, integrity-based, values-driven programs so ethereal they don’t even need to be written down.  

That may sound good, but back in reality, a great program still needs to be papered – or documented – and boxes still need to be checked. Why is that? 

“In Praise Of The Paper Program” displayed over a checklist on a clipboard with a pencil and office workspace.

Four Reasons You Need Paper and Boxes 

There are several reasons why a paper program is critical. First, to prove you have a great program or any program at all, an auditor or prosecutor is going to want physical (or digital) proof that it exists. That risk assessment you’ve done in your head because you know the company so well? Under pressure, your thoughts are not going to hold up as nicely as pulling out your spreadsheet showing you’ve considered that the marketing department has the greatest GDPR-related risk.  

Second, good programs use a risk-based approach, meaning the company can’t do everything possible to mitigate risk. If you’ve chosen to focus your resources on your high-risk third parties as opposed to taking a one-size-fits-all approach, that’s great. If something goes awry, showing how you determined which third-parties are high-risk at your company versus those that are lower risk will put you on a great footing to defend your choices.  

Third, something could happen to you or the person whose job it is to run the program. Let’s say your boss created the program and runs it day-to-day. If your boss wins the lottery, quits, or gets hit by a bus, there will be no way to easily prove why the program was set up the way it was. It will also be difficult, or impossible, to have immediate continuity in how the program is run.  

Lastly, studies show that plans committed to paper are significantly more likely to be accomplished. Creating a plan with milestones and timelines with deliverables that can be touched creates a tangible way to move the program in the right direction. 

What Needs to be Papered 

One of the challenges of the “paper program” is that drafting documentation can expand into a full-time job. There is a balance required between putting down enough on paper and avoiding the real work of compliance by hiding behind the keyboard. What should be prioritized?  

Risk Assessment 

Your risk assessment should be written down. It can be a simple spreadsheet with the regulatory issues ranked on a 1 – 5 scale. Many people avoid drafting risk assessments because they feel like they need to be ultra-complicated. They don’t. Get something down on paper and then create your major program elements around mitigating the higher-number risk areas. 

Stack of paper documents balanced against a wooden checkmark symbol, representing organized paperwork, review, and approval.

Third-Party Due Diligence Criteria 

Many of the companies we work with at Spark Compliance have effective third-party programs. The problem with some of them is that they are led by a brilliant compliance officer that intuitively knows how high risk a third-party is because of their long-term experience.  

That person is usually right – they do intuitively know how high-risk a third-party is based on things like exposure to government officials and the country in which the third-party works on behalf of the company. The problem is that “I know it when I see it” isn’t good for consistency. If that person were to need an extended medical leave, the program would be left in the lurch. Documenting the criteria used to classify third-parties is important.  

Training and Communications Plan 

Believe it or not, many compliance programs operate without a written training and communications plan. Comms are written on the fly and training is assigned on the schedule in the compliance officer’s head.  

The problem is that the best training and communications plans need to be integrated into the greater training efforts at the company. Information security and HR training are probably going to be assigned at some point during the year, so coordination with those teams is critical, and they can’t work from plans that aren’t written down. Leaders will also be hard-pressed to nail down if they haven’t committed to recording a video or sending out an email on the compliance department’s behalf early in the year. Write your training and comms plan and get buy-in for it before attempting execution.  

Agendas for Leadership Presentations 

Draft agendas for leadership meetings and presentations. In many programs, the compliance officer meets regularly with leadership but does not have any documentation proving such meetings happened. There are also frequently no records of the topics of conversation, making it difficult to prove whether management acted responsibly in its oversight duties. Drafting simple bullet point agendas can solve this problem. As a bonus, meetings with agendas tend to go more smoothly and cover ground more effectively.  

Investigations Process 

Compliance officers under stress tend to fight fires as they come. Smaller departments may be correct that everyone runs investigations similarly but having a written process for performing investigations consistently will save time when new people come on. Additionally, a written process ensures that the most important pieces of an investigation are completed (e.g., a written investigation plan, consideration of whether outside counsel should be involved, systemic root cause analysis). 

The criticism of the paper program and check-the-box approach is that it’s form over substance, meaning it doesn’t require true commitment and a good culture to make it work. While none of us should strive to have only a paper program, that doesn’t mean we should lose sight of the power of and need for documentation. Documenting your program should be a box you choose to check off.