Using “Compliant” Stuff Doesn’t Result in Full Compliance

In the past couple of weeks I’ve spoken with five different small to mid-size organizations who have had a software or hardware vendor basically tell them, “Our product is HIPAA compliant! Use it and you will also be fully HIPAA compliant!” How can that be? In three words; it can’t be. Here’s what is most likely going on with those claims.

Vendors themselves don’t meet full compliance

Hardware and software vendors are providing tools that organizations can use to support their wide range and large number of business processes.  The business processes, software and hardware often involve personal information of some type, which are subject to a very wide range of laws, regulations and other legal protection requirements.  The vendors and manufacturers typically are *not* also subject to these same legal requirements, because they are not providing the same types of services as the regulated organizations they sell to. They are providing tools to businesses that deliver the services.

However, many to most hardware, software, vendors and manufacturers have regulatory requirements for the quality and safety of the products they are creating with which they must comply. Those types of regulations apply to specific features that the product must contain, and performance requirements.  Once those are met, those types of businesses generally do not need to do anything else for compliance; it is basically a checklist exercise with a specific end.

Many to most of these vendors and manufacturers do not also fall under data protection regulations. Because of this they view compliance from their own, limited, perspective of always being a checklist that you do once and forget about.  Many to most are not experienced with the need to comply with data protection regulations that require ongoing activities and do not have a specific compliance end date (after all, data protection is an ongoing activity). So, many to most of these vendors and manufacturers do not realize that data protection compliance is an ongoing process with no set completion endpoint.

One or two technical controls don’t fulfill all data protection compliance requirements

There are many types of software and hardware that can support one or some of your many data protection compliance requirements. However, just implementing some type of supporting hardware or software product will still leave many other types of requirements that you must address. And many of those requirements you cannot hand off to someone or something else; they involve you and others in your organization actively doing such things as risk assessments, training, audits, log checking, policy and procedure creation and updating, physically safeguarding, plus a whole lot more.

I was at the 10X Medical Devices conference (which I highly recommend, and look forward to attending again next year) last month, and did a plenary session on the need to build security and privacy controls into medical devices, as well as meet associated HIPAA compliance requirements. I also provided an overview of HIPAA compliance, and explained that it was much different than the FDA compliance checklists that they used for their devices; that it involved the need to have regular training and documentation for a broad spectrum of administrative, physical and technical controls, and that the risk for these areas had to be managed on an ongoing basis. I saw a lot of light bulbs go on over the tops of the heads of many in the audience when I had made my point clear. After my session a couple of representatives from a medical device vendor thanked me and told me they now understand how HIPAA, and other data protection regulations, are significantly different from FDA and other quality and safety regulations. One said, “I’ve been telling my clients for years that our device will make them fully HIPAA compliant because it has encryption.  Wow. I need to change my sales pitch!”

Many of the clients of vendors and manufacturers are depending upon and believing the information they give them is accurate. However, just implementing encryption will not bring you into compliance with HIPAA, or any other data protection law or regulation.  Likewise, just implementing firewalls will not bring you into data protection compliance. Technology alone will not bring you into data protect (e.g., HIPAA, GLBA, etc.) compliance.

A more transparent claim would be that a vendor’s product can support or provide a means to enable HIPAA certain portions of HIPAA compliance, such as encryption; similar to how IBM describes their Elastic Storage data and file management solution. It does not claim full compliance with HIPAA, but that it addresses the compliance requirement to limit access to health data.

Organizations must do a wide range of administrative, technical and physical activities on an ongoing basis, integrated into their daily business practices, to be compliant with data protection legal requirements. Simply implementing one or two technical security controls is a good first step, but far from reaching full compliance, which once attained must then be continuously maintained.

Bottom line for all businesses of all sizes…

Organizations that access, in any way, some type of personal information will likely have data protection compliance requirements with which they must comply. Data protection requirements will have three primary types of activities required: administrative, technical, and physical.

Technical products alone cannot address all compliance requirements, and certainly cannot address all information security and privacy risks. If a vendor tries to tell you otherwise, do not believe them! Data protection compliance requires ongoing actions and management and does not have a set endpoint.

 

 

This post was written as part of the IBM for Midsize Business (http://Goo.gl/t3fgW ) program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.

IBM

< !– Start of StatCounter Code for Default Guide –>

tumblr visitor

Tags: , , , , , , , , , , , , , ,

Leave a Reply