Bank Information Security Program: GLBA Safeguards Rule Compliance

This post covers the written information security program — what it must contain, who approves it, and what has to be reported. Our companion post on bank cybersecurity covers the threats and the technical controls. The two are related and separate: the program is the governance artifact, and controls are what it governs.

Which Standard Actually Applies

Start here, because the confusion is widespread and consequential.

The Gramm-Leach-Bliley Act directed regulators to establish standards for safeguarding customer information. Two different implementations followed:

For banks, savings associations, and credit unions, the federal banking agencies issued interagency guidelines establishing information security standards, appended to their respective regulations. This is what applies to an insured depository institution, and it is what examiners assess against.

For non-bank financial institutions — mortgage brokers, finance companies, auto dealers arranging financing, tax preparers, and others — the FTC's Safeguards Rule applies. It was substantially amended, adding prescriptive requirements including a qualified individual, penetration testing, multifactor authentication, encryption, and specific reporting.

Why this matters practically: articles, vendors, and consultants frequently describe the FTC rule's prescriptive requirements as though they applied to banks. Some of those requirements are good practice and several map onto supervisory expectations — but a bank's obligation runs through the interagency guidelines, and an institution building a program to satisfy the wrong standard is likely to over-build in some areas and miss expectations in others.

A bank with non-bank affiliates or subsidiaries may have both standards in scope across the organization, which is worth confirming rather than assuming.

The Required Elements

The interagency guidelines require each institution to implement a comprehensive written information security program appropriate to its size and complexity, the nature and scope of its activities, and the sensitivity of the customer information it handles.

The program must be designed to:

• Ensure the security and confidentiality of customer information
• Protect against anticipated threats or hazards to the security or integrity of that information
• Protect against unauthorized access to or use of the information that could result in substantial harm or inconvenience to a customer

And it must include these components:

Board involvement. The board or a designated committee must approve the written program and oversee its development, implementation, and maintenance. This is explicit, and the approval should be minuted.

Risk assessment. Identify reasonably foreseeable internal and external threats, assess the likelihood and potential damage, and assess the sufficiency of policies, procedures, and other arrangements in place to control the risks.

Manage and control risk. Design and implement controls to address the identified risks, and train staff to implement the program.

Oversee service provider arrangements. Exercise appropriate due diligence in selecting providers, require them by contract to implement appropriate measures, and where indicated by the risk assessment, monitor them.

Adjust the program in light of relevant changes in technology, the sensitivity of information, internal or external threats, and changes to the institution's own business arrangements.

Report to the board. At least annually, describing the overall status of the program and compliance with the guidelines.

What the Written Program Should Contain

Institutions frequently have policies and no program — a collection of documents with no statement that ties them to the required elements.

A defensible written program states:

• Its scope, including which entities, systems, and information types are covered
• The definition of customer information used
• Roles and responsibilities, including who owns the program
• How the risk assessment is performed, by whom, and how often
• The control framework, by category — access, encryption, network, endpoint, physical, personnel, and disposal
• Service provider oversight, referencing the third-party risk program rather than duplicating it
• Incident response and the customer notification decision process
• Training requirements by role
• Testing and independent assessment arrangements
• How and when the program is adjusted
• Board approval and reporting arrangements

The test worth applying: can someone map each required element to a specific section of the program document? If not, the institution has security documentation rather than a program, and an examiner working through the guidelines will find the gap quickly.

The Risk Assessment

This is the element most often thin, and it drives everything else.

It should identify the institution's information assets and where customer information resides — including in systems nobody inventoried, at service providers, and in paper. Then identify threats, assess likelihood and potential harm, evaluate existing controls, and state residual risk.

Two recurring weaknesses. Scope gaps: institutions assess the core systems and omit peripheral ones, third-party held data, and physical records. And staleness: an assessment that has not changed in three years, while the institution adopted new technology and new vendors, describes a different bank.

The Annual Board Report

Required, specific, and usually generic.

A report that satisfies the requirement and is worth the board's time covers: the status of the program; the results of testing and independent assessment; risk assessment changes; security incidents and management's response; service provider oversight status; policy or control changes made during the year; and recommendations for changes to the program.

The item most often omitted is incidents. A report describing a program without mentioning what actually happened during the year is not a status report.

Service Provider Oversight

The guidelines require due diligence in selection, contractual obligations, and — where indicated by risk — monitoring. This is the same discipline covered in the third-party risk post, and the program should reference that rather than maintaining a parallel process.

Two specifics the guidelines make explicit: the requirement to contractually require providers to implement appropriate safeguards, and the expectation that monitoring is proportional to the risk the provider presents.

Response Program and Customer Notification

Interagency guidance addresses response programs for unauthorized access to customer information, including assessing the incident, containing it, notifying the primary federal regulator, filing a SAR where appropriate, and notifying affected customers where misuse of their information has occurred or is reasonably possible.

