[BreachExchange] Who’s Handling Your Data?: Vendor Risk Management

[Audrey McNeil]

http://www.hitechanswers.net/whos-handling-data-vendor-risk-management/

Access cannot be freely granted to data. Such is the reality of the world
today. If a vendor is allowed to freely access, use or otherwise interact
with data, unnecessary risk has been created. Why go down the risk-filled
road, when issues can be identified and addressed? This question is central
for healthcare entities, whether covered entities contracting with business
associates or business associates contracting with subcontractors. The
direct liability all of the way up and down the chain of access now firmly
entrenched in HIPAA means no entity on any level can escape notice.

If risk exists on all levels, what can be done? Asking questions prior to
full engagement of a vendor is the first step. Do not assume that a vendor
is providing all necessary information, or even any of the relevant
information when pitching services. Instead, having a questionnaire ready
to go that can pull in baseline data. For example, ask a vendor whether it
has HIPAA policies and procedures in place, when it conducted its last risk
analysis, how the results of the risk analysis were used and whether a
breach has ever occurred. Obtaining responses to these and similar
questions can begin providing comfort as to the actual status of a vendor’s
security and/or privacy preparedness.

If a vendor makes it past the initial road of vetting, the terms of the
service agreement are the next important step. What requirements should be
baked into the agreement and how specific or granular should those
requirements go. The answer likely depends upon the nature of the services
being provided. If a vendor is hosting protected health information or
regularly transmitting protected health information, then the agreement may
get quite specific as to types of encryption to utilize, means of
transmission or other requirements. However, if the vendor provides a
service where they only get a minor subset of protected health information,
then a little more leniency may be possible. In addition to the scope of
requirements for protection specified, consideration should be given to the
consequences of non-compliance. Is there a monetary penalty, immediate
termination or some other outcome? Again, the scope of remedies will depend
upon the nature of the services, but all of these issues should be
considered.

The business associate agreement is the next essential element. As should
be widely known, if there is a business associate relationship, no
protected health information can be exchanged until the BAA is in place. If
parties were somehow unaware of the necessity of a BAA, a recent HIPAA
breach settlement through the Office for Civil Rights made the requirement
crystal clear. Acknowledging that a BAA is needed is only the first step
though. The next step is determining whether the BAA will stop at the
baseline of the regulatory requirements, or include “extracurricular” terms
such as mandating insurance coverage, calling for indemnification or
reimbursement, and granting the upstream entity audit rights. Some elements
are easier to identify as desirable than others, i.e. indemnification or
reimbursement. A term such as audit rights is not as clear cut. Arguably
this provides good insight, but the upstream entity will actually need to
utilize those rights. Failure to do so could backfire and end up in
negative consequences for the upstream entity.

The process of vendor management does not end with the execution of an
agreement either. Constant vigilance and dialogue are needed. Threats are
evolving, so entities cannot remain static. If any aspect of privacy or
security protection sits for too long, an issue will almost certainly
arise. Accordingly, parties should work together to manage risks and not
assume that the other is the only one responsible. A go it alone approach
will only come back to harm both entities.

Managing privacy and security risks is not easy. However, understanding
baseline regulatory requirements provides a firm foundation from which to
build. Ignoring or misconstruing that foundation will weaken the structure
above and create enforcement exposure. Do not overlook these initial steps
and create unnecessary risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170420/c05c39e6/attachment.html>