Tag: Examination

09 Aug 2011

Examination Experience Survey – preliminary results

Although the survey is still open, I wanted to discuss one particular trend that I find interesting.  (If you’ve already participated, thank you!  Please pass the link on to a colleague at another institution.  If you haven’t had a chance to fill it out, please do so.  The survey will remain open until 8/19).

One of the questions is “During your last examination, did you challenge any of the findings with the examiner?”  So far, 41% of you have challenged findings…

 

…and of those that did, almost 70% were successful getting the finding removed or modified in the final exit report…

I was surprised by a couple of things.  First, that so many of you actually challenged the examiners.  I think this is a direct result of proper examination preparation.  Fully 85% of you felt that your examination experience was either “pretty much as expected”, or “a few curve balls, but not bad overall”   This makes perfect sense…proper preparation leads to fewer findings, which leads to confidence that you’re doing the right things, and that makes it easier to stand up for what you are doing even though it may differ slightly from examiner expectations.  The key is in understanding the root cause of the examiner finding.

So I was also surprised that the number of successful challenges wasn’t even higher.  Even if your procedures differ from expectations, if you can demonstrate that you are still effectively addressing the root cause, you will usually have success getting the finding removed or modified in the final report.  This next statistic may be telling in that regard…even though 73% of you used an outside consultant to assist with exam questionnaire preparation, only 41% used a consultant to assist with post-exam responses.

Again, the survey will remain open until 8/19, and I’ll be posting additional findings shortly thereafter.  Stay tuned!

 

21 Jul 2011

BCP plans continue to draw criticism

In a recent FDIC IT Examination, the examiner made the following criticism of the institutions’ DR/BCP:

“Business continuity planing should focus on all critical business functions that need to be recovered to resume operations. Continuity planing for technology alone should no longer be the primary focus of a BCP, but rather viewed as one critical aspect of the enterprise-wide process. The review of each critical business function should include the technology that supports it.” (bold is mine)

This is not the first time we’ve seen this finding, nor is it a new direction for regulators, but rather follows directly from the 2008 FFIEC Handbook on Business Continuity Planning when they state:

“The business continuity planning process involves the recovery, resumption, and maintenance of the entire business, not just the technology component. While the restoration of IT systems and electronic data is important, recovery of these systems and data will not always be enough to restore business operations.”

I still see way too many DR plans that focus on the recovery of technology, instead of recovery of the critical process supported by the technology.  Sure, technology is an interdependency of nearly every function you provide, but it must not be the primary focus of your recovery effort.  Focus instead on recovery of the entire process (teller, CSR, lending, funds management, etc.), by recognizing that each process is nothing more than the sum of its interdependencies.   For example, what does it take to deliver typical teller functionality?

  • A physical facility for customers to visit
  • A trained teller
  • A functional application, consisting of:
    • A workstation
    • A printer
    • A database, requiring:
      • LAN connectivity
      • WAN (core) connectivity, requiring:
        • Core functionality
      • A server, requiring:
        • Access rights
      • etc.
    • etc.
  • etc.

As you can see, technology certainly plays a very important role, but it is not the only critical aspect of the process.  All sub-components must work, and work together, for the overall  process to work.  Mapping out the processes through a work-flow analysis is an excellent way to get your arms around all of the interdependencies.

So next time you perform the annual review of your BCP (and you do review your plan annually, right?), make sure your IT department isn’t the only one in the room!

27 Jun 2011

Audits vs. Examinations

As I speak with those in financial institutions responsible for responding to audit and examination requests, I find that there is considerable confusion over the differences between the two.  And some of this confusion is understandable…there is certainly some overlap between them, but there are also considerable differences in the nature and scope of each one.  It may sometimes seem as if you are asked to comply with 2 completely different standards.  How often has the auditor had findings that you’ve never been asked during an examination?  And how often has an examiner thrown you a curve ball seemingly out of left field?

In a perfect world shouldn’t the audit be nothing more than preparation for the examination?  The scope of the audit should be no more and no less than what you need to get past the examination.  Any more and you feel as though you’ve wasted resources (time and money), any less and you haven’t gotten your money’s worth, right?  Well…actually no.  While the two have the same broad goal of assessing alignment with a set of standards, the audit will often use a broader set of industry standards and best practices.  This is because the FFIEC guidance is so general and non-prescriptive.  For example, take one of the questions in the FDIC Information Technology Officer’s Pre-Examination Questionnaire.

“Do you have a written information security program designed to manage and control risk (Y/N)?”