This sits alongside — and is distinct from — the computer-security incident notification rule requiring regulator notification within 36 hours of determining a notification incident has occurred, and alongside state breach notification laws with their own triggers and timelines. Three separate tracks, three separate assessments, and institutions conflate them.

Structured coverage is available through the Certificate in Cybersecurity, Cybersecurity Management, our cyber security training catalog, and Privacy/Information Sharing.

Where Programs Fail Examination

• No single written program document, only scattered policies
• Required elements not mappable to program sections
• Board approval not minuted, or approval of a document the board never discussed
• Risk assessment scope gaps — peripheral systems, vendor-held data, paper records
• Risk assessment stale relative to adopted technology and onboarded vendors
• Annual board report generic, omitting incidents and testing results
• Training not role-specific, or not documented
• Service provider contracts lacking security obligations
• No evidence that access reviews, testing, or incident response exercises occurred
• Program never adjusted, despite changes the guidelines specifically require adjustment for

The last two are the same failure that recurs across every compliance domain in this series: the work is done and not recorded, or the document exists and was never revisited.

Defining Customer Information Correctly

The program's scope depends on a definition institutions rarely examine, and getting it wrong produces gaps that no amount of control investment fixes.

Customer information under the guidelines means nonpublic personal information about a customer of the institution, in any form — electronic, paper, or otherwise — held by or on behalf of the institution. Three parts of that definition do real work.

"In any form." Paper records are in scope. So are records on portable media, in email, in file shares, on laptops, and in printers' memory. Programs built entirely around the core system and the network omit a substantial share of where customer information actually resides.

"Held by or on behalf of." Data at service providers is in scope, which is why service provider oversight is a required program element rather than an adjacent concern. An institution that has mapped its own systems and not its vendors' has mapped part of the perimeter.

"Customer" has a specific meaning distinct from consumer, and the distinction matters for the related privacy rules. It is worth ensuring the program and the privacy notice practice use the terms consistently.

Two practical exercises follow from this. Run a data inventory that starts with the information rather than with the systems — ask where a loan application exists, in every form, from receipt to retention, and the answer will include locations the systems inventory missed. And include disposal, since the guidelines' concern with unauthorized access extends to records being discarded; a shredding practice that is informal is a gap in a program that is otherwise sound.

The broader point is that scope failures are the most expensive kind, because every control decision downstream inherits them. An institution that assesses risk against an incomplete inventory has produced a rigorous analysis of part of its exposure.

A note on proportionality, since the guidelines state it explicitly. The program must be appropriate to the institution's size and complexity, the nature and scope of its activities, and the sensitivity of the information it handles — which means a small community bank is not expected to implement the program a large institution would. What the guidelines do not scale is the requirement that each element exist and that the board approve and oversee it. A three-page program at a small institution, with a real risk assessment, defined controls, documented training, and an annual report that names actual incidents, satisfies the standard more convincingly than a forty-page document assembled from a template describing controls the institution does not operate. Examiners read for fit between the program and the institution, and a program that overstates capability is a worse position than one that is modest and accurate.

Frequently Asked Questions

Does the FTC Safeguards Rule apply to banks?

No. Banks, savings associations, and credit unions are subject to the interagency guidelines establishing information security standards issued by the federal banking agencies under GLBA. The FTC Safeguards Rule applies to non-bank financial institutions such as mortgage brokers, finance companies, and tax preparers. Articles and vendors frequently describe the FTC rule's prescriptive requirements as though they bound banks.

What must a bank's information security program include?

Board approval and oversight, a risk assessment identifying foreseeable threats and evaluating existing controls, controls designed to manage the identified risks, staff training, service provider oversight through due diligence and contractual requirements, adjustment of the program as technology and threats change, and at least annual reporting to the board on program status.

Who must approve the information security program?

The board or a designated committee, which must also oversee the program's development, implementation, and maintenance. The approval should be minuted, and the minute should reflect discussion rather than receipt — approving a document the board never examined satisfies the form and not the requirement.

What belongs in the annual board report?

Program status, results of testing and independent assessment, changes to the risk assessment, security incidents and management's response, service provider oversight status, policy and control changes made during the year, and recommendations. Incidents are the element most often omitted, and a report describing a program without saying what happened is not a status report.

How many notification obligations can one incident trigger?

Potentially three separate tracks: notification to the primary federal regulator under the computer-security incident notification rule, generally within 36 hours of determining a notification incident occurred; customer notification under the interagency response program guidance where misuse has occurred or is reasonably possible; and state breach notification laws with their own triggers and timelines. Each requires its own assessment.

What is the most common examination finding on information security programs?

That the work was performed and never recorded — no evidence that access reviews occurred, that the incident response plan was tested, or that the program was adjusted after the institution adopted new technology. Close behind is a set of scattered policies with no single written program that maps to the required elements.