GLBA Compliance: How to Avoid Common Traps

Risk Assessment, Vendor Management Are Key Examination Trends Linda McGlasson • July 7, 2008

Editor's Note: This is the first in a series of stories that will appear throughout July, focusing on GLBA compliance. Future installments will showcase GLBA compliance elements such as Board of Director education, Information Security programs, GLBA privacy decisions, Incident response plans, and vendor management programs.

The Financial Modernization Act of 1999, AKA the Gramm-Leach-Bliley Act, or just plain GLBA.

However you know it, financial institutions now have had several years of regulatory oversight and examination on it, but some are still struggling to meet the regulation's myriad list of requirements, which include provisions to protect consumers' personal financial information held by financial institutions.

To gauge where financial institutions are in their compliance efforts, we spoke with information security service providers and GLBA compliance experts for their insights on:

What are examiners focusing on re: GLBA?

Where are institutions most commonly falling short?

What are the most frequently asked questions re: GLBA compliance?

The Matter of Risk
Specific components of GLBA include The Safeguards Rule, which requires all financial institutions to design, implement and maintain safeguards to protect customer information. The Safeguards Rule mandates that financial institutions develop a written information security plan that describes how the company is prepared for, and plans to continue to protect clients' nonpublic personal information. The plan should include:

Denote at least one employee to manage the safeguards;

Construct a thorough risk assessment on each department handling the nonpublic information;

Develop, monitor and test a program to secure the information;

Change safeguards as needed with the changes in how information is collected, stored and used.

This rule is intended to ensure what financial institutions already should be doing - protecting their clients' information. It makes financial institutions take a closer look at how they manage private data and to do a risk analysis on their current processes. (GLBA Bill; FDIC Exam Procedures)

Financial institutions' compliance with GLBA has made significant movement toward a mature model -- even during uncertain economic times, says David Schneier, Director of Professional Services at Icons Inc., a New Jersey-based information security services firm.

"As part of the lifecycle of regulatory compliance, enforcement matures and shifts focus, addressing those areas that historically have been overlooked or whose significance has changed due to shifting business and world events," Schneier says. For GLBA, these shifts have resulted in examiners placing greater scrutiny on core activities such as vendor management and business continuity planning. "There's also been a noticeable increase in comments regarding enterprise/operational risk management activities," Schneier notes.

Not all financial institutions are doing GLBA risk assessments properly, says Ken Stasiak, CEO of Secure State, a Cleveland, OH-based information security services firm. "We are generally seeing that financial institutions haven't been performing comprehensive risk assessments, which include process flowing of applications," Stasiak says. "As a result, critical components such as storing, processing or transiting customer information are being overlooked."

One area that needs further emphasis at many institutions is making a GLBA assessment's focus risk-based, says Nathan Johns, Executive with Crowe Chizek and Company LLC, and former Chief of Information Technology at the FDIC. "If an institution doesn't make its assessment risk-based (if they don't identify where the data is and what the controls around that data should be), the regulators make the assumption that data is everywhere," Johns says.

He recalls one client whose regulator said to go down to the individual record level and check those files in each database to see if they were encrypted. "If you let the regulators make that decision for you, then the burden of becoming compliant with GLBA becomes overbearing," Johns says. "You have to demonstrate that you have identified where the information is, through a risk assessment, you have identified controls that you already have in place, and you've lumped that information in areas where appropriate controls allow only appropriate people to get access to it."

Common Questions
"What is my examiner going to be looking for in my institution?" That's the big question every banking/security leader asks.

Schneier says he sees institutions generally looking for definition and direction regarding Document of Resolution (DoR) and Memorandum of Understanding (MoU) issues, and how to best resolve them. "However, since several recent bulletins and issued guidance, I'm spending more time discussing vendor management and application security than in the past," he notes, adding that questions shift to focus on the most recent information published.

Johns is also hearing the same questions on recent guidance. "The most common one I hear is 'It's my vendor; what can I do about this vendor?'"

In terms of getting a vendor to become GLBA compliant, Johns advises institutions that they can't force them to place controls on their systems. Though he notes, "You can through your contract agreements with the vendor, make it part of the agreement that you monitor their levels of compliance. This gives you leverage to get out of a bad relationship if one exists. If you have in your contract, then you can monitor either through some independent review, or if needed, do it yourself by doing an assessment."

GLBA Compliance Markers
How does an institution know that they're on the right track toward GLBA compliance? Schneier says the most obvious signs of a strong compliance program begin with defined roles and responsibilities. He looks to see if compliance is a "top-down strategy that is connected directly to the Board of Directors." The existence of a primary compliance person in charge of the many required activities is another marker. Having an Information Security Officer (ISO) working on core compliance activities is another key compliance marker, he says.

Other key markers:

How comprehensive and available are key policy/procedure documents (primary is the Information Security Policy)?

Does the documentation reflect accurately on the institution and its culture, or is it a stand-alone artifact use only to try and ward off examiners and auditors?

Is there a thorough risk assessment available, and was it conducted recently?

Are current compliance activities aligned against the risk assessment?

How solid is the vendor management program and is it maintained?

Is there a BCP that includes the entire institutions (not just IT), and was it designed and/or updated to address a recent business impact analysis?

Is there an Incident Response plan that staff has been trained to use?

Have any of the core programs/procedures been properly tested?

"Signs of an institution that may be at risk are incomplete or wrong answers to any of these questions," Schneier explains. Not knowing who is responsible for the core compliance activities is almost always an indicator that there are issues present. "Incomplete, outdated or missing documentation is also a concern. Procedures that have either never been validated or haven't been tested recently are problem indicators as well," he observes. When there are very obvious issues, such as improperly designed IT architecture or poor physical security, Schneier adds, "It's rare that those are isolated problems."