Outsourcing – Compliance Guru

18 Nov 2014

Hot Topics Tom Hinkel 5 Comments

Vendor Management in 3 Parts. Part 2 – Risk Assessment (or, “will they or won’t they?”)

In Part 1 I said that vendor management, just as any other risk management endeavor, consists of 3 basic phases;

Identify the risk
Assess the risk, and
Control the risk

I also discussed why risk identification was a more difficult task today because of the “access to data” question, and also because “data” includes not just NPI, but confidential data as well. Everyone from your technology providers to the office cleaning crew could have access to non-public or confidential data, and as a result must be included in Phase 2; the risk assessment. The good news is that even though all vendors must be assessed, only a handful will required significant follow-up in terms of controls reviews (phase 3).

So in this post I will discuss how the risk assessment of vendors has changed over the last few years. Traditionally assessing a vendor was limited to determining the extent to which the vendor had access to (and could possibly disclose) non-public customer information (NPI). This grew out of GLBA, specifically the privacy and security elements of the legislation. Today regulators expect a much broader assessment of third-party risk. In addition to NPI, you must also assess vendor access to confidential information, such as HR records, Board reports, strategic plans and unaudited financials. You should also understand how a failure of the vendor’s product might affect your ability to deliver critical products or services to your customers. Does the vendor provide interdependencies to critical products? If they failed, how many of your services would fail too? Additionally, how difficult (costly & time consuming) would it be to find an alternate vendor, should the need arise?

In a recent speech to a community bankers group, Thomas J. Curry (current FFIEC chairman and Comptroller of the Currency) stated:

“While they have important benefits and are in many ways an essential part of business, it can be easy for financial institutions to become overly dependent upon third parties and overly-trusting. But just because these contractors have long client lists and hard-to-duplicate expertise doesn’t mean they are infallible.”

So vendor risk assessments really come down to determining “will they or won’t they?”:

Will they or won’t they…disclose customer NPI?
Will they or won’t they…disclose confidential information?
Will they or won’t they…fail?
Will they or won’t they…meet the terms of the contract?
Will they or won’t they…continue to meet our strategic objectives?
Will they or won’t they…properly manage their third-party relationships?

Once these questions have been addressed (i.e. asked and answered) you have a good idea of the raw, or inherent, risk level. Now you are expected to…

“…have risk management practices in place that are commensurate with that risk.”

Asking the right “will they or won’t they” questions are the key to accurately assessing inherent risk. The next step is to manage (i.e. control) the risk at acceptable levels. More on that in Part 3.

[poll id=”9″]

14 Oct 2014

Hot Topics Tom Hinkel 0 comment

Vendor Management in 3 Parts. Part 1 – Risk Identification (or, “do they or don’t they?”)

Service provider oversight (aka vendor management) is undoubtedly the hottest hot-button item on the regulator’s agenda right now, and for good reason. For one thing, regulators know that the vast majority of financial institutions outsource at some point, in fact recent studies put the number of FI’s that either transmit, process or store information with third-parties at over 90%. They also know that most recent cyber security incidents affecting financial institutions involved third-party service providers. (The Chase breach is a notable exception.) And increased scrutiny of your vendor oversight program has been cited as a focal point for the ongoing regulatory cybersecurity assessments. Clearly a new vendor management standard is here, and a new expanded approach is required.

I’ve broken the vendor management process into 3 parts, and all areas must be expanded;

Risk Identification
Risk Assessment, and
Risk Management

Again, all three areas have increased expectations. You are expected to manage the risks of third-party relationships the same way you manage internal risk, and step 1 is always to identify the source of the risk. This is relatively simple when all data is stored and processed in-house, but that doesn’t reflect the current outsourced model. So identifying the source of the risk means asking the following question about the third-party…“do they or don’t they have access to my information”?

“Access” means everything from incidental read-only (as in a piece of paper or computer screen), to full read & write. In other words, vendors that provide or support critical processes clearly must be assessed, but anyone that might be allowed in your facility could conceivably see something non-public or confidential. And the definition of “information” has evolved from strictly non-public customer information (NPI), to anything you consider confidential, such as Board reports, HR records, strategic plans, and unaudited financials.

But I think the biggest challenge for most financial institutions is in understanding exactly how to define a “service provider”. The traditional thinking was that only at a few key providers (like core) were defined that way, but the definition of “service provider” has definitely expanded. In fact the Federal Reserve issued a regulatory update in 2013 titled “Guidance on Managing Outsourcing Risk“. In it, they defined “service providers” as

“…all entities that have entered into a contractual relationship with a financial institution to provide business functions or activities”.

The OCC defined it even more broadly, stating in their 2013 update “Risk Management Guidance on Third-party Relationships” that;

