Data security: What the law requires of IT

IT's legal duty to secure sensitive data is complex and continuously evolving. Here's how to avoid the legal ramifications of a data breach

For most IT organizations, securing corporate data against compromise is priority No. 1. Girding the enterprise against breaches is a constant, thankless task requiring foresight, vigilance, and much in the way of IT expenditures. Keep up with the latest threats, or find your company in the headlines -- and your job on the line.

Such is the shift in attitude toward security in IT. In the Wild West, when Jesse James and Butch Cassidy robbed banks, we felt sorry for the banks and hunted down the outlaws. Today, when someone breaks into a company's computer system, our response is totally different: We blame the company for failing to provide adequate security.

[ Avoid "The top 10 security landmines" and keep up with the latest security trends on Roger Grimes' Security Adviser blog. ]

Codifying this shift is a complex blend of laws and regulations enacted to protect the confidentiality and integrity of valuable personal data and the individuals who might be harmed by a breach. Not complying with these mandates can result in grave legal consequences should your organization suffer a breach.

Here you will find a framework for understanding these legal initiatives, which, when viewed as a group, impose two key legal obligations on your organization: the duty to implement reasonable security measures to protect data, and the duty to disclose breaches to those affected.

The duty to provide security
There is no single statute or regulation that governs all of your company's information security obligations. Instead, an ever-expanding patchwork of legal requirements is continuously evolving to impose a comprehensive duty to provide "reasonable" or "appropriate" security to protect your corporate data.

At the center of this patchwork are numerous state and federal regulations: privacy laws that require companies to protect personal data; e-transaction laws that govern the accessibility and integrity of electronic records; corporate governance legislation that requires appropriate controls to protect public companies and their shareholders, investors, and business partners; and unfair-business-practice laws now interpreted to include failure to provide adequate security as an unfair business practice.

[ See Thomas J. Smedinghoff's "What the Law Requires" ( Part 1 | Part 2 | Part 3 ) as presented at InfoWorld's Enterprise Data Protection conference ]

Further complicating your obligations are recent lawsuits, in which a variety of legal theories have been asserted against organizations for failing to provide adequate security for their data. Some decisions have held that companies can be liable for negligence in failing to provide adequate security. Wolfe v. MBNA America Bank, which involved a negligence claim against MBNA America Bank for damages sustained by a victim of identity theft, is an example of this.

In addition to the obligations imposed by statutes, regulations, and court rulings, your company may assume security obligations voluntarily by contract. For example, outsourcing or similar agreements in which one business has access to the confidential data of its trading partner often require appropriate security measures be taken to protect that data. Similarly, businesses are often required to agree to security commitments as a condition of participating in certain activities. Merchants that want to accept credit cards, for example, must agree to comply with the PCI (Payment Card Industry) Data Security Standard.

Rounding out your duty to secure information are obligations your organization has imposed on itself. Through statements in privacy policies, on Web sites, or in advertising materials, your organization will often make claims regarding the level of security it will provide for the data it collects or maintains. By doing so, you impose on yourself an obligation to comply with the standard you have represented to the public.

The legal standard for compliance
The laws, regulations, contracts, and other obligations that impose a duty to provide security typically require only that you provide "reasonable" or "appropriate" security. They offer little guidance as to what kind of security measures are required or how much security is enough. This raises a very difficult question: What constitutes "reasonable" or "appropriate" security?

Yet a careful review of newer statutes and regulations, court decisions, and government enforcement actions reveals an amazingly consistent approach for defining the parameters of a "legal" standard for compliance. That standard focuses on process, not on specific security controls.

[ Take a data-centric view of IT security and find out how the latest security technologies rate in our InfoWorld Test Center lab tests. ]

The legal standard does not dictate what measures are required to achieve reasonable security. Instead, it requires companies to undertake a risk-based process to identify and implement measures that are reasonable under the circumstances to achieve the desired security objectives. This means companies must assess the risks they face, identify and implement appropriate security measures in response to those risks, verify that those security measures have been effectively implemented, and ensure that they are continually updated in response to new developments. And when that is done, the law requires that the process be repeated periodically.

As a result, security measures necessary for legal compliance vary depending on the situation, with decisions regarding the specifics of your security strategy being left up to your company. In Guin v. Brazos Higher Education Service, for example, the court rejected an argument that a specific security measure -- in that case, encryption of personal data on a laptop -- was legally required. Instead, the court noted that the security controls in place were reasonable in light of the risk assessment done.

In other words, the focus is on risk assessment, and then on adopting security controls that are responsive to the threats your company faces. It is not enough merely to implement impressive-sounding security measures.

For example, posting armed guards around a building or requiring key-card access may give the appearance of security, but if the primary threat the company faces is unauthorized remote access via the Internet, physical security measures are of little value. Likewise, firewalls and intrusion detection software are often effective ways to stop hackers and protect sensitive databases, but if a company's major vulnerability is careless (or malicious) employees who inadvertently (or intentionally) disclose passwords or protected information, then even those sophisticated technical security measures, although important, will not adequately address the problem.

Adopting appropriate security controls in response to risk assessment plays an important role in determining whether liability will be imposed in the event of a breach. In Bell v. Michigan Council, for example, the court held that a union was liable for failure to provide appropriate security where it did nothing to protect against a foreseeable threat to its data. Yet in the Guin case noted above, the court held that a proper risk assessment had been performed and that the harm in question was not reasonably foreseeable. As such, the defendant was not liable for its failure to defend against that particular risk.

The law also examines whether security controls are adequate and properly implemented. Just because data is encrypted, for example, does not mean it is secure. One need only look at the TJX breach, which compromised an estimated 90 million encrypted credit card records. Ongoing monitoring, testing, and evaluation of the effectiveness of security controls is required to ensure that they are properly implemented and continue to be effective.

And when assembling your security strategy to appropriately meet the risks your organization faces, don't forget about third parties that have your data. Outsourcing information processing does not relieve you of your obligation to secure the outsourced data. As a consequence, you must look carefully at the security measures your outsource providers have in place -- contractual and otherwise -- to respond to a breach should one occur.

The duty to disclose security breaches
In addition to the legal duty to implement security measures to protect data, you are also required -- in many instances -- to disclose security breaches that do occur to the persons affected by the breach. Laws that require notification seek to provide individuals not only with a warning that their personal information has been compromised, but also an opportunity to take steps to protect themselves against the consequences of identity theft and unauthorized account access.

[ For more on disclosure requirements, see "What to do in the event of a data breach." ]

A total of 44 states, plus the District of Columbia, Puerto Rico, and the Virgin Islands have enacted breach notification laws as of August 2008. The key requirements, which can vary significantly from state to state, include the following:

What type of information is covered?
The statutes generally apply to unencrypted sensitive personal information -- for example, information consisting of first name or initial and last name, plus one of the following: Social Security number; driver's license or other state ID number; or financial, credit card, or debit card account number. Some states cover additional data categories as well.

What triggers the duty to give notice?
Generally, the statutes require notice to individuals following the unauthorized acquisition of data that compromises the security, confidentiality, or integrity of such personal information. In some states, however, notice is not required unless there is a reasonable basis to believe that the breach will result in substantial harm or inconvenience to the individual.

Who must be notified?
Notice must be given to any residents of the state whose unencrypted personal information was the subject of the breach. Some states also require notice to the attorney general, and several states require notice to the credit agencies.

When notice must be provided
Generally, persons must be notified in the most expedient time possible and without unreasonable delay; however, in most states, the time for notice may be extended to accommodate the legitimate needs of law enforcement, if notification would impede a criminal investigation, and to give the company time to take necessary measures to determine the scope of the breach and restore reasonable integrity to the system.

Form of notice
Notice may be provided in writing (such as on paper and sent by mail), in electronic form (such as by e-mail, but only in very limited circumstances), or by substitute notice (such as by publication in statewide newspapers and on the company's Web site).

When it comes to notifying individuals, the nature of the triggering event is of tantamount importance. In several states, for example, notification is required whenever there has been an unauthorized acquisition of covered electronic personal data. In other states, however, unauthorized acquisition of such data does not trigger the notification requirement unless there is a reasonable likelihood of harm to the individuals whose personal information is involved.

Taken as a group, these security breach notification laws suggest a key new addition to the law on corporate information security obligations -- one that goes well beyond the duty of a company to provide security for its information, by adding a duty to warn those who might be adversely impacted by a failure -- or a lack -- of corporate security.

Implicit in both the laws imposing a duty to provide security and those imposing a duty to notify individuals of breaches is recognition of the wide-ranging impact of a company's electronic activities, and the fact that security vulnerabilities in a company can have a significant adverse affect on a wide variety of stakeholders.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies