SOC 3 – Compliance Guru

09 Apr 2012

Hot Topics Tom Hinkel 1 Comment

FFIEC Handbook Update – SAS 70 Transition

The FFIEC has just updated their online IT Examination InfoBase to address the AICPA phase-out of the SAS 70 reporting format. All references to “SAS 70” have now been replaced, and the SAS 70 sections of the Audit and Information Security Handbooks have been completely removed. Previously there were a total of 31 references to “SAS 70” in 8 different Handbooks.

I wrote about this a number of times, and speculated about when the FFIEC would update their Handbooks, and what would replace the term. For the most part “SAS 70” has been replaced with “SSAE 16”, but there are also references to the SOC 2 and SOC 3 reports, as well as a more generic “other third-party review processes”. I’m happy to see the FFIEC is allowing for more flexibility in the choice of vendor control reports they consider acceptable. I’ve also made the case that although this does make the vendor management process a bit more challenging, institutions should welcome the transition.

14 Jun 2011

Hot Topics Tom Hinkel 4 Comments

SOC 2 vs. SAS 70 – 5 reasons to embrace the change

The SOC 2 and SOC 3 audit guides have recently been released by the AICPA, and the SAS 70 phase-out becomes effective tomorrow. The more I learn about these new reports the more I like them. First of all, as a service provider to financial institutions we will have to prepare for this engagement (just as we did for the SAS 70), so it’s certainly important to know what changes to expect from that perspective. But as a trusted adviser to financial institutions struggling to manage the risks of outsourced services (and the associated vendors), the information provided in the new SOC 2 and SOC 3 reports are a welcome change. In fact, if your vendor provides services such as cloud computing, managed security services, or IT outsourcing, the new SOC reports provide exactly the assurances you need to address your concerns. Here is what I see as the 5 most significant differences between the SAS 70 and the SOC 2 reports, and why you should embrace the change:

Management Assertion – Management must now provide a written description of their organizations’ system (software, people, procedures and data) and controls. The auditor then expresses an opinion on whether or not managements’ assertion is accurate. Why should this matter to you? For the same reason the regulators want your Board and senior management to approve everything from lending policy to DR test results…accountability.

Relevance – The SAS 70 report was always intended to be a your-auditor-to-their-auditor communication, it was never intended to be used by you (the end-user) to address your institutions’ concerns about vendor privacy and security. The SOC reports are intended as a service provider to end-user communication, with the auditor providing verification (or attestation) as to accuracy.

Scope – Although the SAS 70 report addressed some of these, the SOC 2 report directly addresses all of the following 5 concerns:

Security. The service provider’s systems is protected against unauthorized access.
Availability. The service provider’s system is available for operation as contractually committed or agreed.
Processing Integrity. The provider’s system is accurate, complete, and trustworthy.
Confidentiality. Information designated as confidential is protected as contractually committed or agreed.
Privacy. Personal information (if collected by the provider) is used, retained, disclosed, and destroyed in accordance with the providers’ privacy policy.

If these sound familiar, they should. The FFIEC Information Security Booklet lists the following security objectives that all financial institutions should strive to accomplish:

The Privacy and Security elements of GLBA
Availability
Integrity of data or systems
Confidentiality of data or systems
Accountability
Assurance

As you can see, there is considerable overlap between the FFIEC requirements and the scope of a typical SOC 2 engagement.

Testing – Like the SAS 70, the SOC 1 and SOC 2 are available in both a Type 1 and Type II format. A Type I speaks only to the adequacy of vendor controls, but the Type II gives management assurance that the vendor’s controls are not just adequate, but also effective. The auditor can do this in a Type II engagement because they are expected to not just inquire about control effectiveness, but actually observe the control operating effectively via testing. And because the scope of the SOC 2 is significantly greater than the SAS 70 (see above), the test results are much more meaningful to you. In fact, the SOC 2 audit guide itself suggests that because your concerns (particularly as a financial institution) are in both control design and effectiveness, a Type I report is unlikely to provide you with sufficient information to assess the vendor’s risk management controls. For this reason you should insist on a Type II report from all of your critical service providers.

Vendor Subcontractors – This refers to the subcontractor(s) of your service provider, and again this is another FFIEC requirement that is directly addressed in the new SOC reports. The FFIEC in their Outsourcing Technology Services Booklet states that an institution can select from two techniques to manage a multiple service provider relationship:

Use the lead provider to manage all of their subordinate relationships, or
Use separate contracts and operational agreements for each subcontractor.

The booklet suggests that employing the first technique is the least cumbersome for the institution, but that either way;

“Management should also ensure the service provider’s control environment meets or exceeds the institution’s expectations, including the control environment of organizations that the primary service provider utilizes.”

The audit guidelines of the SOC 2 engagement require the service auditor to obtain an understanding of the significant vendors whose services affect the service provider’s system, and assess whether they should be included in the final report, or “carved-out”. Given the regulatory requirement for managing service providers you should insist on an “inclusive” report.

In summary, there will be an adaptation curve as you adjust to the new reports, but in the end I think this is an overwhelming step in the right direction for the accuracy and effectiveness of your vendor management program.

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

22 Feb 2011

Hot Topics Tom Hinkel 1 Comment

AICPA finalizes SAS 70 replacement

I wrote about this here as well, but it’s now official: The AICPA has clarified the SAS 70 replacement reports. They are actually officially being referred to as “Service Organization Control Reports (formerly SAS 70 reports)”.

The new SOC reports provide a framework for auditors to examine controls and to help senior management understand the related risks of outsourcing to a service provider.

According to the AICPA:

“Companies had misused SAS 70 to issue reports on controls related to outsourced non-financial data rather than the correct attest standard which was in place. The SOC reports clarify which standard needs to be used and how it should be implemented to meet specific user needs.

SOC 1 reports are primarily an auditor-to-auditor communication which addresses the controls at a service organization relevant to financial reporting. These reports are restricted use reports and therefore are not designed for promotional purposes. – (This is the functional replacement for the SAS 70 only where financial controls are concerned.)
SOC 2 reports are in response to the rapid growth in cloud computing and data outsourcing, as well as the marketplace need for clarification on how reports on non-financial controls regarding information, such as data security, confidentiality and privacy should be structured. – (This will likely be the SAS 70 replacement for the vast majority of service organizations)
SOC 3 reports cover the same subject matter as SOC 2, but in a general use, short form format which may be freely distributed.”

Get used to seeing this logo instead of the myriad of SAS 70 logos:

SOC Reports

Most importantly, know what it is…and what it isn’t. Understand why your vendor chose one report over another, and determine if the report is relevant to you, and adequately addresses your concerns. The term “SAS 70” is mentioned 31 times in 8 of the 12 IT Examination Handbooks, so it is a critical element in how the FFIEC expects you to manage your vendor relationships. No word yet on how the FFIEC will address this going forward…

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…