Boards of Directors: How to Set the Tone at the Top for Security and Compliance
So, it might surprise you that what's tap dead center on my professional radar this week isn't much different than what was there three months ago. Despite the front page headline worthy stories all awhirl around me, our practice is still caught up in all things compliance. Despite the increased pressures being brought to bear upon our clients, they still have to meet regulatory requirements. I've had a few posts around this very concept recently, but it's something that never ceases to amaze me: Examiners aren't easing up, they're bearing down. And so this week I was caught up in some noteworthy situations that I wanted to share with you.
GLBA has always started with the responsibilities of the Board of Directors, as related to providing true oversight for the institution. I've used the phrase "tone at the top" many times in my career, but within the banking industry it's truly the rule. However, what we typically encounter falls short of expectations. In all but the rarest of instances, the level of involvement is little more than a tacit signature on the institution's policy documentation, and perhaps an annual presentation of GLBA-related activities. However, so many of the required activities occur at frequencies and intervals that require much more scrutiny to ensure that all essential activities are functioning as expected so the annual parade of documentation isn't getting the job done.
I've used the phrase "tone at the top" many times in my career, but within the banking industry it's truly the rule. However, what we typically encounter falls short of expectations.
Last week, though, I stumbled across the rare exception where the Board of Directors was really locked in and focused on the details of the engagement. We met with the audit committee, which is comprised of Board members, and I was surprised by how much time and effort they had put into reviewing the related reports and trying to understand the issues. They asked pointed questions that really had teeth, and grilled us for nearly two hours to test both our team's resolve and the integrity of the report. While it was exhausting to a certain extent, my first thought after the meeting ended was "that was fantastic!" To have that many senior people commit the time and effort and to perform their jobs to that degree, proved to me the process really can work. My general sense is that there are very likely fewer risks at this institution as a result of the oversight provided by their Board of Directors. That's what is intended by GLBA and what we should find everywhere we do work. Sadly, we rarely do.
I was also reminded this past week how so many institutions struggle with first understanding and then implementing properly-defined policy and procedure documentation. I participated in a conversation with a client during which we were trying to explain to them why, although they have a document that's labeled "Incident Response Policy," if it fails to describe what's required at a high level, it's not a policy. And if it's labeled "Incident Response Procedure" and describes what comprises an incident, but doesn't provide clear direction as to what to do when an incident occurs, it's not a procedure. What we were looking at last week was actually a narrative describing how the process was managed. It was very technical with a description of how things work and had a sprinkling of policy language, but it fell way short of what would be considered either a policy or procedure document. The general rule I've used (and mentioned before) is that:
- The policy document is written so that the Board of Directors can understand what they're asking from management.
- A procedure is written so that the people who need to use it have clear, concise directions to follow and are either provided with or pointed to supporting artifacts (e.g. forms, software, etc.)
Using Incident Response as the example, you would expect to see a policy clause that states "All employees should have access to and understand how to utilize an Incident Response Program in the event of either a suspected of confirmed information security incident." The related section in the procedure would have statements such as "In the event you have identified a suspected attempt to infect your computer with a virus, immediately unplug the network cable, or if not possible, turn off the computer." The procedure would then provide instructions on who to contact and include the required information (e.g. call the Information Security Officer at (123)555-1212). I recently had one client actually say to me that while what they had wasn't up to standards, it was better than nothing. I vehemently disagree. If you have a document that is incomplete, ineffective or flat out wrong and you went through the trouble to have the Board of Directors review and approve it and then distributed it to your organization, you've just wasted a lot of time and effort. Plus -- and this is a biggie for a practitioner like me - management operates under the false assumption that they have the proper controls in place when they don't. Some of our clients get it, some don't, and we'll just keep whipping out the soapbox trying to get the word out.
I realize for many of our readers it's difficult to focus on day-to-day operations and regulatory requirements when you're worried about keeping the doors open. But if you're going to succeed (and the majority of you likely will), you need to keep up with everything -- and I mean everything. It's just so much easier when you understand what's required of everyone and make sure that they're doing their part. You may be thinking "Who has time to worry about 'when is a policy a policy and not a procedure?'" But these are times where all of us need to work both smarter and harder. So while the headline news may be of greater interest right now, getting your regulatory ducks in a row is likely to help keep your institution from qualifying as the "Story of the Year."