Tag: Audit

16 Dec 2010

The IT Steering Committee – Should or Must?

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.

30 Nov 2010

5 Key Elements of Risk Management

As a financial institution, it sometimes seems that everything you do requires a risk assessment.  Information security, disaster recovery, ID theft, remote deposit capture, outsourcing, in fact the term “risk assessment” appears 215 times in the FFIEC IT Examination Handbooks.  But a risk assessment is only one step of a five step risk management process…and it’s not even the first step.

I think the regulators unnecessarily confuse the issue by conflating “risk assessment” with “risk management”.  Sure it’s important to assess risk, but unless you’ve correctly identified the assets to be protected, you’re assessment will be off target.  And once you’ve correctly identified the assets, and assessed the risk to those assets, you must design a system of controls to avoid, reduce and transfer the risk down to an acceptable level.  And then, because the environment in which the risks and controls exist is not static,  you’re still not done managing.  You must constantly repeat the process.

The process is further complicated by the fact that there is no one standard for documenting risk management.  Although it would be so much easier for both the institution and the regulator if there were a standard checklist or matrix.  Easier for the institution to implement, and much easier for the regulator to follow.  (In fact, in my opinion a standardized risk management process would have been a mutually beneficial outcome from Dodd-Frank…it would benefit institutions, regulators, and the public.)

So, lacking a universal standard for risk management, how do you proceed? Again, the FFIEC handbooks provide guidance here.  I mentioned earlier how often the term “risk assessment” appeared in the handbooks, but the term “risk management” appears even more often…303 times total.  The essential elements of an effective risk management program are:

  1. Identify the assets to be protected.  What are you protecting (i.e. customer information, critical business processes, etc.), and why (privacy, security, etc.)?
  2. Identify the threats to those assets.  What could happen to the assets identified in step 1?  Rank the threats by both impact and probability.  (This is the traditional risk assessment step.)
  3. Apply controls in a layered, overlapping way until the risks are reduced to an acceptable level.
  4. Test the adequacy and effectiveness of the controls.
  5. Monitor the program and periodically repeat the process.

Remember, exactly how this is documented is up to the institution.  Most choose to utilize a matrix, others use a narrative, but regardless of how it’s done the process should include all 5 of these elements.

So next time you hear an auditor or regulator ask for a risk assessment, what they are really asking for is one step in your overall risk management program.  Deliver it to them as part of the program and you’ll never come up short.

24 Nov 2010

Thankful for…Appendix A?!

When you were a kid, you hated the “pop quiz” right?  But if the teacher allowed you to use your notes and textbooks, you felt like you at least had a fighting chance.  I’ve taken both proctored and “open book” certification exams, and I’ve always felt that open-book exams more accurately reflected how most of us retrieve and use information.  Most of us can’t possibly commit everything we need to know to memory, but if we know where to go to get the information, we have a fighting chance of finding the right answer.

That’s exactly how it is with an audit or examination.  In my position I assist many many customers with audits and examinations.  I see a lot of folks treat the pre-exam experience as a “pop-quiz”, with associated high anxiety levels.  They dread the unpredictability of both the “test questions” and the correct answers.  “What are they going to ask…and how should I respond?”  But in reality, all IT examinations are actually open-book, and the books are the FFIEC IT Examination Handbooks.  And the best part is that the Handbooks contain both the questions and the answers!

In the back of every single one of the 12 Handbooks is a section titled “Appendix A – Examination Procedures”.  All of your examiners’ questionnaires and work papers are drawn from these sections.  Granted, most of the examinations use only a small sub-set of the items in Appendix A, but if you use this section as a quick checklist at least you’ll know how prepared you are.  In the past couple months, I’ve heard two different FDIC IT examiners make the same statement when asked “how do we know that we’re compliant…?”, and the answer was “easy, because we give you the answers up front!”

So there’s one more thing to be thankful for tomorrow!

I hope you have a wonderful Thanksgiving!

11 Nov 2010

Dodd-Frank and regulatory compliance

In an excellent article by Lori Moore of ATTUS Technologies, she states that there are multiple reasons why bank examiners may be ramping up scrutiny:

“Examiners who may already be on the defensive in regard to criticism about their actions prior to the fall 2008. Examiners who now have the Dodd-Frank Act on their side, giving them more authority. Examiners who in conjunction with Dodd-Frank have been charged with heightening their scrutiny of all consumer protection compliance.

No doubt, examiners are going to get tough. A decree recently stated by a representative from the OCC: “Fair but tough”. In fact many anecdotal reports confirm this is already happening.”

