Latest HIPAA News

Is AWS HIPAA Compliant?

Posted by HIPAA Journal

Is AWS HIPAA compliant? Amazon Web Services has all the protections to satisfy the HIPAA Security Rule and Amazon will sign a business associate agreement with healthcare organizations. So, is AWS HIPAA compliant? Yes. And No. AWS can be HIPAA compliant, but it is also easy to make configuration mistakes that will leave protected health information (PHI) unprotected and accessible by unauthorized individuals, violating HIPAA Rules.

Amazon Will Sign a Business Associate Agreement for AWS

Amazon is keen for healthcare organizations to use AWS, and as such, a business associate agreement will be signed. Under that agreement, Amazon will support the security, control, and administrative processes required under HIPAA.

Previous, under the terms of the AWS BAA, the AWS HIPAA compliance program required covered entities and business associates to use Amazon EC2 Dedicated Instances or Dedicated Hosts to process Protected Health Information (PHI), although that is now no longer the case.

As part of its efforts to help healthcare organizations use AWS safely and securely without violating HIPAA Rules, Amazon has published a 26 page guide – Architecting for HIPAA Security and Compliance on Amazon Web Services – to help covered entities and business associates get to grips with securing their AWS instances, and setting access controls.

AWS HIPAA Compliance is Something of a Misnomer

Amazon supports HIPAA compliance, and AWS can be used in a HIPAA compliant way, but no software or cloud service can ever be truly HIPAA compliant. As with all cloud services, AWS HIPAA compliance is not about the platform, but rather how it is used.

The Amazon Simple Storage Service (S3) that is provided through AWS can be used for data storage, data analysis, data sharing, and many other purposes. Data can be accessed from anywhere with an Internet connection, including via websites, and mobile apps. AWS has been developed to be secure, otherwise no one would use the service. But it has also been developed to make data easy to access, by anyone with the correct permissions. Make a mistake configuring users or setting permissions and data will be left exposed.

Just because AWS is HIPAA compliant, it does not mean that using AWS is free from risk, and neither that a HIPAA violation will not occur. Leaving AWS S3 buckets unprotected and accessible by the public is a clear violation of HIPAA Rules. It may seem obvious to secure AWS S3 buckets containing PHI, but this year there have been multiple healthcare organizations that have left their PHI open and accessible by anyone.

Amazon S3 buckets are secure by default. The only way they can be accessed is by using the administrator credentials of the resource owner. It is the process of configuring permissions and providing other users with access to the resource that often goes awry.

When is AWS not HIPAA Compliant?

When is AWS HIPAA compliant? When a BAA has been signed, users have been instructed on the correct way to use the service, and when access controls and permissions have been set correctly. Misconfigure an Amazon S3 bucket and your data will be accessible by anyone who knows where to look.

Documentation is available on the correct way to configure Amazon S3 services and manage access and permissions. Unfortunately, since there are several ways to grant permissions, there are also several points that errors can occur, and simple mistakes can have grave consequences.

On numerous occasions, security researchers have discovered unprotected AWS S3 buckets and have alerted healthcare organizations that PHI has been left unprotected. However, security researchers are not the only ones checking for unsecured data. Hackers are always on the prowl. It is far easier for a hacker to steal data from cloud storage services that have had all protections removed than it is to attack organizations in other ways.

One of the mistakes that has been made time and again is setting access controls to allow access by ‘authenticated users.’ That could be taken to mean anyone who you have authenticated to have access to your data. However, that is not Amazon’s definition of an authenticated user. An authenticated user is anyone with an AWS account, and anyone can obtain an AWS account free of charge.

How Common are AWS Misconfigurations?

AWS misconfigurations are very common. So much so, that Amazon recently emailed users who had potentially misconfigured their S3 buckets to warn them that data could be accessed by anyone.

Amazon said in its email, “We’re writing to remind you that one or more of your Amazon S3 bucket access control lists (ACLs) are currently configured to allow access from any user on the internet,” going on to explain, “While there are reasons to configure buckets with world read access, including public websites or publicly downloadable content, recently, there have been public disclosures by third parties of S3 bucket contents that were inadvertently configured to allow world read access but were not intended to be publicly available.”