Of course the correct answer is “Y”, but since the FDIC doesn’t provide an information security program template, how do you know that your program will be acceptable to the regulators?  You know because your IT auditor has examined your InfoSec program, and compared what you have done to existing IT best practices and standards, such as COBIT, ITIL, ISO 27001, SAS 94, NIST, and perhaps others.  While this doesn’t guarantee that your institution won’t have examination findings, it will reduce the probability, as well as the severity, of them.  This point is critical to understanding the differences between and audit and an examination; an audit will identify and allow you to correct the root cause of potential examination findings prior to the examination. So using the example above, even if the examiner has findings related to your information security program, they will be related to how you addressed the root cause, not if you addressed it.  (I’m defining root cause as anything found in the Examination Procedures.)  In fact, the FFIEC recognizes the dynamic between the IT audit and examination process this way:

An effective IT audit function may also reduce the time examiners spend reviewing areas of the institution during examinations.

And reduced time (usually) equals fewer curve balls, and a less stressful examination experience!

17 May 2011

The IT Strategic Plan – Why, Who, & How

One of the most common examination findings recently (particularly with the FDIC) has been the lack of an IT Strategic Plan.  I’m not sure why the focus lately (perhaps the shift from the CAMELS “A” to the “M”?), but the concept is certainly not new.  The regulatory mandate for it is found in the 2004 FFIEC Management Handbook:

“The Board of Directors and management should* implement an IT planning process that:

  1. Aligns IT with the corporate wide strategic plan;
  2. Aligns IT strategically and operationally with business units;
  3. Maintains an IT infrastructure to support current and planned business operations;
  4. Integrates IT spending into the budgeting process and weighs direct and indirect benefits against the total cost of ownership of the technology; and
  5. Ensures the identification and assessment of risk before changes or new investment in technology.”

