SSAE 16 – Compliance Guru

29 Apr 2011

Hot Topics Tom Hinkel 0 comment

Vendor Management and the SAS 70 Replacement

I’ve written about the replacement for the SAS 70, which officially phases out on June 15th, previously. But because this one report is being replaced with 3 new reports, financial institutions have an additional challenge that they didn’t have before. Your vendor management program must now determine the most appropriate report to request based on your specific concerns regarding the vendor. Of course, once the correct report is identified, you must then acquire and review it…this step doesn’t change from the old SAS 70 world.

In the past, determining the correct report wasn’t really necessary, as the SAS 70 was the only reporting tool available if you needed to validate the security controls in place at a service provider. With the SAS 70 being replaced with the SOC 1, SOC 2, and SOC 3, you have 3 options to choose from (and with Type I and Type II versions for the SOC 1 and SOC 2, you really have 5 options!). So how do you choose? It might make sense at this point to back up and take a look at the overall vendor management process.

The FFIEC considers risk management of outsourced services to consist of the following components:

Risk Assessment (assessing the risk of outsourcing)
Service Provider Selection (the due diligence process)
Contract Issues (prior to signing the contract)
Ongoing Monitoring (post contract)

Most institutions believe that their vendor management program begins once the contract is signed, i.e. once the vendor become a vendor. But it’s clear that the vendor management process must begin well before that, and in fact third-party reviews like the old SAS 70, and the new SOC reports, should be obtained during the due diligence phase. This is the proposal phase (step 2 above), well before the decision to engage the vendor.

According to the FFIEC, the due diligence process should determine the following about the vendor:

Existence and corporate history;
Qualifications, backgrounds, and reputations of company principals, including criminal background checks where appropriate;
Other companies using similar services from the provider that may be contacted for reference;
Financial status, including reviews of audited financial statements;
Strategy and reputation;
Service delivery capability, status, and effectiveness;
Technology and systems architecture;
Internal controls environment, security history, and audit coverage;
Legal and regulatory compliance including any complaints, litigation, or regulatory actions;
Reliance on and success in dealing with third party service providers;
Insurance coverage; and
Ability to meet disaster recovery and business continuity requirements.

That is a lot of information to obtain from a non-vendor, but the new SOC reports, and the SOC 2 report in particular, will go a long way towards addressing many of the above concerns. Specifically; systems architecture, internal controls, any third-party providers, insurance coverage, and business continuity would all be addressed in a SOC 2 Type II* report.

I’ve developed this flowchart to assist you with the correct SOC report selection process, and I encourage you to discuss it with your auditor. Of course once the correct report for that vendor has been determined, you must then obtain and evaluate it…that is a topic for a future post.

*Note: We are still waiting for the AICPA to finalize the work program for the SOC 2 and SOC 3 reporting format. Check with your auditor for additional guidance.

16 Apr 2011

Resources Tom Hinkel 1 Comment

SOC Report Selection & Evaluation Aids

With the SAS 70 phasing out on 6/15, financial institutions have a dual challenge; determining the best report to request, and evaluating the report they are provided. To assist with this challenge, I’ve created two documents.

The first, or Step 1, is a SOC Selection Flowchart, which is available here. This will assist in determining the most relevant report to request from your service provider. Once you register your email address, I’ll automatically send the second (Step 2) document, the SOC Evaluation Flowchart. Step 2 is still under development, as the AICPA has not yet completed the audits guides for the SOC 2 or SOC 3.

You will also have the opportunity to opt in (or opt out) of receiving notice of future regulatory compliance resources, like webinars, white papers, etc. I hope you find the flowcharts and other resources useful.

Download SOC Selection Flowchart

25 Jan 2011

Hot Topics Tom Hinkel 0 comment

Top 5 Compliance Trends for 2011 – Part 3

What do Social Media, Cloud Computing, Virtualization, Data Vaulting, Mobile Banking, and Core Services have in common? For most community financial institutions, all these products or technologies involve outsourcing, either wholly or in part.

When it comes to offering the latest products and services, outsourcing allows even the smallest institution to compete with the largest. And outsourcing makes sense, because it means that you don’t have to build and maintain the infrastructure yourself. As the FFIEC stated in their 2004 guidance “In many situations, outsourcing offers the institution a cost effective alternative to inhouse capabilities.” But the FFIEC also makes it clear that you are still responsible for the security of the data wherever it may reside. So given the increased reliance of financial institutions on outside vendors, and the regulators’ expectations, my third regulatory compliance trend for 2011 is:

Vendor Management

This is based on the following criteria:

A recent interview with the head of regulatory compliance with the FFIEC made it clear that new technologies like social media require overwhelming reliance on third parties.
The FDIC changed Part 5 of their IT Examiners Questionnaire from GLBA to Vendor Management
The largest recent data breaches were with third-party vendors (i.e. Heartland), not the financial institution itself.
The Bank Service Company Act requires financial institutions to report all service provider relationships that directly support banking functions. IT vendors are one of the dependency layers that supports the business process, and as such MAY qualify as a direct support component. I addressed this here.

I had this as a trend for 2010, and I’m carrying it over for 2011 as well. I believe that there are some very compelling reasons why the regulators will (and should) increase scrutiny in this area as asset quality issues abate. In the meantime, don’t wait. Update your vendor management program now. Include an analysis in your vendor risk assessment to determine if the vendor should be considered “reportable” under the Bank Service Company Act.

And as you request their third-party reviews, bear in mind that the vendor management process will be a bit more challenging this year with the phase-out of the SAS 70 report. There is some speculation that the new SSAE 16 will become the functional replacement, but be prepared to review and interpret whatever report the vendor provides you.

UPDATE: For further guidance, refer to the Outsourcing and Supervision FFIEC IT Handbooks.

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…

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.