Tag: FFIEC

24 Nov 2010
From the Field Tom Hinkel 1 Comment

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!

16 Nov 2010
Hot Topics Tom Hinkel 0 comment

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
Hot Topics Tom Hinkel 0 comment

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.

13 Oct 2010
From the Field Tom Hinkel 1 Comment

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.

08 Oct 2010
Hot Topics Tom Hinkel 1 Comment

The FFIEC Handbooks and the SAS 70

I’ve written about the 6/15/2011 phase-out of the SAS 70 report in favor of the SSAE 16 series (SOC 1, SOC 2, SOC3) here and here.  The AICPA isn’t expected to update their audit guide until sometime early next year, but financial institutions are anxious to get the FFIEC to comment, as the SAS 70 is mentioned no fewer than 31 times, and in a total of 8 of the 12 IT Examination Handbooks.  It’s mentioned 10 times in the Information Security Handbook alone!

I predict that the FFIEC will remove all references to the SAS 70, or to any specific report for that matter, and replace them with generic references to “audit reviews” or “audit reports”.  It will then fall to the financial institution to determine the most appropriate report for each service provider, based on their risk assessment.  However, the service provider will deliver whatever report they decided to prepare, which may or may not match the report requested.

© 2025 UFS Tech. All rights reserved. Compliance Guru is a registered trademark of UFS Tech. Privacy Policy