Tag: SOC

02 Dec 2014
Hot Topics Tom Hinkel 0 comment

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″]

23 Jul 2014
Hot Topics Tom Hinkel 0 comment

Cybersecurity – Part 2

In Part 1 I discussed the increasing regulatory focus on cybersecurity, and what to expect in the short term.  In this post I want to dissect the individual elements of cybersecurity, and list what you’ll need to do to demonstrate compliance on each one going forward. So here are the required elements of a cybersecurity program, followed by what you need to do:

  • Governance – risk management and oversight
  • Threat intelligence and collaboration – Internal & External Resources
  • Third -party service provider and vendor risk management
  • Incident response and resilience

1.     Governance – risk management and oversight

Nothing new about this one, virtually all FFIEC IT Handbooks list proper governance as the first and most important item necessary for compliance, and governance begins at the top.  In fact a recent FFIEC webinar was titled “Executive Leadership of Cybersecurity: What Today’s CEO Needs to Know About the Threats They Don’t See.”  But governance involves more than just management oversight.  The IT Handbook defines it this way:

“Governance is achieved through the management structure, assignment of responsibilities and authority, establishment of policies, standards and procedures, allocation of resources, monitoring, and accountability.”

 What you need to do:

  •  Update & Test your Policies, Procedures and Practices.  Verify that cyber threats are specifically included in your information security, incident response, and business continuity policies.
  • Assess your Cybersecurity Risk (Risk = Threat times Vulnerability minus Controls).  When selecting controls, remember that there are three categories; preventive, detective, and responsive/corrective.  Preventive controls are always best, but given the increasing reliance on third-parties for data processing and storage, they may not be optimal.  Focus instead on detective and responsive controls.  Also, make sure your assessment accounts for any actual events affecting you or your vendors.  Document both:
    • Inherent cybersecurity risk exposure – risk level prior to application of mitigating controls
    • Residual cybersecurity risk exposure – risk remaining after application of controls
  • Adjust your Policies, Procedures and Practices as needed based on the risk assessment results.
  • Use your IT Steering Committee (or equivalent) to manage the process.
  • Provide periodic Board updates.

2.     Threat intelligence and collaboration – Internal & External Resources

This element reflects both the complexity and the pervasiveness of the  cybersecurity problem, and (unlike governance) is a particular challenge to smaller institutions (<1B).  According to a study conducted in May of this year by the New York State Department of Financial Services, the information security frameworks of small institutions lagged behind larger institutions in two key areas: oversight over third party service providers (more on that later), and membership in an information-sharing organization.

What you need to do:

Regulators expect all financial institutions to identify and monitor cyber-threats to their organization, and to the financial sector as a whole.  Make sure this “real-world” information is factored into your risk assessment.  Some information sharing resources include:

3.     Third -party service provider and vendor risk management

For the vast majority of outsourced financial institutions, managing cybersecurity comes down to managing the risk originating at third-party providers and other unaffiliated third-parties. As the Chairman of the FFIEC, Thomas J Curry, recently stated:

“One area of ongoing concern is the increasing reliance on third parties..The OCC has long considered bank oversight of third parties to be an important part of a bank’s overall risk management capability.”

Smaller institutions may be even more at risk, because they tend to rely more on third-parties, and (as I pointed out earlier) tend to lag behind larger institutions when it comes to vendor management.  This is mostly because of available internal resources.  Larger institutions may conduct their own compliance audits, while smaller institutions may rely more on external resources, such as SOC reports and FFIEC Reports of Examination (ROE).  And once the reports are received, interpreting them to determine if they indeed address your concerns can be an even bigger challenge.

What you need to do:

Regardless of size, all institutions should  employ basic vendor management best practices to understand and control third-party risk.  Pay particular attention to the following:

  • Pre-contract Planning & Due Diligence – in addition to reviewing the SOC reports and ROE’s, determine if the vendor had any significant recent security events.
  • Contracts – they should define if and how you’ll be notified in the event of a security event involving you or your customer’s data, and who is responsible for customer notification.  They should also include a “right-to-audit” clause, giving you the right to conduct audits at the service provider if necessary.
  • Ongoing Monitoring – in addition to updated SOC reports, financials, and ROE’s, don’t forget to take advantage of vendor forums and user groups.  As the FFIEC statement stressed:

“…financial institutions that utilize third party service providers should check with their provider about the existence of user groups that also could be valuable sources of information.”

  • Termination/Disengagement – management should understand what happens to their data at the end of the relationship.

4.     Incident response and resilience

Incident response has been mentioned in all regulatory statements about cybersecurity, and for good reason.  Regardless of whether it originates internally or externally, a security incident is a virtual certainty.  And regulators know that although vendor oversight does provide some measure of assurance, you have very little actual control over specific vendor-based preventive controls.  So detective and corrective/responsive controls must compensate.

What you need to do:

Make sure your incident response program (IRP) has been updated to accommodate a response to a cybersecurity event.  As I stated in Part 1, your existing policies should already do this if they are impact-based instead of threat-based.  “Cyber” simply refers to the source or nature of the threat.  The impact of a cybersecurity event is generally the same as any other adverse event; information is compromised or business is interrupted.  However, all IRP’s should contain certain elements:

  • The incident response team members
  • A method for classifying the severity of the incident
  • A response based on severity, to include internal escalation, and external notification.
  • Periodic testing and Board reporting

Regarding testing, the FFIEC considers it so important they refer to it as one of the primary take-aways from their recent webinar, encouraging all institutions to consider:

How often is my institution testing its plans to respond to a cyber attack? Do these tests include our key internal and external stakeholders?

 In summary, review the requirements for cybersecurity, and compare them with your current policies, procedures and practices.  Hopefully you’ve already incorporated many (if not most) of these elements into your program, and very little adjustment needs to be made.  But either way, be prepared to discuss what you are doing, and how you are doing it, with the regulators…they WILL be asking you.

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.

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