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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
8/13/2013 | 3:41:11 PM
re: What Constitutes a Data Breach for Banks?
It is fitting that the author of this article is an I.S. officer, as all the information is spot-on and relevant to any business exposed to the current threat environment (all of them). One of the most significant points made is that people generally do not process abstract concepts well into practical terms, especially when dealing with technical issues, which pretty much do require specific actions.

G«£Data security is of utmost importance to our businessG«• --/-->
G«£I need to shred this clientG«÷s file copies lying on my desk before I leave the
office,G«• or the slightly more technical, G«£Why is the S missing from the HTTPS
on this website? SomethingG«÷s not right here.G«• Any basic course on business
information security teaches that an organizationG«÷s own employees are often the most dangerous threat to the companyG«÷s data (moreso than crackers, foreign governments, etc.). Negligence and ignorance cost companies grossly underreported amounts of money, not to mention the reputation damage when it all becomes public. Staff need to be trained as much as possible, with well-defined security policies and standards.

Since the function of IT is to speed up business operations
and efficiency, it makes sense to invest in software that both emphasizes
security, and promotes smooth automation requiring minimal operator
intervention. This reduces the chance for errors that could then constitute a
data breach. Security, especially for institutions dealing with compliance
pressure, must be implemented and monitored at all levels G«Ű back-end programming, front-end, personnel policies, and so on. Data integrity and authenticity are just some of the sub-points of a complete plan to secure data.
User Rank: Author
7/31/2013 | 3:18:22 PM
re: What Constitutes a Data Breach for Banks?
That is true, when someone's financial information gets breached, they don't care or want to hear how it was a vendor's fault, the blame will go towards the financial institution.
Greg MacSweeney
Greg MacSweeney,
User Rank: Author
7/30/2013 | 8:37:46 PM
re: What Constitutes a Data Breach for Banks?
I don't think they are ever reported as "data breaches," since the company often voluntarily handed over the data to the vendor. It is something that financial firms need to watch very closely. It is very easy just to hand over the entire data file and that is often what is done. However, a firm should only be giving a 3rd party the data that is actually needed to complete a specific task (data analysis, let's say).

Firms need to think along these lines because one day a 3rd party vendor's systems will be breached and if the data on those systems comes from a bank, the bank will be held responsible by its clients and by the regulators.
User Rank: Author
7/30/2013 | 6:04:32 PM
re: What Constitutes a Data Breach for Banks?
Interesting perspective, I had never thought of that. I wonder how many of these cases are ever reported as data breaches?
User Rank: Apprentice
7/29/2013 | 5:54:14 PM
re: What Constitutes a Data Breach for Banks?
In addition to all of the above, many companies and government agencies routinely provide sensitive information to their software developers and testers. Is this a breach? Do these individuals absolutely need real data to do their job? The answer is NO and these cases should be reported as data breaches.
Register for Bank Systems & Technology Newsletters
White Papers
Current Issue
Bank Systems & Technology Dec. 2, 2014
BS&T's 2014 Elite 8 executives are leading their banks to success, whether it involves leveraging the cloud, modernizing core systems, or transforming into digital enterprises.
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.