Some of those public disclosures have been by healthcare organisations, but the list is long and varied, including military contractors, financial institutions, mobile carriers, entertainment companies, and cable TV providers. One data analytics firm left data unprotected, exposing the records of 200 million voters. Verizon exposed the data of between 6 and 14 million customers, and World Wide Entertainment exposed the data of 3 million individuals. Patient Home Monitoring, a HIPAA covered entity, left 47GB of data unprotected.

There is no excuse for these oversights. Checking for unprotected AWS buckets is not only a quick and easy process, software can be used free of charge for this purpose. A tool has been developed Kromtech called S3 Inspector that can be used to check for unsecured S3 buckets.

Is AWS HIPAA Compliant?

So, in summary, is AWS HIPAA compliant? Yes, it can be, and AWS offers healthcare organizations huge benefits.

Can the use of AWS violate HIPAA Rules and leave PHI unprotected? Very easily.

Would misconfiguration of AWS lead to a HIPAA violation penalty? That is a distinct possibility. AWS is secure by default. Only if settings are changed will stored data be accessible. It would be hard to argue with OCR auditors that manually changing permissions to allow anyone to access a S3 bucket containing PHI is anything other than a serious violation of HIPAA Rules.

The post Is AWS HIPAA Compliant? appeared first on HIPAA Journal.

New Tool Helps Healthcare Organizations Find HIPAA Compliant Business Associates

Posted by HIPAA Journal

Healthcare organizations are only permitted to use business associates that agree to comply with HIPAA Rules and sign a business associate agreement, but finding HIPAA compliant business associates can be a challenge.

Searching for HIPAA compliant business associates is time consuming, although identifying vendors willing to follow HIPAA Rules is only part of the process. Business associate agreements must then be assessed, often incurring legal fees, and healthcare organizations must obtain assurances from new business associate that appropriate safeguards have been implemented to ensure the confidentiality, integrity, and availability of any PHI they provide.

It is also challenging for vendors that wish to take advantage of the opportunities in the healthcare industry. They must be able to demonstrate they have implemented appropriate safeguards and need to provide reassurances that their products and services support HIPAA-compliance.

A solution has now been developed that resolves the issues for both parties and streamlines the process of finding HIPAA compliant business associates. Would-be business associates can also use the solution to prove that they have the necessary safeguards in place to ensure their products and services can be used without violating HIPAA Rules.

The HIPAA Alliance Marketplace is a closed ecosystem founded by the Compliancy Group, which serves as a repository for HIPAA-compliant vendors that can be used to connect medical professionals with trusted vendors.

HIPAA-covered entities can enroll and search the Marketplace for a broad range of service providers, including IT and Managed Service Providers (MSPs), medical billing and collections firms, software and application developers, cloud computing platforms, insurers, printing and mailing vendors, practice management firms, and EHR providers.

In order for a vendor to be included in the HIPAA Alliance Marketplace, they are first subjected to a strict vetting process, in which their services and solutions are assessed against HIPAA Rules. If the audit is passed, the vendor is issued with a HIPAA Seal of Compliance – a reassurance that the vendor has been thoroughly assessed and is a trusted supplier.

“The HIPAA Alliance Marketplace is the only tool of its kind for the health care market today,” said Marc Haskelson, President and CEO of Compliancy Group on the launch of their new HIPAA Alliance Marketplace. “In this climate of data breaches, ransomware, and cyber-security threats, health care providers can rely on the HIPAA Alliance Marketplace to find HIPAA compliant vendors with the security and privacy infrastructure in place to keep their data safe. Vendors can confidently execute Business Associate Agreements with their clients, and providers can be confident in their choice of vendors vetted and verified by the HIPAA Seal of Compliance.”

The post New Tool Helps Healthcare Organizations Find HIPAA Compliant Business Associates appeared first on HIPAA Journal.

Bad Rabbit Ransomware Spread Via Fake Flash Player Updates

Posted by HIPAA Journal

A new ransomware threat has been detected – named Bad Rabbit ransomware – that has crippled businesses in Russia, Ukraine, and Europe. While Bad Rabbit ransomware attacks do not appear to have been conducted in the United States so far, healthcare organizations should take steps to block the threat.

