Author: Tom Hinkel

As author of the Compliance Guru website, Hinkel shares easy to digest information security tidbits with financial institutions across the country. With almost twenty years’ experience, Hinkel’s areas of expertise spans the entire spectrum of information technology. He is also the VP of Compliance Services at Safe Systems, a community banking tech company, where he ensures that their services incorporate the appropriate financial industry regulations and best practices.
13 Dec 2010
Hot Topics Tom Hinkel 1 Comment

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
From the Field Tom Hinkel 1 Comment

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
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.

11 Nov 2010
From the Field Tom Hinkel 0 comment

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.

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