There are currently over 45 state breach notification laws within the U.S., several data protection laws, and numerous regulations including PCI DSS, HIPAA/HITECH, and FISMA, among others. Nearly all of the laws require some form of consumer or other notification in the event of a data breach or data exposure. While the PCI DSS does NOT require notification of a data breach, the various card brand rules require notification.
Some of the more interesting (and heated) discussions arise when companies are asked to define data breach or data compromise as would merit disclosure. More interesting is when companies are asked to define a suspected data breach. For the purposes of PCI DSS, a suspected data breach is the key that requires notification.
Visa’s rules state that “suspected” breaches must be immediately reported or there could be potential penalties. As stated in the Visa “What to do if Compromised” document: “Immediately report to Visa the suspected or confirmed loss or theft of Visa.” (emphasis added)
The suspected part is where companies are exposed to significant risk. Many state breach notification laws also require notification if there is high likelihood of fraud or exposure of consumer data.
Consider the following example. Suppose you, as CSO, are informed of a malicious software outbreak in the customer service department. Does this alone require notification under the state breach notification laws, or relevant regulatory regimes such as Visa’s CISP? Maybe and maybe not. It depends upon a number of factors including access to data, data protections (i.e., encryption, tokenization), network segmentation, various laws etc. In short, it is not easy to decipher, yet it is critical to be as accurate as possible.
Understanding what is, and what is NOT, a data breach or data compromise is the first step in defining your company’s data breach notification plan. The reason it is so critical is in the title of this article. Once you notify that your company has been breached, you cannot unring the proverbial bell. Certainly, any company would absolutely hate to make an announcement that protected data was exposed only to find that, while they may have experienced a security incident, it did not impact sensitive data (PII, CHD, NPI, PHI, etc.).
Taking broader regulations into account
When evaluating your company’s notification requirements under the various card brand data protection programs (CISP, SDP, DSOP, etc.), it is critical that you not forget to consider the broader privacy regulations that may impact your organization. It is equally important that you work with your compliance group, legal team (don’t forget legal!), and the infosec & risk department to ensure you have a solid understanding of when, and under what conditions your company is required to notify of a breach or suspected breach. Here are some basic definitions to use as a starting point. (Please validate these definitions with your own legal and risk departments):
Security incident/event: Any event that compromises the availability, accessibility, or integrity of any asset. This includes systems, personnel, applications, services, etc.
Data breach: Any exposure of, or unauthorized access of sensitive and/or protected data to include PHI, PII, CHD, and NPI.
Suspected data breach: In the absence of direct evidence (identified fraud, or misuse of data, for example), any Security Incident in which it can be reasonable assumed that sensitive and/or protected data was exposed or accessed without authorization.
Remember, some state breach notification laws do not consider a breach of encrypted data as a trigger for notification while others do. Simply encrypting data may not provide absolute protection against notification of a data breach event.
You can find a list of state breach notification laws at www.NCLS.org
In addition, AT&T’s PCI Practice and GRC Practice can help your organization unravel the complexities of compliance.