Tag: FFIEC

12 Jan 2011

Trust and Risk Online

In a recently released paper by the Brookings Institute, they address the issue of trust in an increasingly on-line business environment.  They focus on the difficulty of establishing, maintaining and verifying identity on-line, and how the trust relationship between on-line services and consumers is being threatened by weaknesses in this identity layer component.

Although the paper is not specifically geared for the banking industry, it does contain several items of interest to bankers.  Discussion of on-line identity attacks is relevant to the emerging interest in social media.  Social engineering is also a topic of interest to banks, and has been for some time.  There is also a mention of the Red Flags model, and how compliance with the regulation (which started 12/31/2010) requires a strong identity authentication component.  They do note that the existing FFIEC authentication guidance is a good model, but they recognize that the Red Flags, and other financial institution guidance, falls short because:

“…three of the top five targets for phishing attacks in 2010 (eBay, Facebook, and Google) are not financial services web sites (Gudkova, 2010), and are thus are not necessarily covered by extant rules. Many other online services, including webmail sites, web hosting sites and social network sites are frequent targets. Clearly they are attractive targets for malicious actors seeking identity information, even if those identities are not actually the paying customers of those firms. Access to credentials of these sites can expose highly sensitive information and serve as the jumping off point to serious and highly customized fraud attempts.”

In the end, financial institution risk managers must carefully consider the risks of this “identity layer” in the current environment, and weigh them against the potential benefits of social media.  The paper is definitely worth a read…highly recommended.

28 Dec 2010

Looking back – 2010 compliance hits & misses

Every year about this time, I’m asked to look ahead to the upcoming year and prognosticate on regulatory compliance trends.  I  intend to do just that in a future post, but today I wanted to do something very few other prognosticators do…look back at last years’ predictions and see which ones hit and which missed (and why).

Here was the list of 2010 trends as I saw them early last year:

  • Risk Assessments –New standards and expectations
  • Documentation–Who, What, How and Why
  • Disaster Recovery –Compliant and Recoverable
  • Vendor Management –Trust but Verify

Overall I scored 2 hits and 2 misses, although to be fair the misses are more along the line of “not yet hits”.  Here is how 2010 actually shaped up:

  • Risk Assessments – miss.  This prediction was taken from the Winter 2009 FDIC Supervisory Insights Newsletter article entitled “Customer Information Risk Assessments: Moving Toward Enterprise-wide Assessments of Business Risk”.  It described how examiners should start to evaluate risk on an enterprise-wide basis instead of simply focusing on information security risks.  I predicted that examiners would start to adjust their examination procedures for the new criteria in 2010, but it hasn’t manifested itself in examination work papers yet.  However, some of the enterprise-wide risk criteria has made its way into various risk assessment best practices.  Criteria such as strategic risk, operational/transactional risk, reputation risk and legal/regulatory risk are now part of the vernacular for disaster recovery, retail payment systems and new technology risk assessments.  We’ll call this a miss…for now.
  • Documentation – hit.  The vast majority of audit and examination findings I’ve seen this year we’re not related to missing or insufficient policies or procedures, they were due to the institutions inability to document (prove) that they were following their own procedures.  Expect this trend to continue in 2011.
  • Disaster Recovery – hit.  Both auditors and examiners are finding fault with DR plans that do not strictly conform to the FFIEC guidance.  Specifically, they must contain a business impact analysis, risk assessment, risk management and testing sections, and in that order.  A non-compliant plan that may even be able to demonstrate (through testing) recoverability will still be written up.  (More here.)
  • Vendor Management – miss.  With the increasing reliance of financial institutions on third-party vendors, I predicted that 2010 would be the year that the examiners started scrutinizing vendor management programs more closely.  It hasn’t happened…yet.  It may be because of the continued overwhelming emphasis on asset quality during the safety and soundness examination, but I’m leaving this on the list for 2011.  Asset quality will undoubtedly still dominate in 2011, but there are indications that the pendulum is starting to swing back around.  (More on that later.)

