Organizational Governance and Risk Acceptance

Managing HIPAA Security Compliance:Organizational Governance and Risk Acceptance

One of the fundamental but sometimes overlooked questions in HIPAA Security Rule compliance is, who decides how much residual security risk the organization will accept? The level at which this decision is made can have important consequences not just for the acceptance of HIPAA security compliance measures within the organization, but for the cost-effectiveness of the safeguards selected for compliance and the organization’s ability to defend itself and its officers against civil penalties or criminal charges if its personnel do violate HIPAA’s information protection requirements.
The level at which security risk acceptance authority is vested depends on how the issue is perceived. Senior executives, auditors and legal counsel and board members may not understand or be comfortable with information security issues, and may perceive them as matters of technical implementation. They may therefore explicitly, or perhaps more often implicitly and by default, delegate decisions about such issues to security professionals they consider more qualified to deal with such problems. Some security professionals may be quite willing to accept such delegation, not recognizing that it may be inappropriate – maybe not really recognizing that it is occurring – perhaps even seeing it as a positive enhancement of their power and authority.
Risk Management: In the Eye of the Beholder?

The inappropriate delegation of risk acceptance authority may be particularly likely to occur under the HIPAA Security Rule because of the way it uses the term “risk management.” The Rule specifies that compliance decisions – the selection of safeguards which are “reasonable and appropriate” for addressing risks under the standards and specifications set forth in the rule – are to be made using a risk assessment-based risk management process. “Risk management,” however, can mean different things to different professions, creating a real possibility of confusion and a dysfunctional approach to compliance.
For organizational governance purposes, “risk management” generally means

. . . a policy process wherein alternative strategies for dealing with risks are weighed and decisions about acceptable risks are made. . . . In the end, an acceptable level of risk is determined and a strategy for achieving that level of risk is adopted. Cost-benefit calculations, assessments of risk tolerance, and quantification of preferences are often involved in this decision-making process.

Confusingly, however, the HIPAA Security Rule and many (by no means all) security professionals give the term “risk management” a much more limited meaning, as the implementation of “security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” Security “risk management” under the latter definition is therefore equivalent to risk reduction at the organizational level – a process which depends upon the prior determination of the acceptable risk level to be achieved by the reduction.
Information technology security risks cannot as a practical matter be reduced to zero, nor does the HIPAA Security Rule require “zero risk tolerance.” The rule does require that healthcare organizations “take steps, to the best of [their abilities,] to protect [protected health information in electronic form].” This requirement is based on an interpretation that in the legislation Congress intended to set “an exceptionally high goal for the security of electronic protected health information” but “did not mean providing protection, no matter how expensive.” Covered Entities are therefore permitted to use a “flexible approach” to security measure implementation which permits them to implement “any” measures which are “reasonable and appropriate,” taking organizational circumstances and factors including costs into account.
At the end of this process residual risks will have to be accepted by some party on behalf of an organization. Compliance with the rule is itself an organizational obligation, and the organization is exposed to civil and potentially even criminal penalties in the event of a compliance failure. Since acceptance of residual risks necessarily means the acceptance of some degree of exposure to potential penalties – even if the organization makes its compliance decisions properly and in good faith there is a possibility that enforcement authorities will disagree with them – this decision should only be made as a matter of organizational policy.

Fiduciary Obligations and Security Risk Acceptance.

It is a truism that the officers and directors of an organization have fiduciary obligations to provide oversight to ensure it complies with regulatory obligations. What is perhaps less well understood is that a failure to exercise such oversight could itself be a factor exposing an organization to avoidable legal penalties.
HIPAA provides not only for a regulatory regime, but for criminal penalties for organizations which obtain or disclose protected health information (“PHI”) in violation of the statute or the regulations. (Individuals can be subject to criminal penalties too, but this article is concerned with organizations.) Healthcare organizations obtain and disclose PHI constantly – it’s a necessary part of most operations – which means that a failure to comply with the HIPAA Security Rule in the course of operations involving PHI is a per se criminal violation. For example, the rule presumes that all personnel will receive appropriate security training, and requires that all information system users be assigned unique user names or other identifiers. Any receipt or disclosure of PHI by an untrained user, or by a user who is allowed to log-in under another user’s identifier, could be considered a criminal HIPAA violation by the organization.
This may seem a somewhat extreme reading of the statute, but it is the result of its literal interpretation. Whether charges are ever brought against a healthcare organization which fails to comply with the HIPAA Security Rule will therefore generally be a function of whether the failure has been brought to the attention of the U.S. Department of Justice (which has federal criminal jurisdiction), and if so whether the U.S. Attorney elects to bring charges. While it is to be hoped that prosecutors will exercise their discretion cautiously in such cases, hope is not a prudent strategy for legal compliance.
A better strategy, and one which is recognized in federal criminal sentencing and prosecution decisions against organizations, is to implement a compliance program including organizational policies and board and executive-level oversight. The existence and good faith, reasonable management of such a program is a very material factor relied on by the U.S. Department of Justice in deciding against organizational prosecution when one of its employees or agents breaks the law, and in minimizing penalties if the organization is prosecuted.
More than that, a compliance program would constitute the kind of policy-level security risk management process necessary to determine acceptable levels of risk at the organizational level under the HIPAA Security Rule, which in turn would guide decisions about the reasonable and appropriate safeguards which the organization should implement. By instituting this process the organization would be able to ensure that “reasonable and appropriate” decisions are made, in reliance on the “flexible approach” factors required by the rule. Upon the implementation of safeguards selected under such guidance, the organization will have both brought itself into compliance with the HIPAA Security Rule. While risks cannot be eliminated through such a process, if and when an incident does occur which could expose the organization to penalties it will have a sound defense.
Organizational Risk Acceptance and Security Cost Control.