There are similarities between Bad Rabbit ransomware and NotPetya, which was used in global attacks in June. Some security researchers believe the new threat is a NotPetya variant, others have suggested it is more closely related to a ransomware variant called HDDCryptor. HDDCryptor was used in the ransomware attack on the San Francisco Muni in November 2016.

Regardless of the source of the code, it spells bad news for any organization that has an endpoint infected. Bad Rabbit ransomware encrypts files using a combination of AES and RSA-2048, rendering files inaccessible. As with NotPetya, changes are made to the Master Boot Record (MBR) further hampering recovery. This new ransomware threat is also capable of spreading rapidly inside a network.

The recent wave of attacks started in Russia and Ukraine on October 24, with attacks also reported in Bulgaria, Germany, Turkey, and Japan. ESET and Kaspersky Lab have analyzed the new ransomware variant and have established that it is being spread by drive-by downloads, with the ransomware masquerading as a Flash Player update.

The actors behind this latest campaign appear to have compromised the websites of several news and media agencies, which are being used to display warnings about an urgent Flash Player update. No exploits are believed to be involved. User interaction is required to download and run the ransomware.

Users that respond to the Flash Player warning download a file named “install_flash_player.exe.” Running that executable will launch the ransomware. After files have been encrypted and the MBR has been altered, the ransomware reboots the infected device and the ransom note is displayed.

The ransom amount is 0.5 Bitcoin ($280) per infected device. Victims must pay the ransom within 40 hours or the ransom will increase. Whether payment of the ransom allows files to be recovered is uncertain.

The ransomware is also spreading within networks via SMB, although no NSA exploits are believed to be used. Instead, the ransomware scans for network shares and uses Mimikatz to harvest credentials. The ransomware also cycles through a list of commonly used usernames and passwords. If the correct credentials are found, a file called infpub.dat is dropped and executed using rundll.exe. This process allows the ransomware to spread quickly within a network.

There have been at least 200 infections as of this morning, including the Kiev Metro, Odessa International Airport in Ukraine, the Ministry of Infrastructure of Ukraine, and the Russian Interfax and Fontanka news agencies.

Indicators of compromise have been released by Kaspersky Lab and ESET.

It is possible to vaccinate devices to prevent Bad Rabbit ransomware attacks. Kaspersky Lab suggests “restricting execution of files with the paths c:\windows\infpub.dat and C:\Windows\cscc.dat.” Alternatively, create those two files in the C:\\Windows\ directory and remove all permissions on those files for all users.  

The post Bad Rabbit Ransomware Spread Via Fake Flash Player Updates appeared first on HIPAA Journal.

FirstHealth Attacked with New WannaCry Ransomware Variant

Posted by HIPAA Journal

FirstHealth of the Carolinas, a Pinehurst, SC-based not for profit health network, has been attacked with a new WannaCry ransomware variant.

WannaCry ransomware was used in global attacks in May this year. More than 230,000 computers were infected within 24 hours of the global attacks commencing. The ransomware variant had wormlike properties and was capable of spreading rapidly and affecting all vulnerable networked devices. The campaign was blocked when a kill switch was identified and activated, preventing file encryption.  However, FirstHealth has identified the malware used in its attack and believes it is a new WarnnaCry ransomware variant.

The FirstHealth ransomware attack occurred on October 17, 2017. The ransomware is believed to have been introduced via a non-clinical device, although investigations into the initial entry point are ongoing to determine exactly how the virus was introduced.

FirstHealth reports that its information system team detected the attack immediately and implemented security protocols to prevent the spread of the malware to other networked devices. While the attack was detected rapidly, the ransomware did spread to other devices in the same work areas.

FirstHealth has issued a statement confirming the ransomware attack did not involve the encryption of patient information, and reports that its Epic EHR was unaffected. However, access to its Epic system has been blocked as part of its security protocol to prevent the encryption of patient data and the system is still inaccessible. The MyChart service is online, but no information has been uploaded to the system since the attack occurred.

Even though the attack was limited it has caused considerable disruption. FirstHealth has the arduous task of individually checking 4,000 devices spread across 100 locations to confirm they have not been infected with the virus – a process that will take a considerable amount of time.

