Information Security & Privacy Regulatory Compliance: The Gramm-Leach-Bliley Act

As any banker will tell us, theirs is a heavily regulated industry.  With regulations from A to Z and then some, banks spend up to two out of every three operational dollars on meeting regulatory requirements.   Think of it this way: banks and credit unions are a national resource with regulatory safeguards that virtually require them to be able to survive a nuclear attack.  With that as our yardstick, how does our business continuity plan compare?

So what does all that regulation buy us?   Well actually banks and credit unions (CU) have excellent security controls when it comes to managing our data.  This is primarily due to an act that came about at the start of this century: the Gramm-Leach-Bliley Act which was signed into law in 1999 by President Clinton.  This act, among other things, requires banks and CUs to secure non public information and not sell or transfer it to other organizations (with unfortunately, many exceptions).  That was all well and good, but banks and CUs at that time were into banking not information technology, and they therefore had very limited ideas on how to protect the information they suddenly found themselves the custodian (as opposed to the owner) of.   Also, information technology was changing, banks and CUs were opening up more exposure points for business reasons than they could manage with their core system expertise.

Guidance’s were issued, revised and reissued until a strategy came together that could reasonably assure the protection of the financial industries key customer data.   This strategy in fact has become a standard for the security industry best practice when it comes to information security.  That is where the rest of us come in.  Regardless if we work for a high-tech firm or a non profit or a retail establishment we all can benefit from the hard work put in by our financial institutions.  The strategy is not secret; in fact it is published by the Federal Financial Institutions Examination Council as IT booklets.

See: http://www.ffiec.gov/ffiecinfobase/html_pages/it_01.html#infosec

As a certified information systems security professional and a certified information security manager I find these security guidance’s to be both comprehensive and effective.  They have a proven track record of securing banks, CUs, and other financial institutions against external and internal malicious intent and accidental leakage.  So instead of designing a security program from scratch we could just use one that is already used by a $2.5 Trillion dollar industry.

The strategy has some excellent metrics (measurements used to ensure the plan is in place) and has an outline that would be familiar to anyone who uses PCI, NIST, SOX or other information security guidance’s.   However where SOX and PCI are limited to one aspect of the business, the FFIEC strategy is designed to cover all aspects. 

What follows is an outline of the FFIEC strategy as derived from the GLBA guidance’s for an effective information security program;

              I.      Involve the Board of Directors:  Security must be integral to the business or it will not be implemented effectively.  The regulators have found that without executive management support it is not possible to put together an information security program that will protect key assets.  Security projects tend to ‘wither on the vine’ if key executives are not personally responsible for their success.  If the company does not have a Board of Directors than the executive steering committee would be the appropriate place to charter the information security program.

           II.      Assess the Risk:  One can’t protect the information if one does not know where it is, how it is being processed, transferred, stored, destroyed and reported.   A process known as an information security risk assessment is the key towards creating an effective information security program.

         III.     Test the controls:  The information security risk assessment as part of its process identifies those controls the company uses to secure key intellectual property or non public information.   Once those controls are identified they need to be tested on a regular basis to ensure they are still in place.   From an executive management perspective it is permissible to allow those who implement the control to test the control, however the Board of Directors should bring in an independent audit team to test the controls at least annually.

        IV.     Training:  Internal training of employees as to the nature of the information security program and the sensitivity of the information assets has a high cost reward benefit and is considered essential for an effective program.

           V.    Service Provider Monitoring:  It does us no good if our information is lost by some companies servicing us, ensure the contracts contain effective security language and that those who service us meet or exceed our stringencies in the security policies.

        VI.     Adjust:  When we buy or merge with another company or add another program, a website for example, we should adjust the information security risk assessment as appropriate.  This is real time, not after the fact, we should identify the risks of implementing something before it is implemented.

      VII.    Report:  Results of the effectiveness of the information security program need to go back to the board of directors.   On a regular basis the companies assigned information security officer needs to inform the board of the successes and gaps in the information security program so that they can assign appropriate resources as needed.

Now, of course, each step here requires some effort on the part of management, and each represents a change in the company processes.  However if we are at risk of losing valuable information or we are the custodians of some other companies intellectual property we must come up with an information security program to prove our due diligence.   Why not use one that has been tested by the nation’s financial institutions?

By John Barchie, Senior Information Security Governance Fellow

Back to Top