The first requirement of an effective IT planning process is alignment with the overall strategic plan, yet whenever I ask a group of financial professionals how many have seen their own strategic plan, very few hands go up.  I get more hands in a group of senior management than in a group of network administrators, which seems to make sense except for one thing; the administrators are the ones actually maintaining the IT infrastructure (#3 above).  So the very folks tasked with making sure the infrastructure is aligned with the overall strategic plan, probably haven’t even seen it!

This is the real disconnect from my perspective.  Although you can develop an IT Strategic Plan from a template fairly quickly using standardized verbiage, integrating it into the overall plan, and then executing it, is much trickier.  It should be a live document, linking the overall Strategic Plan with IT projects and issues through the IT Steering Committee.  In fact, the FFIEC even suggests that the IT Steering Committee is the ideal forum for this, stating that the committee:

“…may also oversee the development and maintenance of the IT strategic plan.”

And furthermore,

“The information technology steering committee’s cross-functional membership makes it well suited for balancing or aligning the organization’s IT investment with its strategic and operational objectives.

So the Management Handbook strongly suggests that IT steering is the best forum, and that everyone from the Board of Directors, to IT line management, to business unit management should participate.  But this brings us back to dilemma I mentioned above; that IT line management (and most business unit management, for that matter) are rarely familiar enough with the overall strategic plan to effectively affect alignment.  This brings us to the “how”:

  • Step 1 – Senior management must communicate the mission,
  • Step 2 – Ensure that the IT Committee is tasked with implementing that mission by making sure all IT initiatives support and enhance the missions’ goals and objectives.
  • Step 3 – Most importantly, make sure the committee has the tools and expertise necessary to effectively monitor, gather, analyze and report the data that will document the entire process.  Because in the end…

“…institutions that are better at keeping IT aligned with changing business goals and objectives are positioned to compete more effectively.”


*In FFIEC-speak, “should” really translates to “must”.

11 May 2011

Using Technology to Drive Compliance

In the past year to year and a half, nearly all of the IT examination findings I’ve seen have in the broad category of “documentation”, or more specifically, lack thereof.  In other words, policies and procedures were satisfactory, but documentation was either non-existent, or insufficient, to demonstrate that actual practices followed policy and procedure.

To visualize this, consider that the compliance process consists of three overlapping areas of endeavor:

 

Written polices begin the process, which must always have regulatory guidance as their target.  Policies should track guidance precisely; if guidance states that you should or must do something, your policies should state that you do, or you will.

If policies are “what” you do, written procedures are the “how”.  And just as policies align with guidance, procedures should flow logically from, and align with, your policies. For example, your information security policy states (among other things) that you will protect the privacy and security of customer information.  Your procedures contain the detailed steps (or controls) that you will take to prevent, detect and correct unauthorized access to, or use of, customer information.  Controls like securing the perimeter of your network, updating server and workstation patches, installing and updating Anti-virus, etc.

So you have the “what” and the “how”, but as I mentioned previously, the vast majority of audit and examination findings in the past couple of years were due to deficiencies in the third area; actual (documented) practices.  And this is where technology can be of tremendous assistance.

[pullquote]Auditors and examiners much prefer automated systems over manual.  Automated systems don’t forget, or get too busy, or take vacations or sick days.   They aren’t subject to human error or inconsistencies. [/pullquote]

Auditors and examiners much prefer automated systems over manual.  Automated systems don’t forget, or get too busy, or take vacations or sick days.   They aren’t subject to human error or inconsistencies.  In fact, some processes like firewall logging, normalization, and analysis are virtually impossible to implement manually because of the sheer volume of data generated by these devices.*  And while other areas like patch management and Anti-virus updates are possible to implement manually, auditors much prefer automated processes because they ensure polices are applied in a consistent and timely manner.

But perhaps the biggest boost to your compliance efforts from technology is in the area of reporting, and specifically, automated reporting.  In today’s compliance environment, if you can’t prove you’re following your procedures, the expectation from the examiners is that you aren’t.  This is the one area that has evolved more than any other in the past couple years.  And automated reporting provides that documentation without human intervention, easing the burden on the network administrator.  Auditors (internal and external) and examiners also like automated reporting because they have a higher confidence in the integrity of the data.  And the IT Steering Committee likes it because it is much easier to review and approve reports prepared and presented in a standardized format.

So in summary, technology enables automation, and automation enhances compliance.  And along the way everyone from the Board of Directors, to management committees, to the network administrator, benefits from it.

 

*  The FDIC IT Officer’s Pre-Examination Questionnaire validates the difficulty of manual processes to manage logs when it asks:

“Do you have a formal intrusion detection program, other than basic logging (emphasis mine), for monitoring host and/or network activity”

20 Apr 2011

A Recurring Theme in FDIC Consent Orders

If you look at any of the recent FDIC Consent Orders, you will quickly see a common theme.  I randomly pulled a few off the top of the list, and the verbiage was very similar, and in many cases identical:

  • …the Board shall enhance its participation in the affairs of the Bank
  • …the Bank’s board of directors shall increase its participation in the affairs of the Bank
  • …the Board shall participate fully in the oversight of the Bank’s compliance management system
  • …the Board shall participate fully in the oversight of the Bank’s Compliance Management System
  • …the Board shall increase its participation in the affairs of the Bank
  • …the Bank shall have and retain qualified management
  • …Bank’s board of directors shall increase its participation in the affairs of the Bank
  • …the Bank shall have and retain qualified management.
  • …the Board shall increase its participation in the affairs of the Bank
  • …the Bank’s board of directors (“Board”) shall increase its participation in the affairs of the Bank

In almost every case, regardless of the main thrust of the Consent Order, this was usually the first requirement.  In other words, although the Order may have been imposed because of financial weakness, or lending policy non-conformance, or some other reason, the examiners want to establish up front that the Board and Senior Management are at fault for failing to prevent, detect, and/or correct the problem ahead of time.  Furthermore, regardless of their past participation, in every case they are expected to increase their oversight in the future.

Of course, not only must this occur, but it must also be documented.  If recent examination experience has taught us anything, it is that if you don’t have it documented, it didn’t happen.  The challenge is this; typically the Board defines the broad goals and objectives of the institution in the strategic plan, and delegates the day-to-day responsibility of implementing those goals to committees.  In a perfect world, the mandates flow down from the Board to the committees, and status reporting flows back up from the committees to the Board.  (Graphic illustration) In reality, there are multiple points of failure in this top-down, bottom-up model:

  1. Does the Board have a well-defined, 3-5 year Strategic  Plan?
  2. Has this plan been communicated to all stakeholders?
  3. Have committees been formed, staffed, and tasked with implementing the details of the plan?
  4. Are there well-defined objectives and benchmarks in place to measure alignment between strategic goals and actual performance?
  5. Does the Board have access to adequate, timely information (reporting), and the necessary expertise, to determine if their strategic goals and objectives are being achieved?

A “No” answer at any point in this process causes the whole process to break down.  And even a “Yes, but we didn’t document it…”, is not enough to satisfy the examiners.  So how best to document each step?  Taken in order from above:

  1. Make sure the institution has a valid, up-to-date, Strategic Plan, and…
  2. …the plan has been communicated to all stakeholders.  This isn’t as onerous as it sounds…the plan shouldn’t change that often.
  3. The mission statement for all committees should reinforce their alignment and coordination with the Strategic Plan, and any risk assessments conducted by the committees must measure strategic risk.
  4. Evaluate each new product, service and vendor against its ability to further the objectives of the Strategic Plan, and…
  5. …make sure this information is summarized and presented to the Board at a frequency commensurate with the pace of change within the institution.

As I’ve mentioned before, the Tech Steering Committee is the ideal committee to report all things IT to the Board.  If you utilize a standard agenda, which includes discussion of on-going or proposed IT initiatives (and their alignment with Strategy), document the meetings, and report progress to the Board periodically, you will satisfy the IT oversight requirement.  Once the top-down and bottom-up process is in place for IT, simply duplicate it across the enterprise!