Forecast is for some snow tomorrow here in Columbus. One of my clients just last week shared it had taken a couple of months to get maintenance to test the back up generator. They finally went to fire it up to test that it worked and .... nothing. Tried again. Nothing. Their hardware vendor responded quickly. Turns out that the broken part was under warranty but was 48 hours away.
The test was conducted on one of those warm sunny days we had before Thanksgiving. We aren't supposed to get much snow tomorrow but you never know here in Ohio. Had the part failure not been found until it was actually needed the 48 hour shipping wait could have been catastrophic.
Our client did two things right:
1. They created a policy calendar. Policies should be formal statements of value supported by the routines (processes) that must be followed to meet the stated value. Most of the time though policies are dead documents that state something a client would like to do but doesn't get around to doing. My client's policy calendar lets them manage the normal routines of their "HIPAA year" which operationalizes their compliance.
2. They actually tested the process. The IT Director didn't take no for an answer as maintenance continued to put his test request off.
How are you doing?
Have you operationalized your HIPAA program?
Have you tested your generator, your back up processes and your contingency operations plan?
With compliance efforts the question is "Which way do we go?! And most times the signs are just this clear! Image by bob august via Flickr.
Two weeks ago, a financial services client of ours asked me “how compliant is compliant enough?”
They’ve been a good client for over 15 years. They are good people who care about their customers. They follow a disciplined approach to IT operations which provides a great foundation for their information security program.
At first, I was blown away by the comment.
How could they even consider such a question?
But the more I reflect on their comments and their situation, a new question has come to mind.
Who could blame them?
With the HITECH changes to HIPAA they unequivocally fall into the frame of HIPAA compliance. They by law are obligated to do more than they do now to secure their customer data.
They are doing a lot and doing it well, though they know they are not perfect.
Their wireless network is 100% impervious to outside invaders; they decided the risks of deploying outweighed the business risks of implementing wireless. Over 10 years of having 3rd party security assessments their technical team and technical infrastructure have consisently passed muster (ours wasn't the only firm evaluating them so the consistent findings were from multiple firms using multiple techniques and tests). A recent HIPAA Security Rule Gap Assessment Workshop that we facilitated found that from a HIPAA standpoint they were doing the vast majority of the controls in the security rule.
They are "doing" security but they don't document at a policy or procedure level what they do. Their staff is aware of security issues, but less so about privacy issues, particularly pertaining to information handling practices within the organization. In those 10 years of tests a couple of the assessors have been able to penetrate their physical security through social engineering. Security and privacy is an IT focused effort.
We believe that they are well secured against external attacks but are vulnerable to inside threats and accidents or to interuptions in their business process.
Fixing those business related issues all boils down to revenue versus expense, and they aren’t sure they can invest the time and treasure to attain perfect compliance.
And so the honest question is asked, “How compliant is compliant enough?”
Although they only ask one question, I suspect they had a few other questions they didn’t verbalize:
If we don’t do anything will we really get in trouble?
Will the government really enforce the law? They haven’t really yet have they?
If we do all this extra work won’t the work cost more than the likely fines we’ll pay if we don’t do the work?
Are our competitors doing it? Do our customers care?
In the time they’ve been wrestling with these questions they could have substantially closed the larger gaps in their program. But they are frozen by the uncertainty.
They are not the only client that is frozen by regulatory uncertainty.
Truly, with the way our government regulates information security and privacy I don’t have good answers for those questions.
Regulatory uncertainty is in and of itself a threat to privacy and security, and regulatory non-compliance is a risk that needs to be managed.
In the face of uncertain and confusing regulatory options most businesses in our experience choose to do nothing.
Regulatory uncertainty manifests itself in a number of ways:
Uncertainty due to a lack of knowledge about the potential regulations on the part of businesses
Uncertainty about just what various regulatory agencies are doing
Uncertainty about just what various regulatory agencies are going to do –
Uncertainty due to the myriad of fine line distinctions and confusion in the regulatory body
Uncertainty because of the confusion about which regulations apply to a particular firm or type of firm
All of these types of uncertainty are born out of poor communication, difficult language, sudden course corrections as rules are morphed in the political process even after they’ve been published,
The Red Flags Rule requires many businesses and organizations to implement a written Identity Theft Prevention Program designed to detect the warning signs — or "red flags" — of identity theft in their day-to-day operations. It was first passed in 2003. The FTC moved the enforcement date three times. Depending on whose view you take that was because they bent to lobbying from interest groups representing doctors, lawyers and higher education institutions OR they were listening to industry and adjusting the rules to meet the feedback they were getting. From either perspective the enforcement date continued to slip.
In December 2010, the law was amended with the Red Flag Program Clarification Act of 2010 to focus the law on its original intent.
(NOTE: Did you catch that last line: “Bookmark this site and check it often for revisions that reflect changes in the law.” Often? How often? Changes? What changes? How do I plan for those changes? Are you kidding me?)
HIPAA or the Health Insurance Portability and Accountability Act (HIPAA) of 1996. HIPAA has five titles covering an array of topics. Title II ironically known as Title II of HIPAA, ironically known as Administrative Simplification, primarily requires the establishment of national standards for electronic health care transactions . Administration Simplication also address the security and privacy of health data. The standards are meant to improve the efficiency and effectiveness of the nation's health care system by encouraging the widespread use of electronic data interchange in the U.S. health care system.
Based in part on the poor adoption rates of and loopholes in HIPAA, Congress passed HITECH.
HITECH the street version of the mouthful formal name Health Information Technology for Economic and Clinical Health (HITECH) Act, was enacted as part of the American Recovery and Reinvestment Act of 2009. It was signed into law in February, 2009. It primarily promotes the adoption and meaningful use of health information technologies such as Electronic Health Records (EHR). Within HITECH, Subtitle D addresses privacy and security concerns associated with the electronic transmission of health information primarily through a number of provisions that strengthen enforcement or clarify the original HIPAA rules.
Yet, uncertainty surrounding HIPAA is epic:
Poor enforcement impacted HIPAA adoption rates so HITECH was passed to provide stronger enforcement. We have seen an increase in enforcement action as well as an increase in awareness for breach events through HITECH’s breach reporting requirements but it has not reached a tipping point that catches decisions makers’ attention in a way that motivates them to act.
Rules that were to be out by now are not published. Rules have been published and pulled. Published dates have been moved around the calendar. We know that subcontractors are covered under the Security Rule but the rules have not been published. We know that there are mandatory audits required under HITECH but we don’t know exactly what that means.
Rules sometimes just don’t make sense. For instance, the Security Rule is focused on ePHI or electronic Protected Health Information. Think technical infrastructure. The Privacy Rule is focused on PHI in any form. Think use, handling and behavior. A fax is not considered ePHI though in most environments today many faxes come in and outbound through unified messaging. What is compliant action in regard to action
The government has produced an alphabet soup of laws, rules and regulations FERPA, Sarbanes-Oxley or SARBOX or SOX, GLBA, all with similar stories. And there are legislative efforts to move forward with a new batch of privacy and security laws covering related topics such as national cyber security, privacy, security standards and breach notification. With the continual onslaught of breaches the political will is building to enact and execute a national law focused on information security and privacy.
So into this clear as mud uncertainty we now have political activity driven by the epidemic of breaches that is leading us to a more laws, rules and regulations, and as I would suspect more uncertainty and with it more frozen clients caught between their fear to act and their fear not to act. And doing nothing puts them and their data at risk.
So we think the question isn’t “how compliant is compliant enough” but rather “how can we position our firm to lower compliance risk in light of this uncertainty while focusing on doing the right things to protect our customer and other critical data”
We suggest the following:
Stay focused on the basics. We recommend you start by defining a standard language for internal information security discussions. We at Jacadis like ISO 27001. The ISO 27000 series is an internationally recognized family of standards focused on turning information security, privacy and compliance into a management function. Adoption of ISO 27001 provides a framework and language from which to build top down, management to technical information security, privacy and compliance function within an organization. The framework will provide a standard way of managing security and once adopted assist in building resilience to changes in compliance standards while keeping you focused on protecting the most important information assets in your stewardship. For additional reading on ISO 27001 I suggest an IT toolbox article by Jacadis’ Jerod Brennan.
If you don’t have someone tracking the laws that affect your company, the cost to become compliant is going to hit you like a ton of bricks. Stay on top of it. Ounce of prevention is worth a pound of compliance, er… cure.
And while I don’t suggest you get get caught up with the what ifs and could bes as the legislative process moves forward. If you are an information intensive organization it is a good idea to have an executive level team member monitor the legislative process. You may find there is a moment that calls for your attention to get involved politically if legislation gets restrictive in a way that could impact your business.
If you are looking to answer that question and others surrounding your HIPAA compliance please join me on Wednesday, May 4th for Jacadis' webinar "Are you HIPAA Compliant"?
Preregister so we can expect you coming. I'll make sure we cover content specific to your type of business (provider, business associate, etc.).
If your company is "doing HIPAA" correctly and actually working toward complying with its security rule as a means to improve your information security program you'll at some point conduct a Risk Analysis. The Risk Analysis will require you gather information about where ePHI is collected, stored and processed in your organization. In working with clients conducting inventories we've found that requires answering two questions:
1. Where SHOULD ePHI be? Where do expect it to be collected, stored and processed? Where have you planned to work with ePHI within secure boundaries within business processes that support the requirements of the Privacy Rule.
2. Where is your PHI REALLY? Where does ePHI leak out of standard processes? Where does it go by accident, mistake or intention unknown to management? Data sent from clients to software firms providing tech support for EMR and other health related applications often ends up in account manager emails as well as in support tickets because those conduits represent the customer's best and easiest way in which to deliver the information. Each firm has its own unique unofficial data flow. If you don't identify this unofficial data flow and take steps to either redirect it, remove it or protect it, your Risk Analysis will be inaccurate and your likelihood of having a breach will go up.
"I don't want to know anything about HIPAA. I just want to be compliant.
Can't you just tell me what I need to do and then give me a certificate or something?"
So one of our sales reps was asked last week ...
To many an entrepreneur government regulatory requirements are simply a bother that gets in the way of us doing what we love in running our businesses.
In this case the firm in question is a Software as a Service provider in a niche part of the health care market. The business is under 5 people; the licensing for the service costs less than having a lawyer review each HIPAA BA agreement sent their way.
But because HIPAA compliance in how they protect and use the protected health information hosted in their application and touched by their staff during support interactions HIPAA is a part of the feature set. Like their desire to know Web 2.0 and other evolving technologies, knowledge of secruity and privacy
It isn't a whole lot different than a chef that just wants to create fabulous meals with no care or concern for a clean kitchen or the health inspector that is sure to come one day.
If you are going to play in the health care space providing services to HIPAA Covered Entities you must educate yourself and understand that part of your environment as much as you understand the technical and operational aspects of your business.
We provide services to educate companies of any size on the HIPAA Security and Privacy Rules, to assess how they stand in compliance with those rules and to plan for closing any gaps our assessments may uncover. We also help firms operationalize their HIPAA compliance because the law doesn't say "get there" in regards to compliance with the HIPAA Security and Privacy Rules but "get there, stay there" which means HIPAA must become a regular part of your day to day.
An integral part of our being able to help any company is a willingness to learn HIPAA and understand how it will impact your company.
An integral part of becoming and staying HIPAA compliance is a willingness to learn HIPAA and understand it on an ongoing basis.
In March, 2007, Piedmont Hospital in Atlanta earned the distinction of being the first institution in the country to be audited for compliance with the HIPAA Security Rule. Prior to the audit, according to a ComputerWorld scoop, Piedmont received a request for the information listed below.
Could you provide these items on request in a 10 day time frame?
Policies and Procedures:
Establishing and terminating users' access to systems housing electronic patient health information (ePHI).
Emergency access to electronic information systems.
Inactive computer sessions (periods of inactivity).
Recording and examining activity in information systems that contain or use ePHI.
Risk assessments and analyses of relevant information systems that house or process ePHI data.
Employee violations (sanctions).
Electronically transmitting ePHI.
Preventing, detecting, containing and correcting security violations (incident reports).
Regularly reviewing records of information system activity, such as audit logs, access reports and security incident tracking reports.
Creating, documenting and reviewing exception reports or logs. Please provide a list of examples of security violation logging and monitoring.
Monitoring systems and the network, including a listing of all network perimeter devices, i.e. firewalls and routers.
Physical access to electronic information systems and the facility in which they are housed.
Establishing security access controls; (what types of security access controls are currently implemented or installed in hospitals' databases that house ePHI data?).
Remote access activity i.e. network infrastructure, platform, access servers, authentication, and encryption software.
Internet usage.
Wireless security (transmission and usage).
Firewalls, routers and switches.
Maintenance and repairs of hardware, walls, doors, and locks in sensitive areas.
Terminating an electronic session and encrypting and decrypting ePHI.
Transmitting ePHI.
Password and server configurations.
Anti-virus software.
Network remote access.
Computer patch management.
HHS also had a slew of other requests:
Information Inventory
Please provide a list of all information systems that house ePHI data, as well as network diagrams, including all hardware and software that are used to collect, store, process or transmit ePHI.
Workforce
Please provide entity wide security program plans (e.g System Security Plan).
Please provide a list of terminated employees.
Please provide a list of all new hires.
Please provide a list of outsourced individuals and contractors with access to ePHI data, if applicable. Please include a copy of the contract for these individuals.
Please provide a list of all users with access to ePHI data. Please identify each user's access rights and privileges.
Please provide a list of systems administrators, backup operators and users.
Please provide a list of users with remote access capabilities.
Security Architecture and System Security Plan
Please provide a list of encryption mechanisms use for ePHI.
Please provide a list of authentication methods used to identify users authorized to access ePHI.
Please provide a list of transmission methods used to transmit ePHI over an electronic communications network.
Please include a list of antivirus servers, installed, including their versions.
Please provide a list of software used to manage and control access to the Internet.
Please provide the antivirus software used for desktop and other devices, including their versions.
Please provide a list of database security requirements and settings.
Please provide a list of all Primary Domain Controllers (PDC) and servers (including Unix, Apple, Linux and Windows). Please identify whether these servers are used for processing, maintaining, updating, and sorting ePHI.
Please provide a list of authentication approaches used to verify a person has been authorized for specific access privileges to information and information systems.
Assigned Security Responsibility
Please provide organizational charts that include names and titles for the management information system and information system security departments.
With the likely changes from HITECH we reasonably think an audit today would also require copies of your past Risk Analysises, your Evaluations, your Information Systems Activty Review process and documentation you do it as well as your incident response and breach notification plan.
Jacadis helps businesses prepare and respond to security questionnaires and audit requests from their usually larger customers. We also are the audit and assessment team for some firms who choose to use external resources to review their key vendors' security.
Frankly, as breaches Epsilon isn't a big of deal. No protected information, just names and email addresses were taken. And more sophisticated attacks have come and gone in the press largely unnoticed.
Epsilon has received more attention than the more impactful breaches in part because it touched so many people. Non techies are talking about it. We believe that buzz is going to find its way into the executive suites and audit teams of big companies and boost the rigor and frequency with which larger firms test, prod, and assess their supply partners.
Experts suggest that companies that outsource technology services take some of the following steps:
Make sure the vendor has a recognized certification for information security, such as ISO 27001 or SAS 70 Type 2, granted by an accredited auditing organization such as the International Standards Organization;
Sign agreements that oblige vendors to undergo regular audits by third parties, at least annually. Auditors should test software (especially software that can be accessed via the Internet) and hardware as well as people, to ensure that vendors’ employees themselves don’t fall prey to scams;
Make sure vendors assume liability for breaches that affect customers and end users; and
Make contingency plans with the vendor so that neither is caught by surprise in the event of a security breach.
Management consultants and corporate governance experts are providing similar advice to their Fortune 2000 and similarly sized customers. These recommendations have been around for several years, however, the buzz from Epsilon has the potential to fuel the recommendations to reality.
This will impact you if you answer yes to any of the questions below:
Your business is part of the supply or services chain for larger regulated firms. We see most of the third party verification activity from firms that have regulatory obligations to HIPAA; PCI, GLBA or other financial privacy rules, or Sarbanes-Oxley. We have seen these type of firms apply the highest security and privacy standards to their vendors even if their vendors don’t process confidential or protected information. Do you provide services to these types of firms?
Your business provides a service that includes considerably volatile information. If, for instance, you process non-protected personal information but it is somehow seen as critical to your client’s business or it’s relationship with its customers this might apply. Or, if, for another instance, you process company confidential information such as trade secret related information. Do you provide services to these types of firms?
Firms in the supply chain stack. You may not be doing business with a regulated firm, but you may be providing services to firms that provide goods or services to firms that provide services to regulated businesses. You know what they say about it rolling downhill. Are you at the bottom of a supply chain?
Take action
If you answered yes to any of those questions we suggest the following:
1. Look at your customer agreements with firms in the categories above.
Do any of those agreements place obligations on your company to protect your client’s information in a certain way?
Do they have the right to audit?
Have you told your IT team about these obligations?
Are you prepared to meet these obligations?
2. Sit down with your technical leadership and discuss:
Are we secure? Vulnerable? Do we follow a best practices approach to information security? Which one?
Do we routinely check through tests, assessments, and/or audits our answers to the questions above?
If we got an auditing letter from an existing customer would we be ready for the audit in a week? a month? 3 months?
When the auditor arrives do we have documentation that defines our security programs values (policies), details the routines we follow to meet those values (processes), shows that those routines are being followed (logs, action reports, scorecards, etc.) and that our staff is aware of their obligations (awareness training)?
If we committed during the sales process with a new customer to do certain things to secure their data did IT and the others in the company responsible for delivering on that obligation have a hand in the answer? Are we overcommitting?
Are we managing security well enough that we can create a competitive advantage over other firms in our class? Can we use that advantage to build new business?
If your business provides business to regulated businesses upstream in your market we recommend you keep asking these questions until you feel comfortable with the answers.
But the reality is that HIPAA Privacy Rule wasn't set out to be a destination but rather a journey. It isn't enough to 'BE" compliant but the expectation is to operate in compliance. Two hugely different approaches. My client had treated it as a destination, the "BE" compliant choice, had worked hard toward meeting the Privacy Rule in 2003s, but since 2003 had not attended to their obligations. They are not operating in compliance.
Are you in the same boat? Here are 3 questions that stand out as markers for how you are doing:
HIPAA requires regular training and updates on security and privacy (training requirements exist in both the Security Rule and the Privacy Rule). Have you trained your staff since 2003? Can you prove it when an auditor knocks on your door?
To operate in a compliant status you need to know the Privacy Impact of your business processes and functions. My client had understood this in 2003, but as processes had changed they had not updated their view of the privacy impact. Have your business processes using PHI (and ePHI) changed since 2003?
Documenting your privacy practices is a requirement under HIPAA. It is enormously important to be able to show to an auditor your work effort. For this client they didn't have much to show in the period between 2003 and now, but they were able to quickly produce the original documents from 2003. Our work effort to put them into an operational compliant mode won't require nearly as much investment because we have a sound starting point. Are you documenting your privacy practices under HIPAA?
How do we handle security and privacy complaints, reports and questions in a consistent, affordable manner?
I am working with a small long term facility company. They have 3000 employees serving beds in 5 facilities. They are working to become compliant with HIPAA and HITECH.
Problem
My client this week was struggling with how to best handle HIPAA security notifications, HIPAA privacy complaints, general HIPAA questions as well as other customer services issues. Their "old way" of doing it, originally created to meet compliance with the Privacy Rule in 2003, was to have a different number for each issue. No single office or employee was responsible for logging calls, tracking issues, etc. Their calls weren't high volume but it just takes 1 poorly handled complaint or report to create regulatory penalty chaos. They felt the risk wasn't being adequately managed.
Solution
They have decided to consolidate all of their HIPAA contact points as well as their general customer service contact points into the workload of their IT help desk. The IT help desk staff will be given HIPAA Security and Privacy training as well as some advanced custom training to help them triage calls and direct them to the proper internal resource. They will use their help desk ticketing system to log the calls. The Security and Privacy Officers at the organization will get reports as will the compliance committee. As issues are resolved they will be reported back to the help desk ticketing system as closed tickets.
Benefits:
They will save some money by consolidating phone lines as they today have seperate phone lines for several of the functions that are to be consolidated. They already have plans to implement a new help desk ticketing system. This consolidation will simply provide them an extension of the benefits from that seperate project. Had they already had that in place there wouldn't be any additional costs. They will make a small investment of time and dollars to train their help desk staff.
They have lowered their risks, improved their reporting performance, extended the value of the help desk staff to the company all for a minimal investment.
The regulatory burden on small and mid-sized business is substantial. Sometimes you can think your way around the added costs of a regulation by using existing assets for new purposes. Do you have assets already in place that you can leverage to meet the costs of compliance?