“…a third-party relationship is any business arrangement between a bank and another entity, by contract or otherwise.” (Emphasis added.)

So expand your definition of “access”, and expand your list of providers to include all potential sources of risk… from your core provider to your cleaning crew, all third-party relationships with all levels of access should be assessed.

One more thing, don’t forget to assess vendors that may not have access to sensitive information, but have a high degree of criticality. More on that in my next post on Risk Assessment.

[poll id=”9″]

05 Nov 2013

Hot Topics Tom Hinkel 0 comment

The OCC Sets a New Standard for Vendor Management…

…but will it become the new standard for institutions with other regulators? UPDATE – The answer is yes, at least for the Federal Reserve. Readers of this blog know that I’ve been predicting an increase in vendor management program scrutiny since early 2010. And although the FFIEC has been very active in this area, issuing multiple updates to outsourcing guidance in the past 2 years, it appears that the OCC is the first primary federal regulator (PFR) to formalize it into a prescriptive methodology.

So if you are a national bank or S&L regulated by the OCC, what you’ll want to know is “what changed”? They’ve been looking at your vendor management program for years as part of your safety & soundness exams, exactly what changes will they expect you to make going forward? The last time the OCC updated their vendor management guidance was back in 2001, so chances are you haven’t made many substantial changes in a while. That will change.

However if you are regulated by the FDIC or the Federal Reserve or the NCUA, so what? Nothing has changed, right? Well no…not yet anyway. Except for a change adding a “Vendor Management and Service Provider Oversight” section in the IT Officer’s Questionnaire back in 2007, the FDIC hasn’t issued any new or updated guidance since 2001. Similarly, the NCUA last issued guidance in 2007 but it was really a re-statement of existing guidance that was first issued in 2001. So considering the proliferation of outsourcing in the last 10 years, I believe all of the other regulators are overdue for updates. Furthermore, I believe the OCC did a very good job with this guidance, and all financial institutions regardless of regulator would be wise to take a close look.

So what’s changed? I compared the original 2001 bulletin (OCC 2001-47) side-by-side with the new one (OCC 2013-29), and although most of the content was very similar, there were some significant differences. Initially they both start out the same way; stating that banks are increasing both the number and the complexity of outsourced relationships. But the updated guidance goes on to state that…

“The OCC is concerned that the quality of risk management over third-party relationships may not be keeping pace with the level of risk and complexity of these relationships.”

They specifically cited failure to assess the direct and indirect costs, failure to perform adequate due diligence and monitoring, and multiple contract issues, as troublesome trends.

Conceptually, the new guidance focuses around a 5-phase “life-cycle” process of risk management. The life-cycle consists of:

Planning,
Due diligence and third-party selection,
Contract negotiation,
Ongoing monitoring, and
Termination

First of all, a “cycle” concept strongly suggests that a once-a-year approach to program updates is not sufficient. Secondly, I think the planning, or pre-vendor, phase is potentially the most significant in terms of the changes that regulators will expect going forward. For one thing, beginning the vendor management process BEFORE beginning the relationship (i.e. before the vendor becomes a vendor) seems like a contradiction in terms (although it is not entirely new to readers of this blog), so many institutions may have skipped this phase entirely. But it is at this planning stage that elements like strategic justification and complexity and impact on existing customers are assessed. Those are only a few of the considerations in the planning phase, the guidance lists 13 in all.

The due diligence and contract phases are clearly defined and also expanded, but fairly consistent with existing guidance*. And although termination is now defined as a separate phase, the expectations really haven’t changed much there either.

On-going monitoring (the traditional oversight phase) has been greatly expanded however. The original guidance had 3 oversight activities; the third party’s financial condition, its controls, and the quality of its service and support. The new guidance still has those 3…and adds 11 more. Everything from insurance coverage, to regulatory compliance, to business continuity and managing customer complaints.

But perhaps the biggest expansion of expectations in the new guidance is the banks’ responsibility to understand how the vendor manages their subcontractors. Banks are expected to…

“Evaluate the third party’s ability to assess, monitor, and mitigate risks from its use of subcontractors and to ensure that the same level of quality and controls exists no matter where the subcontractors’ operations reside.” (Bold added)

Shorter version: “Know your vendor…and your vendor’s vendor”. And this expectation impacts all phases of the risk management life-cycle. Subcontractor concerns start in the planning stage, continue through due diligence and contract considerations, add control expectations to on-going monitoring, and even impact termination considerations.

