Debriefing The PHI Report: Determining The True Cost Of A Data Breach

March 23, 2012

DEBRIEFING THE PHI REPORT: DETERMINING THE TRUE COST OF A DATA BREACH

By Jenny Laurello

This week I had the chance to listen to a webinar highlighting the recently released report on The Financial Impact of Breached Protected Health Information. Released on March 5, the “PHI Report” has already been downloaded by more than 1,700 users, with its goal being to help health care organizations both assess security risks, as well as build a business case for protected health information (PHI) security processes, procedures, technologies and executive buy-in.

Created through the PHI Project, a collaboration on behalf of the American National Standards Institute (ANSI), in partnership with Shared Assessments and ISA, the publication takes an extensive look at why organizations are breaching PHI information – and, interestingly enough, at three times the rate of other industries, such as banking and finance. It also includes step by step guidance for organizations to calculate the true cost of a data breach using the “PHIve,” or PHI value estimator, an approach based on the success of prior, similar initiatives, such as ASNI’s 2008 Financial Impact of Cyber Risk report.

For this project, the group honed in specifically on health care, bringing together over 100 CIOs, CFOs, chief compliance officers, chief security officers and general counsel from various health organizations to ask and discuss 50 key questions on what must be done to ensure the security of PHI data. What they discovered was chief privacy and compliance officers were quick to bring up the changes in liabilities and initiatives that they felt needed to be done based on their work so far and to ensure compliance at the federal level. Unfortunately though, without the proper financial language and hard figures to support it – i.e. in the absence of CFO speak — it can be nearly impossible to communicate the value of these projects and create a business case for investment.

To rectify this enterprise language barrier and help IT and security leaders build a case for resource allocation, the project’s subcommittees began working with a team of professionals to define the PHI ecosystem (i.e., anyone who generates, stores, recovers, distributes or in any way handles an electronic record). They also worked to identify the main elements threatening PHI security; in this instance as garnered through the case studies of 40 recent health care data breaches. From this, they determined the top four areas threatening the privacy and security of PHI data are:

Humans: People pose the greatest risk to the breach of PHI, including malicious insiders, non-malicious insiders, outsiders and state-sponsored cyber crime. Of the cases studied in the report, almost half involved an organizational insider, with 90% of those being deliberate.

Intrusion: Through the dissemination of data, mobile devices and wireless devices

With the number of threats and vulnerabilities that exist in the ecosystem, coupled with the hard and fast proof via the growing list of data breach poster children on the OCR’s site, it was clear to the group that they needed to develop a series of standards, safeguards and controls for organizations to implement and follow. And while each organization’s compliance program will vary depending on specific security requirements, the report identifies three universal aspects that anyone can use:

1. Policy: The culture of the organization is established at the top, and the importance of privacy and security programs at the enterprise level needs to be communicated through the creation and enforcement of policies.

2. Procedures: It’s one thing to establish a policy, but it’s another thing to follow it. Clearly outlined procedures ensure the effectiveness of key controls and that everyone is working under the same set of established, enforced rules and guidelines.

3. Technologies: As required by the Security Rule, organizations must have access and audit controls, as well as transmission security technologies in place. Without the technology to help ensure the security of the electronic data, the policies and procedures are merely a start.

After an organization establishes its security policy, determines an agreed upon set of actionable procedures and has implemented the proper technical controls and safeguards, the next step is packaging this information and using it to enhance their business case for resources.

As detailed in the report, the PHIve Method details the steps necessary to calculate the true cost of a data breach:

Step 1: Conduct a risk assessment for each PHI home – Assess risks and vulnerabilities to develop applicable safeguards and controls for each stakeholder in the “PHI home,” which the report defines as “any organizational function or space (administrative, physical or technical) and/or any application, network, database or system (electronic) that creates, maintains, stores, transmits or disposes of ePHI or PHI.”

Step 2: Determine a “Security Readiness Score”- Determine the likelihood of a data breach and assign a “security readiness code.”

Step 3: Determine the cost of “relevance”- Taking into consideration type of business (CE vs. BA), size of breach, likelihood of harm, type of data, as well as age and income of affected individuals.

Step 5: Calculate the total cost of a breach – Refers to the total cost of a data breach, calculated by adding up all adjusted costs for various PHI homes. The report also identifies ranges of impact, which go from “severe,” impacting greater than 6% of revenue, to “insignificant,” affecting less than 2% revenue impact.

In the age of EHRs and electronic data exchange, organizations must make investing in their IT security and data protection initiatives a top priority. With the growing market attractiveness of patient medical information — with one medical record being worth $50 as compared to just $1 per social security number – and the growing number of vulnerabilities in the ecosystem, a solid risk assessment is simply a small component of the larger framework that makes up health IT security preparedness.