Tag: SOC 2

07 Dec 2011
Hot Topics Tom Hinkel 0 comment

2012 Compliance Trends, Part 2 – Vendor Management

In my first post in this series I discussed training (employee and customer) as a good candidate for increased regulatory scrutiny in 2012.  Although these posts are in no particular order, I had initially intended to list “Management” as the next trend.  However a comment made to me by a banker at a recent conference leads me to believe that vendor management has already started to emerge as an area of increased regulator focus, so I am making this trend #2.

Vendor Management

I’ve already posted numerous times on the importance of vendor management…most recently when risk assessing on-line backup vendors, and how the phase-out of the SAS 70 will affect vendor management (here and here), and I even selected it as a potential trend for 2011.  And all the existing reasons still apply, but a couple of fairly recent developments are pushing this issue up the priority list:

  • The increased popularity and adoption of new and emerging technologies, such as cloud computing,
  • New risks and new guidance in electronic banking,
  • The SAS 70 phase-out
  • Examiners are hearing these three words more and more; “…they handle that…“.

All these really go together.  Think about this…is there a critical product or service you offer that doesn’t involve a third-party relationship?  I’ve asked that question at a number of meetings and conferences this year and have yet to have anyone come up with an example.  And to further underscore the point, how many of your vendors have vendors of their own?

So more reliance on outsourcing means that examiners are hearing the phrase “they handle that” more often when they ask about data security.  But as we all know…

Management is responsible for ensuring the protection of institution and customer data, even when that data is transmitted, processed, stored, or disposed of by a service provider.1

In the past, saying “they handle that” to an auditor or examiner was usually followed up with “OK, let’s see the SAS 70 and financials on that vendor”.  You would produce the reports, and that was pretty much the end of that conversation, and indeed often the extent of your vendor management responsibility.  I believe this will change, and I’ve already gotten some validation on that.

Going forward expect examiners to ask to see your entire vendor management program, not just the third-party reviews and financials, and not just on select vendors.  Any vendor that could have access (even incidental access) to non-public information (yours or your customers) must be risk-ranked by your vendor management program.  And the process of evaluating vendors starts well before they become a vendor, when you are still in the pre-implementation stage.

Here are some of the essential, and yet often missing, elements of a vendor management program:

  • Have you conducted due diligence prior to vendor selection?
  • Have you documented that the product or service is in alignment with the goals and objectives of your strategic plan?
  • Is a BSCA filing required?
  • Are the vendor’s disaster recovery capabilities adequate to support your recovery time objectives?
  • Are vendor performance standards (SLA’s) clearly defined?
  • In addition to vendor access to NPI/PII, have you risk-ranked your vendors based on:
    • Access to other confidential (i.e. proprietary) information?
    • Criticality of the product/service they provide?
    • Complexity of the product/service?

Additionally, the new electronic banking guidance will force financial institutions to take a closer look at their Internet banking providers in order to conduct the required (starting in January) risk assessments.  When the examiner asks for your electronic banking risk assessment, and wants to know what layered controls have been implemented, you can not say “our provider handles that”.  The whole point of a risk assessment is to assure that you know, and are comfortable with, the residual risk.

And finally, the third-party report that will likely replace the SAS 70 for most service providers will be the SOC 2, and unlike the SAS 70 the SOC 2 is designed to be a deep dive into the control environment of the service provider.  Also unlike the SAS 70, financial institutions will have to actually review the SOC 2 document to assure themselves that there are no exclusions or other qualifications in the report, and to review the results of control testing (for a Type II).  And unless the service provider specifically excludes it from the report, you will also have a high degree of confidence that any sub-service organizations (providers to your provider) have an adequate control environment as well.

So for all these reasons, expect vendor management to be an increased regulatory priority in 2012.

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:

  1. Security. The service provider’s systems is protected against unauthorized access.
  2. Availability. The service provider’s system is available for operation as contractually committed or agreed.
  3. Processing Integrity. The provider’s system is accurate, complete, and trustworthy.
  4. Confidentiality. Information designated as confidential is protected as contractually committed or agreed.
  5. 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:

  1. The Privacy and Security elements of GLBA
  2. Availability
  3. Integrity of data or systems
  4. Confidentiality of data or systems
  5. Accountability
  6. 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:

  1. Use the lead provider to manage all of their subordinate relationships, or
  2. 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:

  1. Risk Assessment (assessing the risk of outsourcing)
  2. Service Provider Selection (the due diligence process)
  3. Contract Issues (prior to signing the contract)
  4. 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…

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