Bank Systems & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News & Commentary

01:09 PM
Deena Coffman, IDT911 Consulting
Deena Coffman, IDT911 Consulting

What Constitutes a Data Breach for Banks?

Many employees, even those who are technically savvy, do not recognize as reportable events the situations that commonly result in a data breach.

When the media reports on data breach events, the conversation usually shifts one of two ways: toward the abstract—the laws, the theories, the consequences—or to the wonkishly technical—the nuts and bolts of SQL injections, DDoS and forensic investigations. The reality is that many data breach events, even the most common, are not evaluated technically or theoretically because they are not initially identified and reported.

Through our work coaching businesses that range in size from small to medium-sized companies to large institutions, we have found that many employees, even those who are technically savvy, do not recognize as reportable events the situations that commonly result in a data breach.

Consider these scenarios:

  • An employee writes sensitive client information on a sticky note and posts it on his or her PC as a reminder. That’s a data breach.
  • A company laptop containing protected information is lost, misplaced or stolen. That’s a data breach
  • An invoice or HR email with personally identifiable information is mailed or sent via email to the wrong person. That’s a data breach.
  • An FTP site containing protected data is accessed by the wrong client. That’s a data breach.
  • Physical documents containing protected information are disposed of in an insecure fashion. That’s a data breach.
  • Your website host—or another outside service provider that stores, transmits or manages your clients’ or employees’ protected information—is hacked. That may be a data breach and should at least be evaluated by legal and/or compliance./li>

These events often are not the sophisticated cyber attacks that make headlines. They usually involve good employees who make honest mistakes because they haven’t been taught to see data as an asset to be protected. So what’s your next move? How do you train employees to be attuned to recognize and avoid events that create exposure to a data breach?

Assess your data breach exposure points

Inventory your environment and processes to find common activities, documents and storage locations that are components of a data breach. For example, if you work with clients or vendors to exchange protected data via FTP, or if employees or contractors are able to send protected information via email, identify those particular activities and data repositories for additional quality control, security, audit and training measures. The processes and data sets that are not high-risk can then be handled with lower priority, and they won't consume valuable investment and attention.

Institute quality control or additional security for high-risk points.

For those functions, documents and data sets identified as sensitive or protected, institute additional procedures to reduce your potential for error or exposure. Provide specific direction on the level of importance, the protocol for avoiding errors and how to identify and respond to an incident that may produce a data breach.

Train in context

Communicate regularly (not just annually) to the employees that work in the areas identified as possessing an inherent risk of a data breach. Provide training not just on theory but on specific observable actions and events. For example, for the employees managing the client SFTP sites, specifically state the importance of accurately managing account permissions and of instituting testing prior to deployment. Also provide and communicate a mechanism to report when one client accesses another client's FTP site. This mechanism should be easy to remember and use. Telling employees that “PII exposure is a data breach” puts the onus on them to define and identify PII, as well as determine individually whether an event constitutes an exposure. Some employees may not translate one client accessing another client’s FTP site with personally identifiable and/or financial information as a PII exposure. Be specific. Instruct employees to make a report to the incident response team if one client accesses another's FTP site. Tell them that the team should evaluate the incident for compliance with mandatory notification laws. These messages are less ambiguous and more effective. While there are many “Data Breach 101” webinars and generic training programs, these are not as effective as data security and privacy training tailored to your organization. The latter gives employees an understanding of the best security practices as they relate directly to daily tasks, and it doesn’t require individual interpretation from employees.

A knowledgeable employee can be a point of defense rather than a point of exposure.

Deena Coffman is Chief Operation Officer for IDT911 Consulting and Information Security Officer for IDentity Theft 911.

Register for Bank Systems & Technology Newsletters
Bank Systems & Technology Radio
Archived Audio Interviews
Join Bank Systems & Technology Associate Editor Bryan Yurcan, and guests Karen Massey and Jerry Silva from IDC Financial Insights, for a conversation about the firm's 11th annual FinTech rankings.