Tag: SOC 2

30 May 2018
Digital Files

Ask the Guru: A Prospective Vendor Either Won’t or Can’t Provide the Documentation We Need. What Should We Do?

Hey Guru!

We’re doing our due diligence on a new HR software package. We’ve requested the vendor’s financials and a SOC 2 report, but they told us they don’t provide financials (they are privately held), and their SOC 2 won’t be completed until the end of the year. They do have a SOC 1. What are your thoughts on this?


As with almost everything else, this starts with the risk assessment. What are your primary concerns with this vendor? They probably fall in 2 main categories; the security of the confidential data they store and process, and the criticality of the service they provide. A sound set of financials will give you some assurance that they can continue as an on-going concern and fulfill the terms of their contract. A SOC report will give you assurance that they have an effective control system in place for your confidential data. SO without either, how do you assure yourself? You’ll need to find alternate assurances, otherwise known as compensating controls.

In the absence of audited financials, one way to gain at least some assurance about the financial health of the company is to pull a D&B report. Another way is to ask the company for their banking contact as a reference, but as a private company they may be reluctant to provide that. In the end, if you aren’t able to gain sufficient assurance of their ability to continue to function, you’ll need to identify alternative vendors that can step in if needed.

Regarding assurances of their control environment in the absence of a SOC 2 report, this is a bit more difficult because there are potentially 5 criteria covered in a SOC 2 report; confidentiality, data integrity, data availability, privacy and security. Their SOC 1 may speak to data processing integrity, but compensating controls for the other criteria will have to be pieced together. BCP plans and testing results can speak to data availability. InfoSec policies, vulnerability assessments and PEN test results can speak to the security criteria. The contract and/or non-disclosure agreement (NDA) may contain privacy and confidentiality elements.

In the end, you’ll need to decide if the compensating controls in these areas result in a residual risk level within your risk appetite. If not, you may be better of waiting until the SOC 2 is released.

02 Dec 2014

Vendor Management in 3 Parts. Part 3 – Risk Management (or, “can we or can’t we?”)

The last step in the vendor management process is to manage, or control, the risk that was identified in step 1, and assessed (as inherent risk) in step 2.  Controlling risk is defined as applying risk mitigation techniques (or “controls”) to reduce risk to acceptable levels  It’s important to understand that risk can never be completely eliminated, particularly third-party risk.  The goal of this last step is to understand the remaining risk, referred to as “residual risk”, and to decide if this residual risk level is acceptable to you.  Everything that has been done thus far in the risk management process has been building up to this point.  But you may not be done yet.  If residual risk is not necessarily within the “acceptable” range, additional controls must be implemented to further reduce risk to an acceptable level.  Think of step 3 as a cycle; apply controls, evaluate residual risk, if residual risk is not acceptable, apply additional controls.  Repeat until residual risk is acceptable.

So the risk management process begins by asking a series of “can we or can’t we?” questions (all of which should be answered “yes”):

  • Can we or can’t we…assure ourselves that the vendor understands the unique regulatory environment of financial institutions?
  • Can we or can’t we…gain an in-depth understanding of what the vendor is doing to protect our information?
  • Can we or can’t we…trust the vendor’s description of their controls, both what they are, and how effective they are?
  • Can we or can’t we…accurately measure the residual risk level of this vendor relationship, and…
  • Can we or can’t we…come to the conclusion that the residual risk level of this vendor is acceptable?

The answer to the first 2 questions depends on A.) how familiar the vendor is with the regulatory requirements of financial institutions, and B.) how forthcoming the vendor is about their internal processes that relate to information security.  As the FFIEC recently stated regarding outsourced cloud computing (but applying equally to all third-party providers):

