I’ll be posting my list of audit and examination trends for 2011 soon, but this article by me on a similar topic was just published in Bank Technology News.
04
Jan
2011
Category: Hot Topics
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.
21
Dec
2010
Red Flag enforcement to start 12/31
With the signing of legislation on 12/18 exempting certain health care practitioners and other businesses from complying with the Red Flags Rules, it would seem to clear the way for enforcement to begin at the end of this month. Financial institutions have had to comply with the guidelines since 1/1/2008, but regulatory enforcement has been delayed several times as organizations representing attorneys and physicians lobbied to exempt these professionals from complying.
A Red Flag is defined by the FTC as “…a pattern, practice, or specific activity that indicates the possible existence of identity theft.” Financial institutions are expected to already have established a formal Identity Theft Prevention Program that contains reasonable policies and procedures to:
- Identify
- Detect, and
- Respond…
…to any Red Flags that might indicate the presence of ID theft. You must also have a process in place for administering the program, which includes involving the Board and senior management, training your staff, and the appropriate oversight of service providers.
Expect examiners to ask to review your ID Theft Program in your next examination, and request that your next audit include a review as well.
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…
16
Nov
2010
SAS 70 vs. SSAE 16 from the service provider perspective
Although it’s unclear what, if anything, the FFIEC* will say about the new standard before it is officially adopted in June of next year, one thing is certain…both vendors and financial institutions will need to become familiar with the differences in the interim. And one of the most significant differences between the two reporting standards from the service provider’s perspective is the wider scope of the new standard. While the SAS 70 auditing standard only called for a description of “controls”, the SSAE 16 standard requires a description of the service provider’s “system”. A “system” is defined as the services provided, along with the supporting processes, policies, procedures, personnel and operational activities that constitute the service organization’s core activities that are relevant to user entities...including third-party providers. A SAS 70 report, on the other hand, does not, and might in fact contain language similar to “…our examination did not extend to controls of the third-party service organizations…”
The implication of this expansion from “controls” to “system” is more than conceptual. On the plus side for the financial institution, a more expansive report allows for a more accurate representation of the actual risk, resulting in a more thorough risk assessment. The primary advantage for the service provider is that they won’t be required to re-issue a report if they add additional products or services, only if there are material changes in the supporting infrastructure. This makes sense, because the adequacy and effectiveness of controls depends more on the environment in which the controls operate, and less on the specific services the environment supports or provides.
The new standard definitely places a bigger burden on the service provider, but the financial institution is still required to carefully and critically evaluate whether the new report adequately supports their oversight responsibilities.
*The term “SAS 70” is used 30 times, and in 8 of the 12 FFIEC Examination Handbooks.
02
Nov
2010
Mobile devices and information security
The key to addressing the risk of mobile devices is to think of them as functionally equivalent to a PC (with all the information security risks therein), PLUS the added risk of mobility. In fact, the FFIEC combines workstations, laptops and hand-held devices together in their Information Security Examination Procedures for the purposes of determining compliance with user equipment security guidelines.
SO if we consider that all these devices should have equivalent security considerations, the information security risk assessment should determine the institutions’ risk exposure regardless of the location of the data:
- Processing (in-house or at a third party)
- Transit and Transmission
- Handling and Storage
- Destruction / Disposal
Mobile devices have issues in each of these categories and the institution must identify them, and apply layered controls designed to reduce or eliminate them. For example, processing includes email applications as well as third party apps. Do any of these third-party apps process or have access to customer information? Is the application approval process the same as for in-house applications? What about social networking issues? These are easy to control through the internal network, but almost impossible in a mobile device. How will the device handle authentication, and is a reduced password/PIN acceptable?
Transmission presents a particular challenge for mobile devices, as data can traverse multiple platforms such as cellular and Internet in addition to the local area network. The FFIEC requires that “…policies and procedures address the protections for data that is sent outside the institution.” Encryption is the most common control here.
Handling and storage presents the biggest challenge to mobile devices, and again encryption plus remote wipe capability is key to addressing these risks.
Finally, how are mobile device taken out of service at end-of-life?
These are only a few considerations, but at the end of the process the institution must assess the residual risk and decide if it is acceptable. That shouldn’t mean accepting a higher level of residual risk just because of the difficulty of controlling it, but perhaps a slightly higher level is acceptable if the added productivity of mobile devices justifies it.