IT Steering – Page 2 – Compliance Guru

A recent survey of auditors and examiners asked:

During the past year, in which category would you say MOST of your IT audit/exam findings occurred?

The choices were:

Lacking or Insufficient Polices
Inadequate Procedures, or
Insufficient documentation of actual practices

2/3 of the respondents said that insufficient documentation of practices was the most common finding. In other words, policies and procedures were fine, but the institution could not adequately demonstrate that they were actually following them. This brings me to the second compliance trend for 2011 (and a carry-over from last year):

Documentation

The regulatory compliance process involves the coordination of 3 intersecting spheres:

Policies
Procedures, and
Practices

All 3 must be not only be in alignment with one another, but also in alignment with the current interpretation of regulatory guidance. (Made especially challenging since the latter is a moving target.) Policy defines what you will do to address regulatory mandates, procedures dictate how you’ll implement policy, but practices document what you actually do. If polices are off target, but you can still demonstrate good practices, you’ll have a minor audit/exam finding. But if you say you’re doing something and you either didn’t, or can’t prove you did, that is generally a more severe finding.

So what recent audit and examination experience last year has demonstrated, and what I believe we’ll continue to see in 2011, is increased scrutiny in the sphere of documented practices. Simply put…if you didn’t document it, you didn’t do it.

There are many ways to document your actual practices, but perhaps the best way is to take your procedures and convert them into a checklist. The checklist is then discussed in committee (Tech or IT) as a regular agenda item. For example, if your written procedures state that you will implement a patch management process to keep all devices fully patched, be able to produce a report showing device patch status, and present it to a committee assigned responsibility for validating the effectiveness of your procedures.

Remember, if you can’t document it, then for regulatory purposes, you aren’t doing it.

At a recent user group meeting of one of the major core vendors for community banks, I asked the question ‘how many of you use an IT or Tech Steering Committee?’. I was expecting a vast majority of hands to go up, but only about half did. This was surprising to me, given that:

The FFIEC all but mandates this committee,
The FDIC strongly encourages it,
Auditors recommend it, and
It provides a mechanism to address many of the most difficult examination questions

First, the FFIEC mandate. On page 5 of the Management Handbook, it states:

Many boards of directors choose to delegate the responsibility for monitoring IT activities to a senior management committee or IT steering committee…The committee should consist of representatives from senior management, the IT department, and major end-user departments.

Some institutions may call it a Tech Steering Committee, or have another name for it, but in “FFIEC-speak”, if “many” choose to do this, you better have a pretty good reason if you decide not to do it. In fact in Objectives 3, 4 and 5 of the Examination Procedures, the examiner is instructed to review;

…the membership list of board, IT steering, or relevant management
committees established to review IT related matters.
…the minutes of the board of directors and relevant committee meetings
…IT oversight program, to determine if the Board…established a steering committee, and
…the effectiveness of the reports used by senior management or
relevant management committees.

The FDIC strongly encourages the use of an IT management committee in their IT Officers Questionnaire. Part 1 (b) asks for “the names and titles of individuals, committees, departments or others participating in the risk assessment process”. And as I addressed in my series of the trickiest questions on the questionnaire, this committee, and the documentation it produces, can help you document adherence with many aspects of your IT risk management process.

Finally, most of the recent findings in IT audits are due to institutions’ inability to document that they are following their own policies. The policies themselves are sufficient, and the institution may indeed be complying with them, but because of non-existent or inadequate documentation they can’t prove that they are. And in today’s compliance environment, if you can’t prove you’re doing it, you aren’t doing it.

Given it’s overall importance, consider the IT Steering Committee a “must”. If you don’t have one, make a New Years resolution to establish one. Give it a mission to assist the board in overseeing IT-related activities. Make sure it consists of members from all departments, and work from a standardized meeting agenda. Lastly, document each and every meeting, and periodically report to the Board. Better audits and examinations in 2011 will be the fruits of your labor.

Tag: IT Steering

Top 5 Compliance Trends for 2011 – Part 2

The IT Steering Committee – Should or Must?