Managing a cloud computing service provider may require additional controls if the servicer is unfamiliar with the financial industry and the financial institution’s legal and regulatory requirements for safeguarding customer information and other sensitive data. Additionally, the use of such a servicer may present risks that the institution is unable or unwilling to mitigate. One example of such risks would be if the servicer is not implementing changes to meet regulatory requirements. Under such circumstances, management may determine that the institution cannot employ the servicer.

 So if you can’t answer “yes” to the first 2 questions about the vendor’s familiarity with financial institutions and whether they will be forthcoming about their controls, then the answer to the last question about acceptable risk is most likely “no”.

Regarding the third question about trust, third-party audit reports are the best way to gain assurance that vendor controls are both adequate and effective.  SOC reports give third-party validation that financial reports (SOC 1) and information privacy, security, confidentiality, availability and integrity (SOC 2) are both adequate (Type 1) and effective (Type 2).  Without this validation all you have is the assertion of the vendor, which is inadequate for high-risk vendors.  For third-party providers that either process, transmit, or store customer data, a SOC 2 Type II report is essential.

One more thing about controls…you should do everything you can to match the control to the risk.  For example, if there is a high degree of complexity in the service the vendor provides, identifying an alternate vendor is important.  If the criticality is high (as defined by the recovery time objective of any interdependent services), then you should insist on a copy of the vendor’s business continuity plan and testing results.  Audited financials are also important for all critical contracted services to assure that the vendor has the financial strength and stability to honor the terms of their contract.  And as I mentioned previously, a SOC 2 report is essential if the vendor processes or stores customer NPI.

To summarize the entire 3-part vendor management process:  First, you must identify the source of the risk.  In other words, the vendors you utilize along with their associated products and services (more here).  Second, each vendor must be assessed for risk…risk arising from access to customer NPI and confidential data, risk arising from vendor failure, risk arising from vendor criticality and complexity (more here).  Finally, controls are applied to reduce risk down to an acceptable level.  Follow this 3-part approach when you tackle vendor management internally… and demand it from your provider if you outsource the process.

 


 

[poll id=”9″]

11 Dec 2012

Technology Service Providers and the new SOC reports

What do all of the 2012 changes to the IT Examination Handbooks have in common?  They are all, directly or indirectly, related to vendor management.  I had previously identified vendor management as a leading candidate for increased regulatory scrutiny in 2012, and boy was it.  (Not all of my 2012 predictions fared as well, I’ll take a closer look at the rest of them in a future post.)

So there is definitely more regulatory focus on vendors, and it’s a pretty safe bet that this will continue into 2013.  It usually takes about 6-12 months before new guidance is fully digested into the examination process, so expect additional scrutiny of your vendor management process during your 2013 examination cycle.  Since guidance is notoriously non-prescriptive we don’t know exactly what to expect, but we can be certain that third-party reviews will be more important than ever.  Third-party audit reports, such as the SAS 70 in previous years, and now the new SOC reports (particularly the SOC 1 & SOC 2), provide the best assurance that your vendors are in fact treating your data with the same degree of care that regulators expect from you.  As the FFIEC stated in their recent release on Cloud Computing:

“A financial institution’s use of third parties to achieve its strategic plan does not diminish the responsibility of the board of directors and  management to ensure that the third-party activity is conducted in a safe and sound manner and in compliance with applicable laws and regulations.”

Undoubtedly third-party audit reports will still be the best way for you to ensure that your vendors are compliant, but there seems to be considerable confusion about exactly which of the 3 new SOC reports are the “right” ones for you.  In fact, in a recent webinar we hosted with a leading accounting firm, one of the firm’s partners stated that “there are a few instances where you might receive a SOC 1 report where a SOC 2 might be more appropriate”.  And this is exactly what we are seeing, technology service providers are having a SOC 1 report prepared when what the financial institution really wants and needs is a SOC 2.

Why is it important for you to understand this?  Because the SOC 1 (also known as the SSAE 16) reporting standard specifically states that it be used only for assessing controls over financial reporting.  It is their auditor telling your auditor that the information they are feeding into your financial statements is reliable.  On the other hand the SOC 2 reporting standard is a statement from their auditor directly to you, and addresses the following criteria:

  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. Privacy &
  2. Security (elements of GLBA)
  3. Availability
  4. Integrity of data or systems
  5. Confidentiality of data or systems
  6. Accountability
  7. Assurance

