To revisit briefly the tortured history of this regulation, the original version was highly prescriptive and mandated specific technological protections (such as 128-bit encryption) regardless of the size, nature and scope of the business and the risks involved. After wailing and lamentations from business groups, a near-final regulation (discussed in depth in this blog) was issued in August 2009 and shifted the regulatory standard to a more flexible, risk-based, technology-neutral approach. The final revisions were issued after a September 22 hearing, based on which the OCABR concluded that it had finally gotten it right.

The revisions are minimal and deal mostly with the compliance deadline for binding third-party service providers by contract. The final regulation makes it clear that existing contracts signed on or before March 1, 2010 do not have to contain the magic language requiring service providers to maintain appropriate security measures to protect personal information. However, this carve-out does not apply as of March 1, 2012; on that date, ALL contracts must be compliant.

Now that those damned Yankees have won the World Series, if you’re yearning to read the final regulation, you can get it here.

Data breaches impose huge costs on businesses in terms of investigation, remediation, fraud losses, notification of affected individuals, replacement of accounts and reputational and customer-relations damage. Given the resources and sophistication of foreign criminal syndicates and other fraudsters, some data breaches are probably unavoidable. However, in the unfortunate event of a breach, you do not want to be seen as having fallen too far behind the state of the art in information security protection, or you could face statutory or regulatory fines and negligence liability. The FTC busted TJX, which ended up paying millions of dollars in fines to the FTC and the states, because, among other things, they used WEP, an outdated wireless encryption standard. As previously described in this blog, Nevada’s data security law, Senate Bill 227 (which is potentially applicable to any business with Nevada customers), requires personal information stored on portable devices in motion or transmitted outside a business’ secure systems to be encrypted using technology approved by an “established standards setting body.”

And now, in the case of Shames-Yeakel v. Citizens Financial Bank, No. 07-C-5387 (N.D. Ill. Aug. 21, 2009), a federal district court in Illinois has denied Citizens Bank’s motion for summary judgment dismissing a data breach-related negligence claim where the bank allegedly had not moved promptly enough to implement multifactor authentication (i.e., secondary inputs beyond name and password, such as tokens, personal questions, etc.) to secure sensitive Internet transactions. (A 2005 regulatory guidance had criticized single-factor authentication, i.e., name and password alone, as being inadequate.)

There is a dialectic going on here: legislatures, regulators and courts are wary of imposing compliance requirements involving huge costs for new IT infrastructure at a time when the national unemployment rate is 9.8%. At the same time, given the mounting economic costs of data breaches, the public outcry over identity theft, and the connection between identity theft, organized crime and terrorism, legal and regulatory scrutiny of data security protections is increasing and will continue to do so. This dialectic was evident in Massachusetts this past August, when, at the urging of business groups, 201 CMR § 17.00, a highly prescriptive, technology-specific data security regulation that would have gone into effect in January 2010 (and would have required data in motion or stored on portable devices to be encrypted using 128-bit technology) was thoroughly revised to be risk-based and technology-neutral and to take into account the size, scope and type of business, the amount of resources available to the business, etc.

Don’t be an outlier. Learn what the state of the art is (the supporting and ancillary documents for the Payment Card Industry Data Security Standard are particularly useful here) and try to be in the general vicinity. If it’s too expensive, think about outsourcing the hosting or processing of personal information (but make sure you have done due diligence on the vendor and have a protective contract with them, as required by PCI DSS, HIPAA, federal banking regulations and state data security laws) or whether you even need to hold personal information in the first place. Amid the carnage and emotional trauma of a data breach, there’s no need to add legal fees, regulatory fines and tort damages to the heap of misery.

Our new offices in Old City

My biggest challenge in putting the presentation together was to connect all of these dots into some type of coherent pattern. At the beginning of the summer, it looked like we were moving to a much more “prescriptive,” technology-specific, top-down style of data security regulation in the former Massachusetts mold (rigorous computer system security and personnel access control requirements for all businesses owning or licensing personal information, 128-bit encryption, etc.). Then Massachusetts did an about-face, and other states failed to follow the Nevada and Massachusetts model of requiring encryption for personal information transmitted over open networks or stored on portable devices.

The two federal data security bills would set a national data breach standard and national standards for implementing data security safeguards, but are largely technology-neutral (Congressman Bobby Rush’s H.R. 2221 even goes so far as to prohibit the FTC from setting specific technological requirements!). At the end of the day, I told my largely California-based audience that their state data security statute (the original data breach notice legislation combined with a requirement to use reasonable data security safeguards appropriate to the nature of the data) would likely be the paradigm for national and other state data security legislation. California is the trend-setter for insanity in many areas of the law, but its regime seems relatively sane when compared, for example, with the earlier, anal-retentive version of Massachusetts’ 201 CMR 17.00.

While the breeze in San Francisco Bay was lovely, it’s good to be back in the City of Brotherly Love, and in new digs, too. More to come.

First, the new version reflects an abandonment of the “prescriptive” (i.e., top-down, technology-specific) regulatory approach that characterized the previous version of 201 CMR 17.00 issued in February 2009. To put it bluntly, that version scared the living hell out of recession-battered small businesses with its insistence on using 128-bit encryption to safeguard personal information stored on portable devices or transmitted wirelessly or across public networks, and a host of other computer security fiats that could have required the addition of costly IT infrastructure. 201 CMR 17.00 would have been the most stringent data security regulation in the country and would have affected millions of businesses and organizations outside Massachusetts, indeed, anyone who owned or licensed personal information about a Massachusetts resident.

