FFIEC Update: Ensuring Resiliency of Outsourced Technology Services

Dollar bill in binary code
Earlier this month the Federal Financial Institutions Examination Council (FFIEC) released a new appendix to its Information Technology Examination Handbook: "Strengthening the Resilience of Outsourced Technology Services."

Outsourcing technology services often makes good business sense for financial services institutions. It allows them to benefit from outside expertise and alleviate internal workloads, increasing their professionalism and efficiency.

The FFIEC acknowledges this fact with one caveat: Your organization's management and board are still responsible for making sure "outsourced activities are conducted in a safe and sound manner." This responsibility entails making sure the third-party provider provides an adequate level of resiliency so as not to disrupt key processes in the financial services organization.

Below are a few key guidelines from the FFIEC document.

Address Risk

Because your firm is ultimately still responsible for outsourcing business practices, be aware of the risk factors you face when working with a third-party technology services provider and establish controls to mitigate those risks. To assess the level of risk, perform due diligence into the provider’s business continuity program (BCP), establish clear guidelines in your contract with the provider and continually monitor the vendor’s services.

Be Aware of the Provider's Scalability

Organizations rely on technology for critical processes more than ever before. Any outage of critical technology can be detrimental to your business. For this reason, you need to be familiar with a service provider’s ability to respond to a few types of scenarios:

  • A widespread physical disaster or cyber threat in which multiple organizations are affected and need continued service.
  • An isolated incident affecting a single service provider location, which in turn affects several firms.
  • Other continuity issues, such as financial distress.

In each of these scenarios, assess the service provider’s ability to meet your recovery time objectives (RTOs) and recovery point objectives (RPOs.). Prepare contingency plans to ensure the continuity of key applications.

Make Sure the Service Provider Has a Business Continuity Plan

A service provider needs to have identified single points of failure and created a comprehensive business continuity plan that addresses restoration of key services. Being familiar with the provisions of a service provider’s BCP will allow you to make adequate preparations in your own BCP.

Involve the Provider in Testing

Services provided by third parties should be included in regular business continuity testing, especially if the services provided are critical business functions.

The FFIEC recommends testing in conjunction with the service provider. These tests have a two-fold benefit in that they demonstrate both parties’ ability to recover within the designated time frames and to meet contractual obligations. However, some third parties service hundreds of organizations and as such might not be able to participate in one-on-one tests. In these cases, you should still ensure that you’re familiar with the provider’s testing scope, frequency and remediation activities.

Prepare for Cyber Threats

With the predominance of virtualized infrastructures, you need to adequately prepare for cyber threats. The FFIEC recommends preparing incident response strategies for the following types of threats:

  • Malware
  • Insider threats
  • Data systems destruction and corruption
  • Communications system disruption
  • Simultaneous attacks on the firm and service provider
  • Cyber attacks

To read the full appendix, visit ithandbook.ffiec.gov.

[Webinar Recap] I Need A Compliant Business Continuity Strategy. Now What?

Intro slide for webinar presentation
Today organizations in regulated industries know that to remain compliant with industry and federal regulations, they need a well-rounded business continuity strategy. Unfortunately, developing a strategy can be a challenge, which is why during our webinar with DRJ earlier this week, Rentsys Senior Manager Brandon Tanner offered tips for getting started with compliance.

After the show, participants had several great questions for Brandon, so we’ve featured a few highlights below.

Q: How do I know which recovery time objectives (RTOs) and recovery point objectives (RPOs) are applicable to my organization?
A: I would start with asking, “What does our business impact analysis say today? What are our established RTOs and RPOs?”

Then I’d go and I take a look at the regulatory bodies that are tied to your particular organization and industry and look to identify any areas where you’re told how to classify your data (for instance, critical or urgent) and given timelines associated with those. Also consult with some of your peers that may have information on that piece.

Finally you’ll want to look at service level agreements (SLAs) that your organization has tied to service delivery.

