Tag: cloud computing

17 Dec 2013

FFIEC Issues Final Social Media Guidance…and Challenges Remain

Originally proposed back in January 2013, and following a comment period in which they received and evaluated 81 official comments, the FFIEC has at last released their final guidance for financial institutions engaging in social media activities.  I expect all the regulatory agencies to adopt it soon (the FDIC has already, and pretty much verbatim).

According to the FFIEC, this final guidance is “…substantially as proposed, but with some changes“.  I wrote about this when it was first proposed and I encourage you to read my original post for the specific components of a social media risk management program.  This post will focus only on the major changes between the two, and four main “grey” areas that I felt required clarification for institutions.

I did a word-for-word comparison of the verbiage in the proposed with the final, and there seemed to be some softening of the verbiage in some areas (no doubt due to the comments received).  For example, originally the guidance said that “…this form of customer interaction…occurs in a less secure environment, and presents some unique challenges…”.  This was changed to “…Since this form of customer interaction…MAY occur in a less secure environment, it CAN present some unique challenges…”.  Other  areas were expanded, for example the requirement to provide “guidance” for employees was expanded to “guidance AND TRAINING“.  Also, the risk management component that included “…A DUE DILIGENCE process for selecting and managing third-party service provider relationships” was changed to “…A RISK MANAGEMENT process for selecting and managing third-party relationships….”.