FirstHealth is continuing to provide medical services to patients, although the health network has had to cancel some appointments and patients are experiencing delays due to the lack of access to its systems. FirstHealth said, “Our team is working tirelessly to remediate the virus and get our system back up to be fully operational.”

FirstHealth says a patch to address the vulnerability exploited by the new Wannacry ransomware variant has been developed and the patch is being applied on all vulnerable devices. FirstHealth said, “This patch will be added to anti-virus software available for others in the industry to apply to their systems,” suggesting it is not the same patch (MS17-010) that was made available by Microsoft in March to block the SMB flaw that the May 2017 WannaCry attacks exploited.

The post FirstHealth Attacked with New WannaCry Ransomware Variant appeared first on HIPAA Journal.

Employees Sue Lincare Over W2 Phishing Attack

Posted by HIPAA Journal

In February 2017, Lincare Holdings Inc., a supplier of home respiratory therapy products, experienced a breach of sensitive employee data.

The W2 forms of thousands of employees were emailed to a fraudster by an employee of the human resources department. The HR department employee was fooled by a business email compromise (BEC) scam. While health data was not exposed, names, addresses, Social Security numbers, and details of employees’ earnings were obtained by the attacker.

This year has seen an uptick in W2 phishing scams, with healthcare organizations and schools extensively targeted by scammers. The scam involves the attacker using a compromised company email account – or a spoofed company email address – to request copies of W2 forms from HR department employees.

Cyberattacks that result in the sensitive data of patients and consumers being exposed often results in class action lawsuits, although it is relatively rare for employees to take legal action against their employers. Lincare is one of few companies to face a lawsuit for failing to protect employee data.

Three former Lincare employees whose PII was disclosed in February have been named in a class-action lawsuit against the firm. The plaintiffs are seeking damages for the exposure of their PII, credit monitoring and identity theft protection services for 25 years, and 25 years of coverage by an identity theft insurance policy. Lincare previously offered 24 months of complimentary credit monitoring and identity theft protection services to employees affected by the incident.

The plaintiffs claim Lincare was negligent for failing to implement “the most basic of safeguards and precautions,” such as training its employees how to identify phishing scams. The plaintiffs allege the HR employee failed to authenticate the validity of the request for W2 forms, instead just attaching the information and replying to the email.

In the lawsuit, the plaintiffs argue that had simple security measures been adopted by Lincare the breach could have been easily prevented. Those measures include the use of advanced spam filters, providing information security training to staff, implementing data security controls that prohibit employees having on-demand access to PII, adding multiple layers of computer system security and authentication, and ensuring PII was only sent in encrypted form.

The risk of the PII being used to commit fraud is not theoretical. The attacker has already used the stolen data to apply for credit and loans. The lawsuit points out that Lincare sent an email to staff on April 21 saying, “Current and/or former employees affected by the data breach had already had their PII used by a third party or parties as part of a fraudulent scheme to obtain federal student loans through the Department of Education’s Free Application for Federal Student Aid.”

The question that the courts will need to answer is to what extent Lincare is liable for the attack, whether additional safeguards should have implemented and whether there was an implied agreement that the company would keep employee information secure.

The post Employees Sue Lincare Over W2 Phishing Attack appeared first on HIPAA Journal.

Beazley Publishes 2017 Healthcare Data Breach Report

Posted by HIPAA Journal

Beazley, a provider of data breach insurance and response services, has published a special report on healthcare data breaches covering the first nine months of 2017.

While hacking and malware attacks are common, by far the biggest cause of healthcare data breaches in 2017 was unintended disclosures. Hacking and malware accounted for 19% of breaches, while unintended disclosures accounted for 41% of incidents. The figures show healthcare organizations are still struggling to prevent human error from resulting in the exposure of health data.

As Beazley explains in its report, it is easier to control and mitigate internal breaches than it is to block cyberattacks by outsiders, yet many healthcare organizations are failing to address the problem effectively. “We urge organizations not to ignore this significant risk and to invest time and resources towards employee training.”

Beazley notes that the number of cases of employee snooping on records and other insider incidents is getting worse. This time last year, 12% of healthcare data breaches were insider incidents, but in 2017 the percentage has increased to 15%.

