Massachusetts' Revised Personal Information Security Regulation (201 CMR 17.00)

ness Regulation (OCABR) recently released a revised version of its "Standards for the Protection of Personal Information of Residents of the Commonwealth" (the "Regulation").  This August 2009 version modifies the February 2009 version of the Regulation. The press release for the new revision is here, and the FAQs released by OCABR appear updated to address some of the changes in the regulations. UPDATE (082509):  Jack Daniels with some insight from the security perspective: LINK. For ease of reference, ISC has taken the time  to create a REDLINED VERSION showing the revisions in the new Regulation.  The redlines indicate changes between the February 2009 version and the August 2009 version of the Regulation.  Also included below is a summary of some of the more significant changes.


Owns and Licenses v. Stores and Maintains Personal Information.

In the prior version of the regulation, companies that "owned, licensed, stored or maintained" personal information were subject to the Regulation.  Now, only companies that own or license personal information are within the scope of the Regulation.  The Regulation defines "owns or licenses" as follows:

Owns or licenses, receives, maintains, processes, or otherwise has access to personal information in connection with the provision of goods or services or in connection with employment.

As such, it appears that organizations that handle personal information when not in connection with the provision of good or services, or in connection with employment, would not be subject to the Regulation.  This could perhaps encompass a person or company holding personal information for purely personal reasons.


Written Information Security Program

The new Regulation builds in some flexibility with respect to the requirement of a written security program.  Now such program must contain:

administrative, technical, and physical safeguards that are appropriate to (a) the size, scope and type of business of the person obligated to safeguard the personal information under such comprehensive information security program; (b) the amount of resources available to such person; (c) the amount of stored data; and (d) the need for security and confidentiality of both consumer and employee information.

This appears to be designed to provide leeway for smaller organizations and other companies that do not pose much risk with respect to personal information.  In fact, this is confirmed to some degree by the FAQs released by OCABR, which indicate:

the most recent regulation issued in August of 2009 makes clear that the rule adopts a risk-based approach to information security, consistent with both the enabling legislation and applicable federal law, especially the FTC's Safeguards Rule. A risk-based approach is one that directs a business to establish a written security program that takes into account the particular business' size, scope of business, amount of resources, nature and quantity of data collected or stored, and the need for security. It differs from an approach that mandates every component of a program and requires its adoption regardless of size and the nature of the business and the amount of information that requires security. This clarification of the risk based approach is especially important to those small businesses that do not handle or store large amounts of personal information.

"Technically Feasible."

In the prior version of the Regulation, companies were required to encrypt files containing personal information transmitted across public networks or wirelessly only if it was technically feasible to do so.  The new Regulation expands the concept of "technically feasible" to apply to all of the items listed in the "Computer System Security Requirements" subsection of the Regulation. What this means in practice is that none of those specific controls of this section of the Regulation are now required unless it is "technically feasible" to implement them.  Again, this appears to be an attempt to provide some flexibility for small companies.  However, it also may provide cover for larger businesses that have complex IT environments. The key issue here is the meaning of "technically feasible."  One problem with the term for organizations subject to the Regulation is that it focuses on technical aspects rather than "cost feasibility" or "business feasibility." One could argue that practically anything is technically feasible if you don't take price into account or potential disruptions or problems with business practices and activities. While the term is not defined in the Regulation for some reason, the FAQs define "technically feasible" as follows:

"Technically feasible" means that if there is a reasonable means through technology to accomplish a required result, then that reasonable means must be used.

This definition does not necessarily help because it is not clear what is meant by "reasonable means" in this context, and whether resource and business constraints factor into the analysis.  Significantly, unlike in the context of a written infosec program, the Regulation does not explicitly reference the "resources available" to the company as one of the factors for determining whether something is "technically feasible."  ISC believes that this concept is vague and the OCABR would have been better served using an approach similar to the one used for the WISP.


New Service Provider Definition and Obligations.

The Regulation now includes a specific definition of "service provider":

Service provider, any person that receives, maintains, processes, or otherwise is permitted access to personal information through its provision of services directly to a person that is subject to this regulation; provided, however, that "Service provider" shall not include the U.S. Postal Service.

It appears that by using the word "directly" they wanted to eliminate companies that might incidentally receive personal information.  However, based on the language of the statute these companies would still be directly subject to the regulation if they "own or license" personal information.  As such, service providers may have both contractual obligations and direct obligations to comply with the Regulation. Significantly the duties with respect to service providers have also been narrowed.  Previously the Regulation imposed an obligation to take reasonable steps to "verify" that service providers could implement the required security.  The word "verify" has been dropped.  Added to the new Regulation is an obligation to have a contract in place with service providers requiring them to implement and maintain appropriate security measures around personal information.   This requirement only applies to contracts entered into after March 1, 2010 (it does not indicate what is to happen with contracts that renew after March 1, 2010).  Notably, the old version of the Regulation required companies to "ensure" that their service providers complied with the Regulation.


Deleted Specific WISP Requirments

The old version of the Regulation required the WISP to impose a "minimum necessary use" limitation with respect to personal information, and a mandated "personal information" inventory be performed.  Those specific obligations have been deleted (however, they could still be required in general with respect to a WISP). In all, by attempting to impose a "risk-based" framework, the Regulation appears to provide more flexibility and leeway.  Nonetheless, the Regulation is still vague in some areas and companies of all sizes and complexities will have to analyze whether and how the law applies to their organization.  The Regulation will also complicate relationships with service providers, who are likely to have to go through a more rigorous "due diligence" process and also enter into more stringent contracts imposing security obligations. There are additional changes that you can observe in the redlined version.   If you have any additional input on the potential impact of these changes, please provide a comment so we can further discuss (and I can update this post as necessary).