In summary, everything expands. Your pre-vendor & pre-contract due diligence expands, oversight requirements (and the associated controls) increase, and of course everything must be documented…which also expands! The original guidance listed 5 items typically contained in proper documentation, the updated guidance lists 8 items. But it’s the very first item on the list that caught my attention because it would appear to actually re-define a vendor. Originally the vendor listing was expected to consist of simply “a list of significant vendors or other third parties”, which, depending on the definition of “significant”, was a fairly short list for most institutions. Now it must consist of “a current inventory of all third-party relationships”, which leaves nothing to interpretation and expands your vendor list considerably.**

So if you are regulated by the OCC you can expect these new requirements to be incorporated into the examination process fairly soon. If not, use this as a wake-up call. I think you can expect the other federal regulators to follow suit with their own revised guidance. The OCC has just set the gold standard. Use this opportunity to get ahead of your regulator by revisiting and enhancing your vendor management program now.

* Safe Systems customers can get updated due diligence and contract checklists from their account manager.

** All vendors on the list must be risk assessed, and although the risk categories didn’t change (operational, compliance, reputation, strategic and credit) some of the risk elements did. Matt Gunn pointed out one of the more interesting changes in his recent TechComply post. I’ll cover that and others in a future post.

20 Aug 2013

Ask the Guru, From the Field Tom Hinkel 2 Comments

Ask the Guru: Vendor vs. Service Provider

Hey Guru
I recently had an FDIC examiner tell me that we needed to make a better distinction between a vendor and a service provider. His point seemed to be that by lumping them together in our vendor management program we were “over-analyzing” them. He suggested that we should be focused instead only on those few key providers that pose the greatest risk of identity theft. Our approach has always been to assess each and every vendor. Is this a new approach?

I don’t think so, although I think I know where the examiner is coming from on the vendor vs. service provider distinction. First of all, let’s understand what is meant by a “service provider”. The traditional definition of a service provider was one who provided services subject to the Bank Service Company Act (BSCA), which dates back to 1962. As defined in Section 3 of the Act, these services include:

“…check and deposit sorting and posting, computation and posting of interest and other credits and charges, preparation and mailing of checks, statements, notices, and similar items, or any other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution.”

But lately the definition has expanded way beyond the BSCA, and today almost anything you can outsource can conceivably be provided by a “service provider”. In fact according to the FDIC, the products and services provided can vary widely:

“…core processing; information and transaction processing and settlement activities that support banking functions such as lending, deposit-taking, funds transfer, fiduciary, or trading activities; Internet-related services; security monitoring; systems development and maintenance; aggregation services; digital certification services, and call centers.”

Furthermore, in a 2010 interview with BankInfoSecurity, Don Saxinger (Team Lead – IT and Operations Risk at FDIC) said this regarding what constitutes a service provider:

“We are not always so sure ourselves, to be quite honest…but, in general, I would look at it from a banking function perspective. If this is a function of the bank, where somebody is performing some service for you that is a banking function or a decision-making function, including your operations and your technology and you have outsourced it, then yes, that would be a technology service that is (BSCA) reportable.”

Finally, the Federal Reserve defines a service provider as:

“… any party, whether affiliated or not, that is permitted access to a financial institution’s customer information through the provision of services directly to the institution. For example, a processor that directly obtains, processes, stores, or transmits customer information on an institution’s behalf is its service provider. Similarly, an attorney, accountant, or consultant who performs services for a financial institution and has access to customer information is a service provider for the institution.”

And in their Guidance on Managing Outsourcing Risk…

“Service providers is broadly defined to include all entities that have entered into a contractural relationship with a financial insitiution to provide business functions or activities”

So access to customer information seems to be the common thread, not necessarily the services provided. Clearly the regulators have an expanded view of a “service provider”, and so should you. Keep doing what you’re doing. Run all providers through the same risk-ranking formula, and go from there!

One last thought…don’t get confused by different terms. According the the FDIC as far back as 2001, other terms synonymous with “service providers” include vendors, subcontractors, external service provider (ESPs) and outsourcers.

03 Aug 2012

Hot Topics Tom Hinkel 0 comment

Risk Assessing iCloud (and other online backups) – UPDATE 2, DropBox

Update 2 (8/2012) – Cloud-based storage vendor DropBox confirmed recently that a stolen employee password led to the theft of a “project document” that contained user e-mail addresses. Those addresses were then used to SPAM DropBox users. The password itself was not stolen directly from the DropBox site, but from another site the employee used. This reinforces the point I made in a previous post about LinkedIn. If you have a “go-to” password that you use frequently (and most people do) you should assume that it’s out there in the wild, and you should also assume it is now being used in dictionary attacks. So change your DropBox password, but also change all other occurrences of that password.

But passwords (and password change policies!) aside, serious questions remain about this, and other, on-line storage vendors:

