Say What You Do…But Do What You Say

Say What You Do…But Do What You Say

Feedback from recent regulatory examinations indicates a potentially troublesome trend; regulators are actually reading your policies.  Traditionally, regulatory findings are concentrated in policy weaknesses.  Either polices don’t exist (social media and mobile banking for example), or they do exist but need “expansion”.  (“Expansion” is a vague and often used-term in examination findings to indicate a shortcoming of some sort.  Either the policy isn’t broad enough or detailed enough or doesn’t conform to current guidance.)

These problems are relatively easy to fix; draft the policy or expand it or enhance it, run it by the Board, and move on.  But every time you add a policy, or expand an existing one, you obligate yourself.  You say you’ll do something a certain way, or with a particular group, or with a specific frequency.   And this is where many recent exam findings have occurred.  Examiners are reading through your policies, and identifying deviations between your policies and procedures and your actual documented practices.

This is nothing new, I originally wrote about it back in 2011.  What is new however is the depth and breadth of the scrutiny.  What used to be primarily limited to Board reporting and testing and auditing, now seems to include almost any instance of “will” or “shall”.  Here is an example of the scope of this challenge.  The following is a short excerpt from the beginning of a typical information security program.*  I’ve highlighted all the areas that obligate the institution in some way or another:

This overall Information Security Program is critical to the safety and soundness of Sample National Bank. Therefore, the Board of Directors shall approve this written Information Security Program. The Board of Directors designates the Information Security Officer to develop, implement, and maintain the Program. Senior management in each functional area of Sample National Bank will be responsible for day-to-day monitoring of compliance with this Program. Any perceived breaches of security or potential risks to non-public information will be reported immediately to the Information Security Officer.

The Information Security Committee will coordinate an independent audit/examination for section 501b GLBA compliance on an annual basis. The independent audit/review will focus especially on areas that were identified as high or moderate risk during the risk assessment process that was coordinated by the Information Security Officer and the Information Security Committee.

Regular testing of key controls, systems, and procedures shall take place as necessary depending on the complexity of the process/system involved. Due to the critical need for independence between those who are responsible for operating a process/system and those who conduct or review the testing, the internal auditor/compliance officer or his/her designee shall be responsible for the review of all testing methodology and results.

So in this short three paragraph, 1/2 page excerpt I count no fewer than nine instances where the institution has obligated themselves to do something:

  1. The Board will approve the program,
  2. The Board will designate the ISO to manage the program,
  3. Senior management in each department will do the day-to-day compliance monitoring,
  4. Breaches of NPI will be reported to the ISO,
  5. There will be an annual GLBA audit,
  6. The audit will be risk-based,
  7. Regular testing will occur,
  8. Testing will be risk-based, and
  9. Internal audit will review all testing.

The policy goes on for another 15 pages, and a quick search for every instance of “will” or “shall” turns up 40 potential opportunities for actual practices to deviate from policies…and all this is in just one policy.

What can you do to avoid this policy vs. practice mismatch?  Use the opportunity of your next policy update to take an inventory of everything you are promising to do, and how you’re supposed to be doing it.  Start with a quick search of all occurrences of “will” or “shall”.  If you’re not doing it, or can’t prove you’re doing it, take it out of your policy.  You may get written up for a policy deficiency, but that’s easy to fix and better than having a finding that “…management states that they are doing <xx>, but examiners could find no documentation that it was being done.”  A “failure to follow policies” is an oversight weakness finding that speaks poorly of management, and often invites further scrutiny into other policy vs. practice deviations.

Of course there is a difference between not doing something, and not being able to prove you’re doing something, but it’s a difference without a distinction as far as the regulators are concerned.  If you can’t prove it, you’re not doing it.  So say what you’ll do, but make sure you can back that up with the meeting minutes, reports, checklists, test results, and other documentation to demonstrate that you’re doing what you say.

[poll id=”8″]

*Thanks to Jackie Marshall at Gladiator Technologies for the use of their InfoSec policy template verbiage.

Print Friendly, PDF & Email
Tom Hinkel
As author of the Compliance Guru website, Hinkel shares easy to digest information security tidbits with financial institutions across the country. With almost twenty years’ experience, Hinkel’s areas of expertise spans the entire spectrum of information technology. He is also the VP of Compliance Services at Safe Systems, a community banking tech company, where he ensures that their services incorporate the appropriate financial industry regulations and best practices.

Write a Comment