As the OCABR proudly explained when it unveiled the redraft, the new, mellower 201 CMR 17.00 more emphatically adopts the flexible risk-based approach used by federal law, such as the FTC’s Safeguards Rule implementing the security requirements of the federal Gramm-Leach-Bliley Act (GLBA). Organizations other than Massachusetts governmental entities that own or license personal information (first name or first initial and last name, together with Social Security, driver’s license or state ID card number, or financial account, credit or debit card number) relating to a Massachusetts resident must still implement a comprehensive written information security program containing administrative, technical and physical safeguards, but it is clear now that the appropriateness of the safeguards will depend on the size, scope and type of business, the amount of resources available to the business, the amount of stored data, and the need for security and confidentiality of consumer and employee information.

While all information security programs must still meet some general requirements (such as designating employees responsible for their maintenance, risk assessment and evaluation of current safeguards, reasonable restrictions on physical access to records containing personal information, oversight of service providers through an appropriate selection process and contracting, developing employee security policies for the storage, access and transportation of personal information outside of business premises, preventing terminated employees from accessing personal information, documenting responses to data breach incidents, etc.), gone are the more onerous requirements, such as identifying all systems and storage media containing personal information and imposing a rigorous system of limiting the extent and duration of access by personnel to personal information. (These former requirements will now be used as guidance only.)

Another notable change is that the computer system security requirements in the regulation will now apply only to the extent technically feasible for the business. In its FAQ’s, the OCABR defines “technically feasible” as indicating the existence of “a reasonable means through technology to accomplish a required result.” This qualifier has enormous significance for the requirement to encrypt personal information stored on portable devices or transmitted wirelessly or across public networks. For example, while encryption of backup tapes on a going-forward basis is required, a business may not be required to encrypt a tape being transferred from current storage (although it should consider alternate protections depending on the amount and sensitivity of the information). Likewise, the OCABR has indicated that it may not enforce the encryption requirement for Blackberries, iPhones and similar devices, since there is currently no generally accepted encryption technology, but will for laptops.

Not only is the encryption requirement now subject to technical feasibility, but it is also technology neutral. No longer will businesses be required to use an encryption standard of 128-bit or higher.

There have also been some changes to the requirement to oversee service providers with whom personal information is shared. First, as the statute has become less onerous, the requirement to select service providers capable of compliance has become correspondingly lighter. Secondly, the regulation is now in conformance with the FTC’s Safeguards Rule under GLBA; businesses must take “reasonable steps” to select service providers capable of maintaining appropriate security measures for personal information and must require them to do so by contract. (However, any contract entered into prior to March 1, 2012 will not be considered non-compliant even if it lacks these provisions, as long as it was entered into prior to March 1, 2010.)

Finally, the date by which businesses must be compliant with 201 CMR 17.00 has been pushed back to March 1, 2010 (from January 1, 2010), another concession to the jitters experienced by small and medium-sized businesses (SMB’s) since the inception of this regulation in late 2008. (It is even possible that the regulation will be further amended, since the OCABR has invited public comment and will hold a hearing in Boston on September 22.)

Is 201 CMR 17.00 less scary now? Yes, but how much depends on whom you ask. For regulated financial services companies or businesses used to complying with the Payment Card Industry Data Security Standard (PCI DSS), HIPAA or GLBA, the amended Massachusetts regulation requires little or nothing that they are not already doing. However, it is still more stringent and formalistic in terms of administrative process than any other state’s data security law (including even California’s!) and will represent a major cultural shock for SMB’s who up to now have not had to think systematically about security (and may not have a CTO or information security officer on staff). Furthermore, based on my own experience, some managers who are used to purchasing IT services quickly, based on lowest available pricing, may chafe at the service provider due diligence and contracting requirements, although these requirements can actually be satisfied fairly easily.

With March 1, 2010 rapidly approaching, businesses will need to take a good hard look at themselves, assess the risk and the resources available to mitigate it, and determine whether their need to store and transmit personal information is great enough to justify the extra costs of compliance.

I will discuss the changes more fully in an upcoming post, but overall they respond to concerns from recession-racked businesses about the stringent encryption and other technical and computer security requirements of the regulation, which would have applied across the board to businesses regardless of their size and resources and the technical feasibility of implementation.

So, for example, the amended regulation now only requires that personal information stored on portable devices or transmitted over the Internet must be encrypted “to the extent technically feasible.” Furthermore, it drops the requirement of a 128-bit or higher encryption standard. More generally, businesses’ information security programs now only must contains safeguards that are appropriate to the size, scope and type of business and the amount of resources available to the business. The third-party service provider oversight provision has also been modified to be consistent with the FTC’s Safeguards Rule implementing the information security requirements of the Gramm-Leach-Bliley Act; businesses must take “reasonable steps” to select service providers capable of maintaining appropriate security measures for personal information and must require them by contract to do so. However, any contract entered into prior to March 1, 2012 will not be considered non-compliant even if it lacks these provisions, as long as it was entered into prior to March 1, 2010.

More to follow soon.