While it is not possible to eliminate the risk of healthcare employees improperly accessing patient records, it is straightforward to ensure that when incidents occur they are detected quickly. As the Protenus Breach Barometer reports clearly show, many healthcare employees have been discovered to have been improperly accessing patient health data for months or even years before the unauthorized access is detected. As Beazley points out in the report, the failure to detect insider incidents promptly and take action increases the risk of regulatory action.

Phishing and social engineering attacks also increased significantly in 2017. There has been a 9-fold increase in social engineering scams in 2017. Beazley reports that two types of social engineering attacks in particular have increased in 2017 – Fraudulent instruction incidents and W-2 Form phishing scams.

Fraudulent instruction incidents are a type of Business Email Compromise (BEC) scam where the attacker pretends to be a company executive and sends a request to make a bank transfer. W-2 Form phishing scams similarly involve the spoofing of a company email address. In this case a request is made to send the W-2 forms of all employees that have worked in the previous fiscal year. The information is then used to submit fraudulent tax returns. Healthcare organizations can reduce risk by teaching employees how to recognize these types of email scams.

Along with an increase in data breaches, there has also been an increase in HIPAA enforcement actions by the Department of Health and Human Services’ Office for Civil Rights (OCR). The report notes that there have been nine settlements announced so far in 2017 on top of 13 HIPAA settlements in 2016. In 2014 and 2015 there were 13 settlements.

There has also been a notable increase in settlement amounts. In 2014/2015, the average settlement amount was around $1,000,000. In 2016/2017, the average settlement was $1.8 million.

As Beazley explained in the report, experiencing a breach opens the door to OCR investigators. Part of the OCR breach investigation involves a review of basic HIPAA compliance. When noncompliance is discovered, financial penalties may be deemed appropriate.

Beazley explains there are two main reasons for the increase in settlements for noncompliance with HIPAA Rules: OCR’s growing frustration with covered entities that are still failing to comply with the HIPAA Privacy and Security Rules, and more available resources to devote to pursuing settlements.

The post Beazley Publishes 2017 Healthcare Data Breach Report appeared first on HIPAA Journal.

HHS Issues Limited Waiver of HIPAA Sanctions and Penalties in California

Posted by HIPAA Journal

The Secretary of the U.S. Department of Health and Human Services has issued a limited waiver of HIPAA sanctions and penalties in California. The waiver was announced following the presidential declaration of a public health emergency in northern California due to the wildfires.

As was the case with the waivers issued after Hurricanes Irma and Maria, the limited waiver of HIPAA sanctions and penalties only applies when healthcare providers have implemented their disaster protocol, and then only for a period of up to 72 hours following the implementation of that protocol. In the event of the public health emergency declaration ending, healthcare organizations must then comply with all provisions of the HIPAA Privacy Rule for all patients still under their care, even if the 72-hour period has not yet ended.

Whenever the HHS issued a limited waiver of HIPAA sanctions and penalties, healthcare organizations must still comply with the requirements of the HIPAA Security Rule and the Privacy Rule is not suspended.  The HHS simply exercises its authority under the Project Bioshield Act of 2004 (PL 108-276) and section 1135(b) (7) of the Social Security Act, and will not impose sanctions or penalties against healthcare organizations for the following provisions of the HIPAA Privacy Rule:

  • 45 CFR 164.510(b) – The requirements to obtain a patient’s agreement to speak with family members or friends involved in the patient’s care.
  • 45 CFR 164.510(a) – The requirement to honor a request to opt out of the facility directory.
  • 45 CFR 164.520 – The requirement to distribute a notice of privacy practices.
  • 45 CFR 164.522(a) – The patient’s right to request privacy restrictions.
  • 45 CFR 164.522(b) – The patient’s right to request confidential communications.

Even in emergency situations, the HIPAA Privacy Rule permits HIPAA-covered entities to share patients’ PHI to assist in disaster relief efforts and to help ensure patients receive the care they need.

PHI may also be disclosed for the purpose of providing treatment to patients, in order to coordination patient care, or when referring patients to other healthcare providers.  PHI can be shared for public health activities to allow organizations to carry out their public health missions. Disclosures can be made to family members, friends, and other individuals involved in a patients’ care, as necessary, to identify, locate, or notify family members of the patient’s location, condition, or loss of life. Disclosures can be made to anyone, as necessary, to prevent or lessen a serious injury and disclosures can be made to the media about a patient’s general health status and limited facility directory information can also be disclosed for a named patient, provided the patient has not objected to such disclosures.

