Is 201 CMR 17 compliance keeping you up at night? You're not alone. This new Massachusetts data protection law is one of the most stringent of its kind. But don't fear, compliance is possible.
In this interview, David Navetta, founding partner of the Information Law Group, discusses how enterprises can approach compliance with the many different facets of this law.
0:30 - Why so stringent?
1:12 - Key provisions to watch
2:05 - Evaluating risk postures
3:26 - Legal issues vs. security issues
5:28 - Enforcement: What to expect
7:20 - Gauging "technical feasibility"
8:30 - Documenting compliance
10:08 - Provisions for reporting
11:19 - Is "quick fix" compliance possible?
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact firstname.lastname@example.org.
201 CMR 17 compliance: What you need to know
Eric Parizo: Hello, I am Eric Parizo, it is great to have you with us. Joining us
today is David Navetta. David is the founding partner of the
Information Law Group. David, thank you so much for joining us today.
David Navetta: Thank you so much for having me, appreciate it.
Eric Parizo: 201CMR17 is widely considered the most stringent State Data Breach
Law conceived yet. Why is that?
David Navetta: I think it is because of the laws that actually came before
that. A lot of the Data Security Laws out there, whether they be
federal or state, often required a nebulous security requirement,
comprehensive security, reasonable security, adequate security. This
law was one of the first laws to actually require a specific set of
controls be in place, as well as a written information security
program. I think companies of all sizes are looking at it and saying,
'Wow, this is much more, this does not allow as much leeway, I would
say, than a lot of the other laws that existed.' Although, that was
changed to some degree, and I am sure we will talk about that in a
Eric Parizo: What are the key provisions that information security managers need
to be concerned with?
David Navetta: As I was saying, the key issue here is the specific
requirements for written information security program, which includes
many different types of provisions, such as risk assessment, security
policies, disciplinary actions, overseeing service providers, all that
needs to be written into a written information security program that
is comprehensive. The second aspect of it are actual controls that
need to be in place, including authentication controls, access
controls, encryption of data on public networks or on wireless
networks, encryption of data on storage devices and laptops. All these
specific requirements are in the act and I think all of them cause
potential challenges for companies trying to comply with the law.
Eric Parizo: Perhaps the most nebulous part of 201CMR17 is that organizations are
charged with evaluating their own risk postures. What are the issues
that come along with that?
David Navetta: A little history here: the regulation started out without any
kind of risk-based factors built into it. The risk-based factors were
actually intended to help smaller and medium businesses address their
concerns without having necessarily to comply strictly with each of
the requirements of the law. The problem with that, of course, is
whenever you are making that kind of judgment; it is actually a legal
judgment, as opposed to a security judgment. This is where I think
legal and security overlap much more so than any other laws that I
deal with. What you need to do here as an organization essentially,
is not only look at your security in general, you need to think about
if I am not going to be able to comply with each of the strict
requirements of this law for whatever reason, whether or not I can
justify that based on the various risk factors that are set forth in
the law, including the size of the company, resources of the company,
type of data that is being held, and amount of the data. The problem
with that, of course, is there is judgment involved in that, again,
legal judgment is the issue. I think it can be difficult for a
security professional to look at the statue by himself and try to come
up with the right answer, and this is where you need to work with
legal, and actually try to understand how a judge, a jury, or
regulator may look at your decisions as you make them in this context.
What you are essentially doing, in essence, is taking a legal
position. If you are not strictly compliant with each of the
requirements, the question you ask yourself as an organization is, 'If
I suffer a breach, or if a regulator comes in and does an
investigation, how am I going to legally defend my situation and my
decisions?' Going to your question, this is where the documentation
comes in. You need to be able to understand how you came up with the
decisions that you made when you put your controls in place, why you
left certain things out, or why you were not stringent in certain
areas, and you need to justify that at a risk basis. 'I did not do
this because there was not a risk that was actually present in this
area, or the data I had was so small, it wasn't that much data and I
didn't have much risk there, or my company did not have enough
resources to do whatever it was that was required of the law.' Again,
the problem is whenever you make that kind of judgment call, when
something goes wrong, you need to be able to defend it.
The other aspect of documentation and this law, that is interesting,
is for the control section, they say 'If it is not technically
feasible, you do not need to put certain controls in place.' Again,
you look at those words and you ask yourself, 'What do they mean? What
do they mean, in practice? Whether you are a lawyer coming out of the
blue or a security professional, it is difficult to know what that
means. You basically need to build positions around what 'technically
feasible' means, when it comes to controls. What is somewhat
disturbing is when it says 'technically feasible' for the control
section of this law, 'technically feasible' does not seem to take into
account the cost to put a control in place, for instance, encrypting a
laptop or encrypting data devices, and it does not seem to take into
account how it might disrupt your business to do some of these things.
I think there are some challenges beyond the actual requirements of
the statute in just how it is worded and drafted that also need to be
addressed, again, with a legal and security bend on it.
Eric Parizo: David, since this is new law, there are not really any precedents for
how it is going to be enforced. What can organizations use as a
David Navetta: There is the concept of the law of 'reasonable security.' That
is a concept that is similar to a slip-and-fall theory, where you were
negligent and did not shovel your driveway; you did not take
reasonable actions to do so. The same theory can apply to security.
Unfortunately, we are just starting to get to a point where that type
of theory is being tested in the law and in courts, but right now, we
do not have much guidance on it. Ironically, the place that it is
actually being tested right now is in the online banking cases, where
there has been a breach of a customer's online banking account, and
the question of the case is whether or not the bank's security was
reasonable or not. What you look at and what courts have looked, or
are starting to look at are industry standards, guidance that is put
out by organizations within the banking industry. They look at risk as
well. What I try to tell clients is if you are looking at various
choices, whatever choices you can show that do not cost that much
money but save a lot of risk or reduce a lot of risk, those are
usually the choices you need to make.
When it comes to very expensive types of controls or measures that do
not necessarily save a lot of risk, those may not be the controls or
measures you need to put in place. There is no magic formula,
unfortunately. It is a case-by-case basis, and you have to take a lot
of factors into account, again, going back, you need to understand how
you came to your decisions in the first place, so whenever challenged
on them, or when the regulator or litigator comes in and says you have
done something wrong, you can go back and understand what you have
done, and explain why it was reasonable or complied with the law.
Eric Parizo: There is quite a bit of leeway, in terms of what is considered
'technically feasible,' especially from one industry to another. How
can organizations go about figuring that out for themselves?
David Navetta: This is where I have to bring in my security friends and defer
to them, and this is again, the key point I always try to make is it
is a collaborative effort. I cannot say, as a lawyer, what is
technically feasible, I need to rely on the experts to do so, whether
it be internal experts or outside experts, coming in to tell me what
is feasible. Again, I have problems with the words 'technically
feasible' in that statute because it does not take into account the
other risk-based factors that apply to the written information
security program. What I would advise clients, though, is to still
consider cost. The law, at least in the negligence context, does not
require perfect security, does not require that you build Fort Knox
every time; it requires that you have taken reasonable steps to
address the risk that you face. When you are looking at whether you
want to put a control in, whether it is technically feasible, or
whether it is practical for your organization, really that is the key
question. Is it going to reduce risk to a certain level that is
adequate or that you can defend in court?
Eric Parizo: There is also a really big emphasis on documentation. How can
organizations go about working with their legal and information
security teams to document compliance, over time?
David Navetta: To the extent you can set some sort of attorney-client
privilege that would allow you, in theory, to talk to business
managers and security professionals under the cloak of privilege, so
as you are making your decisions to the extent that you are
communicating sensitive information that could hurt you later on in
court, that information could be protected by attorney-client
privilege. The first thing is, as part of this documentation process,
you want to set up that privilege. Beyond that, I think what you need
to do is, again, it is a process. You need to show that you went
through a due diligence process, and you need to show essentially,
where you made certain decisions. A lot of your decisions are going to
be obvious, if you are able to encrypt data on laptops and it is not a
problem for your organization, fine. It is the gray areas where you
have had to, for whatever reason, because your organization is not set
up in a way to allow you to comply strictly with the law, or you do
not have the resources to comply, it is the gray areas where you
really need to sit down and say, for instance in the document,
'Despite the fact that we could not do X, we got X, Y and Z to
actually compensate and address the risk that would have been
mitigated by the control, X.' Putting that in documentation, and
saving it for a rainy day that hopefully never happens, is important,
especially, again, it might not happen for five years after you made
your decisions, and the people that made all those decisions may be
gone. This type of documentation can help you significantly if you
ever need to defend those actions.
Eric Parizo: It has been reported that the Massachusetts Attorney General's Office
has called for stringent reporting on any event that could eventually
lead to a data breach. What are the implications of that, for
David Navetta: What it looks like at this point, and from what I have heard,
is that if there is a breach, they are going to look at whether or not
you complied with this law, potentially. I am not sure if there is
going to be a threshold, maybe over a certain number of records or the
size of a breach where they might be interested, but the bottom line
is, in a lot of states where there has been a breach, you do not have
these laws behind them. What they do is they provide notice that could
the affected consumers, and that is the end of it. They may suffer a
lawsuit sometimes, but sometimes not. In this case, in Massachusetts,
or to be more accurate, if you hold Massachusetts resident data and
you suffer a breach, you could expect there is a possibility you are
going to have a regulator looking at whether or not you complied with
the law that sit behind the breach notice laws. I think that is a big
difference for organizations and imposes risk. You need to make sure,
not only that you provided notice, but that you can back up your
Eric Parizo: David, finally, there are several different organizations out there
that are offering what has been called a quick fix for 201CMR17
compliance, a $99 package, per se, and they offer everything you need.
What is your advice there, for organizations considering that kind of
David Navetta: It is a difficult question because it is a resource issue, at
the end of the day. I would say that just because you got a stamp of
approval from some third party, do not count on being actually found
compliant, or that you actually are compliant. I would use those types
of organizations as more of an organization to give you a test of what
you are doing or what you are not doing; giving you a feel for what is
going on. They can give you an idea of whether you need to dive deeper
into it. Hopefully, in a lot of cases, some of these organizations
pose such a low risk that there is really not a big issue, but if you
have a lot of data, especially credit card data, personal information,
you really need to look at this seriously, and take the time and
effort and sometimes, unfortunately, spend the money, to actually
address the issue.
Eric Parizo: David Navetta, founding partner Information Law Group. Thank you so
much for joining us today.
David Navetta: Thank you for having me.
Eric Parizo: Thank you for joining us as well. For more information security
videos, feel free to check out SearchSecurity.com/video. Until next
time, I am Eric Parizo. Stay safe out there.