There were minor clarifications to Reg Z and UDAAP expectations, and a fairly considerable expansion of the CRA requirement to retain public comments.  Fortunately this was limited to comments received only through social media sites run by, or on behalf of, the institution.  Comments made elsewhere would not have to be retained, as they are “not deemed to have been received by the institution”.  (Unfortunately this “not deemed to have been received” concept applies only to CRA comments, not complaints or disputes.  See #2 below.)  Finally the guidance makes it clear that email and text messages on their own do not constitute social media…unless (presumably) they are facilitated through a social media platform.

Here are the four “grey” areas that I think needed the most clarification for financial institutions, and my interpretation of the guidance:

  1. Does the guidance impose a single standard of expectations for all institutions regardless of their degree of involvement in social media activities?
    • No.  Although all institutions are expected to implement a risk management program, it should be consistent with breadth of the institutions involvement in social media activities.  And it should be designed with input from folks in compliance, technology, information security, legal, human resources, and marketing.  However, even institutions who choose to not use social media should be aware of the risks of not being able to respond to negative comments or complaints that may arise elsewhere. (More on that in the next bullet.)  So it looks as if a policy and a risk assessment are required regardless of the level of your involvement in social media activities, even if you choose to opt out.
  2. Would institutions be required to monitor and respond to all communications about the institution throughout the Internet?
    • No, but institutions are expected to understand the risks of NOT being able to respond, particularly the reputation risks of not being able to respond to complaints or disputes originating from other channels.  They also mention the “challenge” for institutions to protect their brand identity by being aware of the risk of someone “spoofing”, or masquerading, as the institution.  All these risks exist regardless of the institutions decision to engage in social media activities.  In fact, responding to a negative comment or spoofing attack may be much more challenging if you’ve decided to not engage at all, or even not to engage on a particular platform.  For example, if a comment is made on Twitter and you don’t have a Twitter account.  The guidance still recommends the use of social media monitoring tools and techniques to identify potential risks but leaves the procedural specifics, and any actual response, up to the institution.
  3. How much control would be required over employee use of social media, both during business hours, but more specifically on their own time?
    • Not as much as the proposed guidance first indicated.  The final guidance makes a clear distinction between employee “official” use, and employee “personal” use.  Institutions must establish policies and training that clearly outline what employees are, and are not, allowed to communicate in their official capacity.  But the guidance stopped short of requiring institutions to impose any restrictions on employee personal use of social media, saying only that institutions evaluate the risks for themselves and determine appropriate policies.  Since the potential for reputation risk exists regardless of whether employees are posting officially or personally, I believe you should strongly consider including guidelines for employee personal use in your training, even if it’s not covered in your policies.
  4. How much due diligence is required by institutions for social media providers?
    • Plenty.  And in my opinion vendor management is where the biggest challenges lie for financial institutions.  The guidance states that “…Working with third parties to provide social media services can expose financial institutions to substantial reputation risk.”  (emphasis mine)  And they point out that this guidance “…does not impose any new requirements…”.  So the regulators require the same degree of due diligence for social media vendors that they require for all other potentially high-risk service providers, and just as with any other outsourced relationship, you are expected to complete it prior to engaging with the provider.

But selecting and risk-managing social media vendors is much more challenging.  First of all, unlike with other initiatives, once you’ve selected your platform you don’t have a choice of providers.  If you choose to utilize Facebook or LinkedIn or Twitter for example, the provider is the platform.  It’s not as if you can select among multiple Facebook vendors!  Furthermore you are expected to be aware of matters such as the vendor’s reputation, their policies regarding use of your (and your customers) information, how (and how often) their policies might change, and what (if any) control you have over the vendors policies and actions.  So let’s take a look at these expectations in order:

  • The vendor’s reputation?
  • Their policies?
    • Social media vendors exist to sell advertising.  Their policies exist to support their profit model, which is to try to get their users to disclose as much information as possible about themselves in order to better target advertising.  Regardless of what they may state in their privacy policy, contrast their business objectives with yours.
  • How often might social media vendors change policies?
    • As often as they like, and without prior notification.
  • What control do you have over the vendors’ policies and actions?
    • None.

Once you’ve assessed all potential risks, your next challenge is to try to mitigate them.  Standard vendor risk controls for vendors consist of requesting, obtaining, and reviewing documentation such as financial reports, third-party audits, contractual confirmation of GLBA adherence, BCP testing results, etc.  But often requests for this type of documentation are either ignored or refused by social media providers, and even when documentation is provided, it doesn’t directly address your privacy, confidentiality, and security concerns.  Social media service providers are simply not used to dealing with the unique regulatory reporting requirements of the financial industry.  And accord to the FFIEC “…a financial institution should thus weigh these (residual risk) issues against the benefits of using a third party to conduct social media activities.”  Unfortunately, social media is one activity that must be outsourced.

One more thing to consider is that all social media providers are also (by FFIEC definition*) cloud service providers, and as such subject to all of the guidelines for Outsourced Cloud Computing as well.  Given the risk management challenges of social media, institutions may want to remember what the FFIEC had to say about providers that are unfamiliar with the financial industry, or unwilling to implement changes to their policies or procedures to meet changing regulatory requirements:  “Under such circumstances, management may determine that the institution cannot employ the servicer.”

So in summary, the FFIEC seems to be telling financial institutions “proceed if you must, but proceed cautiously…and don’t take any shortcuts”.  And I will repeat what I first said back in 2011…the challenge of risk managing social media boils down to this:  You are accepting an either (at best) higher level of residual risk or an (at worst) unknown level of risk, to achieve an uncertain amount of benefit.  Oh, and risk avoidance is not an option.

*”…cloud computing is a migration from owned resources to shared resources in which client users receive information technology services, on demand, from third-party service providers via the Internet ‘cloud.'” – FFIEC Statement on Outsourced Cloud Computing, July 10, 2012

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”?!)

08 Aug 2012

7 Cloud Vendor Deal Breakers for Financial Institutions