In all cases, the ‘minimum necessary’ standard applies. Information should be restricted to the minimum necessary information to achieve the specific purpose for which it is disclosed.

Further information on the waiver can be found in the HHS bulletin on this link.

The post HHS Issues Limited Waiver of HIPAA Sanctions and Penalties in California appeared first on HIPAA Journal.

Q3, 2017 Healthcare Data Breach Report

Posted by HIPAA Journal

In Q3, 2017, there were 99 breaches of more than 500 records reported to the Department of Health and Human Services’ Office for Civil Rights (OCR), bringing the total number of data breaches reported in 2017 up to 272 incidents. The 99 data breaches in Q3, 2017 resulted in the theft/exposure of 1,767,717 individuals’s PHI. Up until the end of September, the records of 4,601,097 Americans have been exposed or stolen as a result of healthcare data breaches.

Q3 Data Breaches by Covered Entity

Healthcare providers were the worst hit in Q3, reporting a total of 76 PHI breaches. Health plans reported 17 breaches and there were 6 data breaches experienced by business associates of covered entities.

There were 31 data breaches reported in July, 29 in August, and 39 in September. While September was the worst month for data breaches, August saw the most records exposed – 695,228.

The Ten Largest Healthcare Data Breaches in Q3, 2017

The ten largest healthcare data breaches reported to OCR in Q3, 2017 were all the result of hacking/IT incidents. In fact, 36 out of the 50 largest healthcare data breaches in Q3 were attributed to hacking/IT incidents.

Covered Entity Entity Type Number of Records Breached

Type of Breach
Women’s Health Care Group of PA, LLC Healthcare Provider 300,000 Hacking/IT Incident
Pacific Alliance Medical Center Healthcare Provider 266,123 Hacking/IT Incident
Peachtree Neurological Clinic, P.C. Healthcare Provider 176,295 Hacking/IT Incident
Arkansas Oral & Facial Surgery Center Healthcare Provider 128,000 Hacking/IT Incident
McLaren Medical Group, Mid-Michigan Physicians Imaging Center Healthcare Provider 106,008 Hacking/IT Incident
Salina Family Healthcare Center Healthcare Provider 77,337 Hacking/IT Incident
Morehead Memorial Hospital Healthcare Provider 66,000 Hacking/IT Incident
Network Health Health Plan 51,232 Hacking/IT Incident
St. Mark’s Surgical Center, LLC Healthcare Provider 33,877 Hacking/IT Incident
Sport and Spine Rehab Healthcare Provider 31,120 Hacking/IT Incident

Main Cause of Healthcare Data Breaches in Q3, 2017

For much of 2017, the main cause of healthcare data breaches was unauthorized disclosures by insiders, although in Q3, 2017, hacking was the biggest cause of healthcare data breaches. These incidents involve phishing attacks, malware and ransomware incidents, and the hacking of network servers and endpoints. These hacking incidents involved the exposure/theft of considerably more data than all of the other breach types combined. In Q3, 1,767,717 healthcare records were exposed/stolen, of which 1,578,666 – 89.3% – were exposed/stolen in hacking/IT incidents.

Location of Breached PHI

If vulnerabilities exist, it is only a matter of time before they will be discovered by hackers. It is therefore essential for HIPAA covered entities and their business associates conduct regular risk assessments to determine whether any vulnerabilities exist. Weekly checks should also be conducted to make sure the latest versions of operating systems and software are installed and no patches have been missed. Misconfigured servers, unsecured databases, and the failure to apply patches promptly resulted in 31 data breaches in Q3, 2017.

In Q3, 34 incidents were reported that involved email. While some of those incidents involved misdirected emails and the deliberate emailing of ePHI to personal email accounts, the majority of those breaches saw login details disclosed or ransomware/malware installed as a result of employees responding to phishing emails.  The high number of phishing attacks reported in Q3 shows just how important it is to train employees how to recognize phishing emails and how to report suspicious messages. Training should be an ongoing process, involving classroom-based training, CBT sessions, and phishing simulations, with email updates sent to alert employees to specific threats.

