Friend or foe? Bank regulator issues new information security exam procedures

New information security guidance from the FFIEC will keep financial institution technology risk managers busy for some time. The specific guidance will be welcomed by some but others will consider it intrusive.

it wasnt me i dont know what unsure

If you are involved with a financial institution subject to federal regulatory exams or a technology service provider that serves these institutions (like a technology start-up company), you probably have experienced the joy of preparing for or experiencing a regulatory compliance review.

And now you will have the opportunity to spend more time preparing for these reviews. A new Information Security IT Examination Handbook (“Handbook”) was just released by the Federal Financial Institutions Examination Council (FFIEC) – and it will definitely keep many CSOs occupied during the coming months.

As a financial services infosecurity professional with a to-do list that is already exceeding any realistic capacity that you may have, dealing with implementing processes, documentation and checklists to satisfy some regulator or auditor is not on your “bucket list.” Yet, as individuals and consumers who have unfortunately too often been the victim of identity theft – whether resulting from leaked confidential data maintained by a vendor who supposedly had controls or one that was negligent -- we can all appreciate the need for all businesses that maintain this important data of ours to be on the same page as to what it means to protect our data.

In nonregulated industries that we patronize, consumers are subject to the whims of management and their risk appetite to survive a lawsuit should a breach occur. In regulated industries such as banking, federal and state regulators conduct periodic exams to help ensure the resiliency and reputation of our financial system. The handbook contains the audit program that financial service regulators will use to conduct regulatory compliance examinations. The handbook also contains excellent reference and supporting guidance that can be used by other industries interested in improving their information security program. So from a consumer perspective, I both respect and appreciate what the financial regulators are trying to do.

[ RELATED: NY regulation aims to raise bank security standards  ]

Those favoring practical experience over checklist security will not be happy. Most information security professionals agree that practical experience and judgment far outweigh checklist security in protecting organizations. Some would argue that diverting tight resources into procedural or documenting information security controls can actually hamper protection efforts. And in some aspects this argument make sense.

The new handbook is “heavy” with requirements to document and provide evidence of control procedures used to manage the bank’s (or financial services company’s) information security effort. This will surely frustrate checklist security opponents. And for many requirements, specific expectations are provided that the bank would be expected to have to achieve the requirements objectives.

Sampling of areas that will require new or renewed attention

Based on my experience working with bank information security and internal audit departments of all sizes, many bankers (and their technology service providers) will find the following sample of new or “reemphasized” guidance supporting “opportunities” to reconsider their regulatory compliance strategies:

  • Gage the bank’s culture and attitude toward security by determining how security is factored into the development and introduction of new products and software. Many risk management and audit professionals will champion this requirement as a way to manage the risks resulting from end user departments circumventing information security and related risk management involvement in strategic decision making and software selection.  
  • Adapt a vulnerability risk acceptance process that identifies the name of the employee accountable for accepting the risk.
  • Develop, maintain and update a repository of threat information (note: this could be a challenge for some smaller banks who perform periodic rather than ongoing risk assessments).
  • Classify data based on both sensitivity and criticality (note: many banks primarily considered sensitivity to prioritize (and limit) their protection efforts on assets having nonpublic personal information, but will now need to expand the number of assets requiring “heightened” protection strategies.
  • Apply the same standard of care in accepting vendor-developed applications into production as if the application was developed in-house. This could challenge those banks that currently rely on the reputation of the vendor to ensure that appropriate application security is incorporated into the software and functioning properly.
  • Continue to enhance board-level reporting including providing specific board member performance expectations and management reporting. This would also need to include more robust risk reporting that highlights changes in the threat landscape and inherent risk. Appropriate metrics will need to be designed and reported on to fulfill this responsibility.

Bottom Line – A friend as long as you provide me with some flexibility

Nobody likes to be told what to do. For those subject to the new handbook, implementing the requirements and being subjected to periodic examinations to determine the effectiveness of the implementations will definitely challenge their information security programs. Yet, this nuisance, and yes I agree, potential career killer, can also provide tremendous opportunity.

By specifying expectations, risk management professionals have a better idea of what the regulators are looking for. This will also provide these professionals with the opportunity to engage the board and management to better address cybersecurity risk. Hopefully, the regulators will provide these professionals with the flexibility to implement what makes sense for their environment and avoid holding all organizations to a one size fits all approach.

Copyright © 2016 IDG Communications, Inc.

Microsoft's very bad year for security: A timeline