Tag: SAS 70

04 Jun 2012
Hot Topics Tom Hinkel 0 comment

5 Keys to Understanding a SOC 2 Report

Although I have written about these relatively new reports frequently, and for some time now, it still remains a topic of great interest to financial institutions.  Fully 20% of all searches on this site over the past 6 months include the terms “SOC” or “SOC 2”, or “SAS 70”.  Some of this increased interest comes from new FFIEC guidance on how financial institutions should manage their service provider relationships, and some of it comes from financial institutions that are just now seeing these new reports from their vendors for the first time.  And because the SOC 2 is designed to focus on organizations that collect, process, transmit, store, organize, maintain or dispose of information on behalf of others, you are likely to see many more of them going forward.

Having just completed our own SOC 2 (transitioning from the SAS 70 in the previous period), I can say unequivocally that  not only is it much more detailed, but that it has the potential to directly addresses the risks and controls that should concern you as the recipient of IT related services.  But not all SOC 2 reports are alike, and you must review the report that your vendor gives you to determine its relevance to you.  Here are the 5 things you must look for in every report:

  1. Products and Services – Does the report address the products and services you’ve contracted for?

  2. Criteria – Which of the 5 Trust Services Criteria (privacy, security, confidentiality, availability and data integrity) are included in the report?

  3. Sub-service Providers – Does the report cover the subcontractors (sub-service providers) of the vendor?

  4. Type I or Type II – Does the report address the effectiveness of the controls (Type II), or only the suitability of controls (Type I)?

  5. Exceptions – Is the report “clean”?  Does it contain any material exceptions?

Before we get into the details of each item, it is important to understand how a SOC 2 report is structured.  There are 3 distinct sections to a SOC 2 (and they generally appear in this order);

  1. The Service Auditors Report,
  2. The Managements Assertion, and
  3. The Description of Systems.

So simply put, what happens in a SOC 2 report is that your service providers’ management prepares a detailed description of the systems and processes they use to deliver their products and services to you, and the controls they have in place to manage the risks.  They then make an assertion that the description is accurate and complete.  Finally, the auditor renders an opinion on whether or not the description is “fair” as to control suitability (Type I) and effectiveness (Type II).

Products and Services

The first thing to look for in a SOC 2 report is generally found in the Management’s Assertion section.   It will state something to the effect that “…the system description is intended to provide users with information about the X, Y and Z services…”  You should be able to identify all of your products and services among the “X”, “Y”, and “Z”.  If you have a product or service with the vendor that is not specifically mentioned, you’ll need to satisfy yourself that the systems and processes in place for your products are the same as they are for the products covered in the report.  (You should also encourage the vendor to include your products in their next report.)

Criteria

The next thing to look for is found in the Service Auditor’s Report section.  Look for the term “Trust Services Principles and Criteria”, and make a note of which of the 5 criteria are listed.  The 5 possible covered criteria are:  Privacy, Security, Confidentiality, Integrity and Availability.  Service provider management is allowed to select which criteria they want included in the report, and once again you should make sure your specific concerns are addressed.

Sub-service Providers

The next item is also found in the Service Auditor’s Report section, and usually in the first paragraph or two.  Look for either “…our examination included controls of the sub-service providers”, or “…our examination did not extend to controls of sub-service providers”.  The report may also use the terms “inclusive” to indicate that they DID look at sub-service providers, or “carve-out” to indicate that the auditor DID NOT look at the controls of any sub-service providers.  These are the service providers to your service provider, and if they store or process your (or your customers) data you’ll need assurance that they are being held to the same standards as your first-level service provider.  This assurance, if required and  not provided in the SOC 2, may be found in a review of the sub-service provider’s third-party reviews.

Type I or Type II

As with the older SAS 70, the new SOC 1 and SOC 2 reports come in two versions; a Type I, which reports on the adequacy of controls as of a single point in time, and a Type II, which reports on both control adequacy and effectiveness by evaluating the controls over a period of time, typically 6 months.  Clearly the Type II report is preferred, but because the SOC 2 audit guides were just released last year, most service providers may choose to initially release a Type I.  If your concerns about the service provider include whether or not their risk management controls were both adequate AND effective (and in most cases they should), make sure they immediately follow up the Type I with a Type II.

Exceptions

Finally, scan the Service Auditor’s Report section for verbiage such as “except for the matter described in the preceding paragraph…”, or “the controls were not suitably designed…” or “…disclaim an opinion…”, or terms such as “omission” or “misrepresentation” or “inadequate”.  These are an indication that the report could contain important material exceptions that would be cause for concern.

One more thing…pay particular attention to a sub-section (usually found in Description of Systems section) called “Complementary End-User (or User-Entity) Controls”.  This is not new to the SOC reports, the SAS 70 had a similar section, but it is one of the most important parts of the entire report, and one that is often ignored.  This is a list of what the vendor expects from you.  Things without which some or all of the criteria would not be met.  This is the vendor saying “we’ll do our part to keep your data private, secure, available, etc.,  but we expect you to do a few things too”.  It’s important that you understand these items, because the entire auditor’s opinion depends on you doing your part, and failure to do so could invalidate some or all of the trust criteria.  By the way, you should be able to find a corresponding list of these end-user controls repeated in your contracts.

The lesson here is that vendor third-party reviews like the SOC 2 are no longer a “check the box and be done” type of exercise.  As part of your vendor management process, you must actually review the reports, understand them (don’t hesitate to enlist the help of your own auditor if necessary), and document that they adequately address your concerns.

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.

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

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