My next post will be my predictions for 2011.  I’m also collecting survey responses from auditors and examiners on where they think the areas of focus will be, and I’ll report that in early 2011 as well.

All the best for a Happy and Compliant New Year!!

23 Dec 2010

New FDIC Survey Results and Third-Party Providers

The new FDIC Supervisory Insights Winter 2010 newsletter addresses several issues of interest to bankers, including Trust Preferred Securities, Managing Agricultural Credit, and Senior Life Settlements.  But there was also a section that analyzed the results of a survey that was conducted by FDIC examiners over the past year.   The more than 2,100 responses are producing some interesting results, especially when correlated with other financial reports like call reports, but of particular interest to me were the findings examining how financial institutions are “responding to the recent period of economic and competitive challenges”. One of the trends identified in the survey results was how financial institutions are increasingly “…making use of third-party providers to offer new and innovative products”, and particularly, “how effectively bank safety-and-soundness and compliance risk management systems are keeping pace with these changes.”

Community financial institutions are no strangers to vendor management, particularly the importance of addressing privacy and security issues, but the article makes reference to the risk of Unfair or Deceptive Acts and Practices (UDAP).  This is not a traditional risk category in and of itself, and may not be a consideration in your current vendor management program, but based on recent enforcement cases, maybe it should be.  The article makes reference to FDIC guidance here, and the FFIEC provides additional guidance here and here, but none of the existing guidance specifically mentions the significant financial liabilities and increased reputation risk that can result from a lawsuit based on UDAP.

The conclusion states:

Overall, Survey results show that banks are responding to ongoing economic and competitive challenges in a variety of ways, for example, by tightening underwriting standards and making use of third-party service providers to offer new and innovative products. These operational changes can affect an individual institution’s risk profile and its ability to effectively manage the resulting consumer compliance risks. The analysis of data gathered through this Survey will continue to help the FDIC understand how effectively bank safety-and-soundness and compliance risk management systems are keeping pace with these changes.

I suggest you incorporate UDAP risk into your existing vendor management risk assessment by assuring that it is identified as one of the potential contributors to reputation risk (along with privacy and security breaches), and that the  legal risks are assessed along with standard regulatory/compliance risks.

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.

13 Dec 2010

SAS 70 replacement…3 alternatives

I’ve written about this  here, here and here, and we are still waiting on additional guidance from the AICPA, now expected March/April 2011.   But of greater interest to financial institutions is the opinion of the FFIEC, which refers to the SAS 70 in the IT Examination Handbooks 30 times, and has yet to officially endorse a replacement.

Although the SSAE 16 is designated as the replacement report by the AICPA, you’ll need to become familiar with a couple of terms before determining if it will be suitable in your circumstances;  ICFR and non-ICFR.  ICFR stands for Internal Controls over Financial Reporting, and non-ICFR (logically) stands for controls other than those used for financial reporting.

Why is it important to understand this?  Because the SSAE 16 standard specifically states that it be used only for ICFR, NOT non-ICFR.  That means for the vast majority of financial institution’s vendor relationships such as core vendors and IT vendors, the SSAE 16 may not be the most relevant report to request or to receive.

You’ll also need to understand SOC reports.  SOC stands for Service Organization Controls, and there are 3 options; SOC 1, SOC 2 and SOC 3 (and a Type I and Type II for the first 2).  Here is the best way to understand them:

  • SOC 1 – equivalent to the current SAS 70 for ICFR engagements
  • SOC 2 – attests to controls relevant to data privacy, security, confidentiality, integrity and availability
  • SOC 3 – equivalent to the current SysTrust and WebTrust reporting standards

Again, the SOC 1 and SOC 2 reports can be prepared as either a Type I (a point in time) or Type II (a period of time, typically 6 months).

Will the SOC 1 or the SOC 2 become the de-facto replacement for the SAS 70?  In my opinion, the SOC 2 directly addresses all the concerns a financial institution would have regarding their (and their customers’) information.  But will the SOC 1 morph into something its’ not supposed to be, as the SAS 70 did?  Only time will tell, so stay tuned…

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.