The difference between “tough but fair”, and “fair but tough” is much more than semantic.  It means that “tough” is the operative word.  As the pendulum of regulatory focus swings from credit risk back to regulatory risk, expect regulators (and auditors) to spend more time scrutinizing your information security policies, procedures and practices.

13 Oct 2010

DR Plans – Compliant or Recoverable?

When addressing the issue of your disaster recovery plan, the ultimate goal is both.  But if you’re faced with limited resources (time, personnel, and money), and need to decide whether you’ll conduct a test or re-write your existing plan, what should you do?  A successful test demonstrates that you can recover if you have to.  Isn’t that the point of a DR plan?  Why waste limited resources tweaking your plan when the tests validate your recovery capability?

Because if your plan doesn’t follow the FFIEC guidance, you may fail an audit or examination regardless of how many successful tests you’ve conducted.  It may seem like a case of misplaced priorities, but it does make sense.  The March 2006 IT Examination Handbook is (unlike most of the other handbooks) pretty prescriptive in it’s guidance.  It “encourages” financial institutions to adopt a 4-phase process consisting of:

  • Business Impact Analysis
  • Risk Assessment
  • Risk Management
  • Risk Monitoring & Testing

I put “encourages” in quotes, because whenever the FFIEC uses that word what they really mean is that you better have a very very good reason NOT to adopt this process.  In fact, since 12/07 the FDIC has made the Business Impact Analysis mandatory, and recent audits have faulted plans for not having a Risk Assessment.  So the first reason you should focus on bringing your plan into alignment with current regulatory guidance is to avoid audit and examination deficiencies.  You may never experience an actual emergency severe enough to activate your plan, but you are virtually guaranteed to have it audited and examined, and repeatedly so.

But the most important reason to focus on having a compliant plan is that the prescribed process actually makes sense.  Each phase specified in the Handbook flows logically to the next phase, with the end result being a comprehensive program that:

  1. Identifies and prioritizes all critical business process and their inter-dependencies (Phase 1)
  2. Identifies threats to those processes (Phase 2)
  3. Develops recovery procedures in the event the threats affect the processes (Phase 3), and
  4. Tests all assumptions to validate all previous phases (Phase 4)

Unless you’ve completed Phases 1 & 2, how do you know your test results are valid, i.e. that you are recovering the processes that are most important to you?  If you haven’t done the analysis and assessment steps, you really don’t know.

So, complaint AND recoverable is the goal, but if the question is compliant OR recoverable, you should always opt for compliant.  Because if compliant is done correctly, recoverable will be the result.

20 Sep 2010

SSAE 16 replaces SAS 70 (…sort of) – UPDATE 2

In my last post I indicated that the AICPA would have additional guidance on this topic this fall.  It appears that we may now have to wait until early 2011.  According to this document from the AICPA,

“The existing (AICPA Audit) guide is being overhauled and rewritten to reflect the requirements and guidance in SSAE No. 16. The revised guide is expected to be available for sale in early 2011”.

This presents a dilemma for service institutions whose existing SAS 70 reports have expired, or are about to expire.  I will address this in greater detail in a future post.  But the much bigger issue is for financial institutions who rely on the SAS 70 reports to validate the adequacy and effectiveness of controls at their service provider.  As I made clear in my last post, the new SSAE 16 reporting standard is not designed to address controls over subject matter other than financial reporting.  According to a recent article:

In the past, many CPAs used SAS no. 70 to report on controls at a service organization that are unrelated to user entities’ internal control over financial reporting, for example, controls over the privacy of customers’ information. However, SAS no. 70 is not applicable to examinations of controls over subject matter other than financial reporting, and neither is SSAE no. 16.

For the vast majority of vendors that provide products and services to financial institutions, the the SSAE 16 is not appropriate unless the product or service provided directly impacts financial reporting.

If you are a financial institution with outsourced IT services, you should be far more interested in the privacy, security, confidentiality, integrity and availability of your (and your customers’) data at the service provider.  The report you want is called a Service Organization Control (SOC) Report. There are 3 different reports:

  • SOC 1 – Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting
  • SOC 2 – Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality and/or Privacy
  • SOC 3 – Trust Services Report

Your service provider may present you with any one of these (or the SSAE 16), and with either a Type I or Type II.  I believe that the SOC 2, Type II will be adopted as the de-facto standard for organizations that provide IT related services to financial institutions (including managed services like cloud computing).

The guidance we are waiting on from the AICPA is a report called “Reporting on Controls at a Service Provider Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy”.  Again, it’s not expected until early next year, but financial institutions should start planning now.  Ask your service provider to tell you what report they plan to provide to you, and then determine whether or not the report provided sufficiently addresses your concerns.

Bottom line…this is no longer simply a “check-list” item in your vendor management program!

To be continued…