With all the recent focus on vendor management in general, and cloud vendors in particular, there has been a lot of discussion about changing regulatory requirements and best practices.  For the most part, cloud vendors must adhere to the same due diligence, contract, and monitoring guidelines as any other vendor  However there are a few (often overlooked) elements that must be considered prior to engaging any cloud-based vendor.  Elements important enough to be deal breakers if you (and they) can’t answer “yes”.

  1. Do they contractually hold themselves to the same high data privacy, security, confidentiality, integrity and availability standards required of financial institutions?   It used to be understood that anyone offering services to financial institutions had to contractually adhere to GLBA guidelines, but with all the relatively new vendors competing for your business, it can’t be assumed or taken for granted any more.  Make sure the contract stipulates it.
  2. If so, can they document adherence to that standard by producing a third-party report, like the SOC 2?  Even if the contract stipulates adherence, you must determine the adequacy and effectiveness of a servicer’s internal controls by requesting, receiving and reviewing the appropriate third-party report prior to engaging…and then periodically throughout the relationship.
  3. Do you know exactly where your data will be physically stored?  Both the biggest strength and the biggest weakness for cloud vendors is in the redundant and distributed nature of the data.  Having data stored multiple times in multiple locations throughout the country is great for high availability, but makes it almost impossible to ensure compliance with your policies for proper handling and storing of information.  You must know where you data is located at all times, and how it gets there.  And if your data is transmitted or stored outside the U.S., you’ll need to understand the rules and regulations of the hosting country.
  4. Will they retain and destroy information consistent with your internal data retention policies?  Internal retention and destruction policies must be observed regardless of how or where the data is stored.  If the data is stored in multiple locations, are all occurrences destroyed?  There may be additional regulatory and legal exposure if data is either destroyed too early, or retained too long.
  5. What happens to your data once your relationship with the vendor is terminated?  The vendor disengagement process is particularly challenging with cloud vendors because you can’t simply walk away any more than you can just throw out a hard drive.  Is the data irretrievably wiped, or simply deleted?  What about the encryption keys?
  6. Do they have a broad and deep familiarity with the regulatory requirements of the financial industry?  According to the most recent statement from the FFIEC on managing cloud vendors, because of the increased legal and regulatory risks, “managing a cloud computing service provider may require additional controls if the servicer is unfamiliar with the financial industry”.
  7. If so, are they willing and able to make changes to their service offerings necessitated by those requirements? Even if the vendor demonstrates adequate familiarity with the financial industry, are they willing to make the necessary changes in their services if and when regulations change?  Unless financial companies make up the majority of their clientele, they may not be, and “under such circumstances, management may determine that the institution cannot employ the servicer.”
10 Jul 2012

FFIEC issues Cloud Computing Guidance

Actually the document is classified as “for informational purposes only”, which is to say that it is not a change or update to any specific Handbook and presumably does not carry the weight of regulatory guidance.  However, it is worth a read by all financial institutions outsourcing services because it provides reinforcement for, and references to, all applicable guidance and best practices surrounding cloud computing.

It is a fairly short document (4 pages) and again does not represent a new approach, but rather reinforces the fact that managing cloud providers is really just a best practices exercise in vendor management.  It makes repeated reference to the existing guidance found in the Information Security and Outsourcing Technology Services Handbooks.  It also introduces a completely new section of the InfoBase called Reference Materials.

The very first statement in the document pretty well sums it up:

“The (FFIEC) Agencies consider cloud computing to be another form of outsourcing with the same basic risk characteristics and risk management requirements as traditional forms of outsourcing.”

It then proceeds to describe basic vendor management best practices such as information security and business continuity, but one big take-away for me was the reference to data classification.  This is not the first time we’ve seen this term, I wrote about examiners asking for it here, and the Information Security Handbook says that:

“Institutions may establish an information data classification program to identify and rank data, systems, and applications in order of importance.”

But when all your sensitive data is stored, transmitted, and processed in a controlled environment  (i.e. between you and your core provider) a simple schematic will usually suffice to document data flow.  No need to classify and segregate data, all data is treated equally regardless of sensitivity.  However once that data enters the cloud you lose that control.  What path did the data take to get to the cloud provider?  Where exactly is the data stored?  Who else has access to the data?  And what about traditional issues such as recoverability and data retention and destruction?

Another important point made in the document, and one that doesn’t appear in any other guidance,  is that because of the unique legal and regulatory challenges faced by financial institutions, the cloud vendor should be familiar with the financial industry.  They even suggest that if the vendor is not keeping up with regulatory changes (either because the are unwilling or unable) you may determine on that basis that you cannot employ that vendor.

The document concludes by stating that:

“The fundamentals of risk and risk management defined in the IT Handbook apply to cloud computing as they do to other forms of outsourcing. Cloud computing may require more robust controls due to the nature of the service.”

And…

“Vendor management, information security, audits, legal and regulatory compliance, and business continuity planning are key elements of sound risk management and risk mitigation controls for cloud computing.”

…as they are for all outsourced relationships!

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?