While the potential consequences are perhaps less dire than criminal penalties, inappropriate delegation of risk acceptance authority may also lead to excessive spending on security safeguards and inappropriately burdensome compliance decisions. This can be demonstrated by analyzing alternative compliance decision-making approaches under one of the more problematic security standards.
The HIPAA Security Rule requires a Covered Entity to “identify[,] respond to[,] mitigate the harmful effects of [and] document security incidents and their outcomes.” A “security incident” in turn is defined as an “attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.” A risk reduction perspective might well interpret these provisions to require that any and every event which meets this definition must be dealt with according to the specification. But anybody familiar with systems administration in a large enterprise knows that events which fit this definition happen constantly.
At a very basic level network connections, particularly ports accessible to the Internet, are constantly “pinged” by unknown and presumably unauthorized applications or individuals. Each such attempted connection is “attempted unauthorized access” within the regulatory definition of “security incident.” They are also almost always harmless, assuming basic security safeguards have been implemented. Nonetheless compliance with the letter of the regulation would require each one to be identified, responded to and documented.
This would seem to be a pointless exercise in security log review and documentation, except that the failure to do so could be construed as a meaningful failure if some evildoer were to succeed in gaining access through such connections – and if the regulation is interpreted to require “zero risk tolerance” it could be evidence of negligence.
Since it is also not possible to rule out the risk that someone will succeed in hacking in to your network, a zero risk tolerance approach would require the routine review of all relevant system event logs, and the documentation of all apparent attempts at unauthorized access as required by the regulation. And such documentation is presumably subject to the 6-year HIPAA document retention requirement. If the Security Rule is interpreted as requiring zero risk tolerance, however, this burdensome approach is appropriate, even though the risks presented by attempted unauthorized access would be much better addressed through good system management practices.
This would be the approach under a definition of “risk management” as equivalent only to risk reduction at the system level. But if, instead, HIPAA Security Rule compliance is a function of considered organizational risk management, it is possible to determine a level of risk which can and should be accepted – and the burdens of compliance can be appropriately balanced against their benefits.
Conclusion.

The risk acceptance decision is the key to the risk management process which is the foundation of HIPAA Security Rule compliance, and as seen above such decisions should be vested at the organizational policy level. The vesting of risk acceptance authority at a lower administrative level, expressly or by default, may well lead to dysfunctional security safeguard selections, and expose the organization to avoidable penalties.
This does not mean that the board, or CEO, COO or CFO for that matter, should micromanage HIPAA compliance or security administration. It does mean that they should fulfill their fiduciary obligations and provide guidance to those who do manage compliance and security. They should receive routine briefings on the status of security and compliance, and establish policies and procedures intended to ensure compliance. Such policies should include guidance on risk acceptance, perhaps requiring CEO or COO approval for acceptance of residual risks above certain thresholds of probability and financial exposure, and vesting risk acceptance discretion in the Chief Information Security Officer (or equivalent title) below those thresholds. Since the security program budget will also be generally determined at the organizational policy level this will also tend to prevent overspending – and where a bigger budget is necessary to reduce risks to organizationally acceptable levels, the decision will be forced upward to the level best suited to balance budgetary and security issues and needs.
Such an approach also requires organizational policy-makers to overcome any reluctance to address security issues on an informed basis, and requires security officers to overcome any tendencies they may have to build their own fiefdoms. Given the considerable and increasing importance of information security for information technology-dependent organizations, however, policy oversight is essential and the separation of security from operations is dysfunctional. HIPAA Security Rule compliance is therefore an opportunity for such organizations to “do well by doing good” – to learn to function better while ensuring they comply with the law – for those who will take it as such.

Related Posts

10/03/2011

More HIPAA/HITECH and Joint IT Environments: Multiple Account Access

I’ve had some interesting follow-up from my previous posting about HIPAA/HITECH and cloud computing. One question was about my statement that users authorized by one Covered Entity whose Protected Health Information and applications are hosted in a joint IT environment shouldn’t have access to the Protected Health Information and applications of other Covered Entities hosted […]

Read story
10/03/2011

Preliminary Thoughts on the HITECH/HIPAA NPRM: Modifications to the HIPAA Privacy, Security, and Enforcement Rules under the Health Information Technology for Economic and Clinical Health Act

The Notice of Proposed Rule Making (“NPRM”) for the proposed new regulations amending the HIPAA regulations as required by HITECH have just been informally published here. The formal publication date in the Federal Register is probably going to be July 14, 2010. This is a brief heads-up on a few issues the NPRM seems to […]

Read story