The post Q3, 2017 Healthcare Data Breach Report appeared first on HIPAA Journal.

Bill Introduced to Standardize State Data Breach Notification Laws

Posted by HIPAA Journal

The HIPAA Breach Notification Rule explains how HIPAA covered entities and their business associates’ data breach response should include issuing notifications to patients, plan members and the HHS’ Office for Civil Rights. Healthcare organizations must also comply with state data breach notification laws, which in some U.S. states, requires notifications to be issued more rapidly. Those laws cover different types of information, have additional notification requirements, and in some states, require credit monitoring and identity theft protection services to be offered to breach victims.

Currently, there are 48 separate state data breach notification laws. For a small health system operating in one or two states, keeping up to date with relevant state data breach notification laws is straightforward. For large health systems and health plans that operate in multiple states, keeping up to date with changes to state laws, and ensuring compliance with those laws, can be a challenge.

Bill Proposes Standardization of State Data Breach Notification Laws

Congressman Jim Langevin (D-RI) has recently re-proposed a bill (H.R. 3806) – The Personal Data Breach Notification Act – that will standardize data breach protection laws and will ensure all consumers are notified of breaches promptly, regardless of where they live.

Rather than have separate state data breach notification laws, the Personal Data Breach Notification Act will introduce a national data breach notification standard that must be followed by all states. The Personal Data Breach Notification Act would apply to all organizations or entities that collect the data of more than 10,000 individuals over a 12-month period and the provisions of the Personal Data Breach Notification Act will supersede any provision of the law of any State.

Not only will the bill make it easier for businesses to understand what they are required to do following a data breach, Langevin explains it will “strengthen companies’ obligations to report intrusions that compromise consumers’ personal information.”

30 Day Time Limit for Issuing Breach Notifications

Currently, state data breach notification laws require notifications to be issued to consumers as soon as possible following the discovery of a breach, although the maximum timescale for issuing those notifications differs from state to state, and the speed of notification also depends on which entity experienced the breach.

The Personal Data Breach Notification Act will standardize notifications and will ensure consumers are informed of a breach of their personal information faster. The proposed maximum time limit to issue notifications is 30 days from the discovery of the breach, although the bill states there should be no unreasonable delay in issuing notifications.

Additional time may be granted to breached entities in certain circumstances, although a request for an extension would have to be made to the Federal Trade Commission, which would be responsible for enforcing the Personal Data Breach Notification Act.

As with HIPAA breach notifications, a request could be made by law enforcement to delay the issuing of notifications so as not to impede with an investigation. In such cases, the Director of the United States Secret Service or the Director of the Federal Bureau of Investigation would be permitted to authorize a delay of up to 30 days – meaning a maximum time frame of 60 days from the discovery of a breach.

Data Elements Covered by the Personal Data Breach Notification Act

The definition of a breach is defined as “a compromise of the security, confidentiality, or integrity of, or the loss of, computerized data that results in, or there is a reasonable basis to conclude has resulted in: i) the unauthorized acquisition of sensitive personally identifiable information; or (ii) access to sensitive personally identifiable information that is for an unauthorized purpose, or in excess of authorization.”

The exposure of the following information would require breach notifications to be issued.

Currently, state data breach laws require the breached entity to issue a notification to state attorneys general of any breach of personal information. If the Personal Data Breach Notification Act is passed, a government agency would be required to be designated to receive the breach notification reports.

Notifications could be made by mail, telephone, or email, with the latter only permissible if individuals consent to receiving electronic notifications.

As with HIPAA, a media notice must also be issued, although rather than the threshold being 500 individuals, the Personal Data Breach Notification Act would only require a media notice to be issued if the breach impacts 5,000 or more individuals.

The failure to comply with the Personal Data Breach Notification Act could result in financial penalties. The FTC would be able to issue financial penalties with the penalty structure the same as for Federal Trade Commission Act violations. State attorneys general would also be permitted to enforce compliance and take action against entities that breach the Personal Data Breach Notification Act.

The post Bill Introduced to Standardize State Data Breach Notification Laws appeared first on HIPAA Journal.