Those three things allow you to come to a reasoned framework for determining the appropriate RTOs and RPOs. If there’s a gap, you have a tool for discussing how to prioritize each of those requirements. You’ll want to meet the most aggressive requirement.

Q: Who needs to have a SOC 2 and how is it different from a business associate agreement (BAA)?
A: Any critical vendor you’re dependent on and that is tied to your compliance requirements and service level agreements should have that SOC 2 report because you need to have visibility into what they’re doing.

A BAA is an agreement between the organizations. It does tie into HIPAA and how the data you deal with is protected, but what’s to validate that what’s in the BAA is actually happening? Now, obviously if the agreement has been signed and something does happen, there’s liability associated with it, but in a SOC 2 there’s actually validation from third parties. If you’re a healthcare organization, I’d require a SOC 2 and a BAA.

Q: What is the best approach to getting critical third-party providers to embrace BC compliance?
A: If you’ve got critical third-party vendors that are resistant to BC compliance, I would look for alternative vendors. But I would also say if you’re struggling there, it’s an executive-level decision.

If your business arrangements or compliance requirements are tied to that vendor embracing business continuity, whoever manages the business relationship should have those requirements written into the documentation. There should be a service level agreement tied to it and expectations that they will comply to those standards. The SLA needs to be tested, so the vendor needs to be able to prove to your organization that they have validated the requirements. Once you get that far, now you’re most likely talking again about the SOC 2.

To see the complete webinar, get it on demand here.

Where in the World Is Your Data?

World map
Recently The Internet Archive resurrected several nostalgic computer games, including the 1980s-era “Where in the World Is Carmen Sandiego?” In the game, players join the ACME Detective Agency to track down a troupe of thieving villains led by the elusive Carmen Sandiego.

The only way players can stop Carmen and her thieves is to use their geography knowledge to gather clues and pinpoint the crooks’ locations. If players get a location wrong, they have to retrace their steps and try again, all the while losing precious time.

In this respect, disaster recovery (DR) has something in common with “Where in the World Is Carmen Sandiego?” If backups are vaulted in the wrong geographic location, you limit your ability to rebound from an incident within the necessary recovery time objectives (RTOs). 

Why Is Location Important?

The goal of strategically selecting where your data will be vaulted is to minimize organizational risk as much as possible. To achieve this goal, you need to solve for two separate RTOs:

  • Operational issues that are specific to your individual environment (e.g., a server outage)
  • Regional disasters

An operational issue would most likely have a lower RTO and would allow for local data vaulting. A regional disaster would either have an equal or less aggressive RTO, because events affecting several providers in a given area are viewed differently than an event affecting a single entity only. Unfortunately, many organizations focus solely on addressing operational RTOs in the DR planning process, which is catastrophic in a widespread event.

Where Should Data Be Stored?

The important thing is to have your data as close as possible, but far enough away to ensure there’s not a common risk between geographies. During Hurricane Sandy, for example, organizations with production operations in New York and DR in New Jersey went down.

That doesn't mean they should put their production in New York and move DR to Washington State, though. The further apart locations are, the more challenges exist from an availability and recovery perspective — not to mention cost and latency (affecting communications, user experience, etc.).

What About Data Stored in the Cloud?

When working with cloud providers, it’s important to be aware of where their back-end data centers are located — some providers have locations all over the world, whereas others have strategically placed facilities in the U.S. only. (If your business is subject to industry or federal regulations that require data to remain stateside, you’ll want to avoid your data being sent overseas.)

However, one of the benefits of the cloud is that it allows you to achieve a solution that addresses both operational and DR RTOs. Cloud providers have service level agreements that both IT and executive management can understand, as well as industry-specific compliance documentation (depending on the cloud), allowing the business to dictate risk aversion or assumption.

While pinpointing the best geographic locations for your data might not be as fun as tracking a world-class villain, it’s a key part of the DR planning process that can save you time when you need it most.

Popular Posts