As you can see, there is considerable overlap between what the FFIEC expects of you, and what the SOC 2 report tells you about your service provider.  So why are we seeing so many service providers prepare SOC 1 reports when the SOC 2 is called for?  I think there are two reasons; first, because they are functionally equivalent, the SOC 1 is an easier transition if they are coming from the SAS 70.  I can tell you from our transition experience that the SOC 2 reporting standard is not just different, it is substantially broader and deeper than the SAS 70.  So some vendors may simply be taking the path of least resistance.

But the primary reason is that if the vendor provides a service to you that directly impacts your financial statements (like the calculation of interest) they must produce a SOC 1.  But, if they additionally provide services unrelated to your financial statements, should they also produce a SOC 2?  In almost every case, the answer is “yes”, because for all of the above reasons, the SOC 1 simply will not address all of your concerns.

The next couple of years will be transitional ones for most technology service providers as they adjust to the new auditing standards, and for you as you begin to digest the new reports.  But will the examiners be willing to give you a transition period?  In other words, should you wait for your examiner to find fault with your vendor management program to start updating it?  I’m not sure that taking a wait-and-see attitude is prudent in this case.  The regulatory expectations are out there now, the reporting standards are out there, and the risk is real…you need to be pro-active in your response.

(NOTE:  This will be covered more completely in a future post, but the CFPB has also recently issued guidance on vendor management…and they are staffing up with new examiners.  Are there three scarier words to a financial institution than “entry-level examiners”?!)

04 Jun 2012

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

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.

06 Feb 2012

NIST releases new Cloud Computing Guidelines

Although not specific to the financial industry, the new guidelines provide a comprehensive overview of the privacy and security challenges of this increasingly popular computing model.  It’s worth a look by both financial institutions considering cloud-based services, as well as service providers, because NIST guidelines often wind up as the basis for new or updated regulatory guidance.

They start by defining the concept of cloud computing as characterized by the “…displacement of data and services from inside to outside the organization” and by correctly observing that “…many of the features that make cloud computing attractive, however, can also be at odds with traditional security models and controls.”   This pretty accurately summarizes the challenges faced by financial institutions as they consider, and try to manage, the risks of cloud computing…data and services are out of their direct control, but risks of privacy, security, confidentiality, data integrity and availability must be controlled.

NIST offers the following guidelines for overseeing cloud services and service providers:

  • Carefully plan the security and privacy aspects of cloud computing solutions before engaging them.
  • Understand the public cloud computing environment offered by the cloud provider.
  • Ensure that a cloud computing solution satisfies organizational security and privacy requirements.
  • Ensure that the client-side computing environment meets organizational security and privacy requirements for cloud computing.
  • Maintain accountability over the privacy and security of data and applications implemented and deployed in public cloud computing environments.

For financial institutions, all these guidelines should be addressed in your existing policies.  The privacy and security elements are mandated by GLBA, and should already be present in your information security program.  One of the required, but often overlooked, elements of your vendor management program is the requirement to strategically justify your decision to engage a cloud services provider, and periodically review and reaffirm that decision.  Understanding the cloud provider environment is indeed a challenge for financial institutions, and I have already addressed this, and some possible solutions, here.  I’ve also discussed why increased adoption of cloud-based services will likely make vendor management a topic of increased regulatory scrutiny in 2012 here.  Additionally I think that the new SOC 2 report will directly address many of the concerns facing institutions employing cloud-based services.

As for the FFIEC, I was surprised to see that a search of the word “cloud” on the IT Examination InfoBase turned up not one single mention.  The Handbooks are getting a bit dated…perhaps, given the importance of managing outsourced relationships, plus the increased challenges of cloud computing, they should address this next?  Or do you think the existing guidance on managing outsourced technology and vendors is sufficiently broad?