Management, compliance & auditing

How to comply with the GLBA Act — 10 Steps

Brian Hickey
August 2, 2018 by
Brian Hickey

The Gramm-Leach-Bliley Act is a U.S. federal law created to control how financial institutions deal with a consumer's non-public personal information (NPI). This is information that a financial institution collects when providing a financial product or service that can identify an individual and that isn't otherwise publicly available.

The Act has three main elements:

  1. The Privacy Rule, which regulates the collection and use of NPI
  2. The Safeguards Rule, which requires financial institutions to implement a security program to protect NPI
  3. Pretexting provisions, which prohibits access to NPI under false pretense

It's beyond this article to provide a detailed description of the Act, but readers can learn more about the general provisions, privacy rule and safeguards rule by following the links under the Sources heading.

From a compliance point of view, the principles that need to be met are:

  • Ensuring the security and confidentiality of NPI
  • Protecting against unauthorized access which could cause substantial harm or inconvenience to any customer
  • Protecting against any threats which might affect the security or integrity of NPI

This article recommends a series of steps that will ensure these principles are met and GLBA compliance is achieved.

10 steps to compliance

1. Understand the regulation and how it applies to you

Review the Act, with help from your legal team when needed, to make sure you understand the scope and how it applies to your company. This might seem a very basic first step, but it will ensure you have a firm foundation for designing and implementing your compliance program.

Use the review to identify the main implications that need to be considered in detail as you work through the remaining steps.

2. Conduct a risk assessment

The goals of the risk assessment are to catalog the systems used for managing NPI and to identify threats and vulnerabilities that put the information at risk.

External examiners, testing compliance against GLBA, will look for evidence of a robust risk assessment and the use of proper controls to mitigate any risks, so this process is central to your compliance program.

The FFIEC Cybersecurity Assessment Tool can help plan and perform the risk assessment. Prepare an inventory of all systems that store, process or transmit NPI — for example, mail servers, network devices, PCs and laptops. To help decide if a system is in scope, ask yourself: if the system was breached, could customer information be stolen or changed? Be cautious and, if in doubt, include the system on the inventory to stop anything from being missed.

Each system then needs to be evaluated for threats and vulnerabilities. There are various publicly available lists of vulnerabilities that provide useful input, and working groups drawn from business and IT teams would be the best people to help with the evaluation.

3. Ensure effective controls are in place to mitigate risks

It's possible your existing technical, physical and management control framework will mitigate the risks found by the risk assessment, but it's more likely that existing controls will have to be improved or new controls applied. Again, there are lists of controls that can help you decide what is most appropriate.

Examiners will expect to see evidence that all vulnerabilities and threats are matched with an appropriate control, so make it easy for them by creating a simple table, annotated with the rationale for your selection.

As an additional check, consider using a third party to perform network scans and penetration testing to measure control effectiveness.

4. Protect yourself from the insider threat

The insider threat – employees who inadvertently or maliciously compromise the company – is the biggest threat to most organizations and deserves extra attention when developing your compliance program.

Use pre-employment recruitment checks to filter out security risks, and employment contracts should place the onus on employees to follow security policies and procedures.

Role-based security restricts NPI use to those that need it and can be easily changed if the employee changes role or leaves the company.

There should be regular awareness communications and a training program to re-enforce security policies and keep everyone up to date with any new threats. Since GLBA requires action to prevent pretexting, this can be built into the training program using modules that focus on social engineering, BEC and similar types of threat.

Tools, such as InfoSec Institute's SecurityIQ, make the process of organizing and delivering training straightforward. You can create personalized training plans, run phishing simulations, link learner assessment tools to training plans and monitor progress across the company using customizable dashboards.

5. Service providers need to be GLBA-compliant

If you use a service provider for NPI storage or processing, or if you rely on their service for the integrity or availability of NPI, they are in scope for GLBA and you must ensure they have appropriate safeguards in place.

Like you, they should have a written information security plan (WISP) and an appointed owner for its maintenance and implementation. Your supply contract should also commit them to maintaining compliance.

6. Confirm you're meeting the privacy rule requirements

You must provide customers with a "clear and conspicuous" privacy notice describing what NPI is collected and for what purpose, and customers should be allowed to opt out of information sharing with third parties.

Additionally, an annual privacy disclosure needs to be provided to customers, although this rule was revised in 2015 and is now only required if certain conditions aren't met.

Systems and business processes need to support these requirements and, since the privacy notice should provide an accurate description of your current policies and practices for protecting NPI, you need to make sure the information is the same in both documents.

7. Update your DR and BCP plans

GLBA requires an incident response plan to be in place, and if you include it in your IT disaster-recovery (DR) or business continuity (BCP) plans, you can easily show examiners how the company will respond to the business disruption caused by a security breach such as data theft or a denial-of-service attack.

All three plans should be tested at least annually and updated as required.

8. Prepare a written information security plan

The Safeguards Rule requires companies to develop a written information-security plan (WISP) that describes administrative, technical and physical safeguards that will protect NPI.

It doesn't have to be lengthy – GLBA states it should be appropriate to the business size, the nature and scope of its activities, and the sensitivity of the customer information at issue – but it should be current, correct and formally approved by the Board. The steps we describe above make up the contents of the WISP.

In addition, an owner responsible for WISP maintenance and implementation should be appointed.

9. Report to the board

GBLA also requires an annual report to be provided to the Board and its receipt recorded in meeting minutes as evidence of their commitment in meeting the Act. Contents should include:

  • The status of the information security program
  • Risk assessment summary and any material issues discovered
  • Risk management and control decisions
  • Service provider arrangements
  • Any security violations and actions taken in response

10. Review, revise and improve

The WISP, and related processes, should be revised at least annually and more frequently if there has been significant business change. Feedback from employees, new threats and lessons learned from any breaches or near-misses are all valuable input.

Controls should be tested regularly, and training programs revised and repeated throughout the year.

Finally, if the whole compliance process seems a bit daunting, consider using a software tool to take away some of the burden.


Brian Hickey
Brian Hickey

Originally a software engineer, Brian Hickey has worked with enterprise technology since the early 80s and held roles in sales, marketing and project management. Most recently he led large scale implementations in financial services where security and compliance were critical components of the delivered solution.