Do they hold themselves to the same high information confidentiality, integrity and availability standards required of financial institutions?
If so, can they document adherence to that standard by producing a third-party report, like the SOC 2?
Will they retain and destroy information consistent with your internal data retention policies?
What happens to your data once your relationship with the vendor is terminated?
Do they have a broad and deep familiarity with the regulatory requirements of the financial industry, and are they willing and able to make changes in their service offerings necessitated by those requirements?

Any vendor that can not address these questions to your satisfaction should not be considered as a service provider for data classified any higher then “low”.

________________________________________________________

Update 1 (3/2012) – A recent article in Data Center Knowledge estimates that Amazon is using at least 454,400 servers in seven data center hubs around the globe. This emphasizes my point that large cloud providers with widely distributed data storage make it very difficult for financial institutions to satisfy the requirement to secure data in transit and storage if they don’t know exactly where the data is stored.

________________________________________________________

Apple recently introduced the iCloud service for Apple devices such as the iPhone and iPad. The free version offers 5GB of storage, and additional storage up to 50GB can be purchased. The storage can be used for anything from music to documents to email.

Since iPhones and iPads (and other mobile devices) have become ubiquitous among financial institution users, and since it is reasonable to assume that email and other documents stored on these devices (and replicated in iCloud) could contain non-public customer information, the use of this technology must be properly risk managed. But iCloud is no different than any of the other on-line backup services such as Microsoft SkyDrive, Google Docs, Carbonite, DropBox, Amazon Web Services (AWS) or our own C-Vault…if customer data is transmitted or stored anywhere outside of your protected network, the risk assessment process is always the same.

The FFIEC requires financial institutions to:

Establish and ensure compliance with policies for handling and storing information,
Ensure safe and secure disposal of sensitive media, and
Secure information in transit or transmission to third parties.

These responsibilities don’t go away when all or part of a service is outsourced. In fact, “…although outsourcing arrangements often provide a cost-effective means to support the institution’s technology needs, the ultimate responsibility and risk rests with the institution.“* So once you’ve established a strategic basis for cloud-based data storage, risk assessing outsourced products and services is basically a function of vendor management. And the vendor management process actually begins well before the vendor actually becomes a vendor, i.e. before the contract is signed. Again, the FFIEC provides guidance in this area:

Financial institutions should exercise their security responsibilities for outsourced operations through:

Appropriate due diligence in service provider research and selection,
Contractual assurances regarding security responsibilities, controls, and reporting,
Nondisclosure agreements regarding the institution’s systems and data,
Independent review of the service provider’s security though appropriate audits and tests, and
Coordination of incident response policies and contractual notification requirements.*

So how do you comply (and demonstrate compliance) with this guidance? For starters, begin your vendor management process early, right after the decision is made to implement cloud-based backup. Determine your requirements and priorities (usually listed in a formal request for proposal), such as availability, capacity, privacy/security, and price…and perform due diligence on your short list of potential providers to narrow the choice. Non-disclosure agreements would typically be exchanged at this point (or before).

Challenges & Solutions

This is where the challenges begin when considering large cloud-based providers. They aren’t likely to respond to a request for proposal (RFP), nor are they going to provide a non-disclosure agreement (NDA) beyond their standard posted privacy policy. This does not, however, relieve you from your responsibility to satisfy yourself any way you can that the vendor will still meet all of your requirements. One more challenge (and this is a big one)…since large providers may store data simultaneously in multiple locations, you don’t really know where your data is physically located. How do you satisfy the requirement to secure data in transit and storage if you don’t know where it’s going or how it gets there? Also, what happens if you decide to terminate the service? How will you validate that your data is completely removed? And what happens if the vendor sells themselves to someone else. Chances are your data was considered an asset for the purposes of valuing the transaction, and now that asset (your data) is in the hands of someone else, someone that may have a different privacy policy or may even be located in a different country.

The only possible answer to these challenges is bullet #4 above…you request, receive and review the providers financials and other third-party reviews (SOC, SAS 70, etc). Here again, large providers may not be willing to share information beyond what is already public. So the answer actually presents an additional challenge.

Practically speaking, perhaps the best way to approach this is to have a policy that classifies and restricts data stored in the cloud. Providers that can meet your privacy, security, confidentiality, availability and data integrity requirements would be approved for all data types, providers that could NOT satisfactorily meet your requirements would be restricted to storing only non-critical, non-sensitive information. Of course enforcing that policy is the final challenge…and the topic of a future post! In the meantime, if your institution is using cloud-based data storage, how are you addressing these challenges?

* Information Security Booklet – July 2006, Service Provider Oversight

10 Jul 2012

Hot Topics Tom Hinkel 0 comment

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!

12 Next →