Password Guidance

We’ve seen a lot of bogus password guidance lately. We’d like to take this opportunity to help set the record straight.

Did you know that the password “September2018!” fits commonly accepted password complexity rules? It contains at least one uppercase character, at least one lowercase character, at least one number, and at least one special character. For the end user, we completely understand the want to use passwords that are easily memorable, especially when your organization enforces antiquated password aging rules.

It is the opinion of Aligned Risk Management that password aging rules are dangerous because they encourage bad behavior from end users.

It is the opinion of Aligned Risk Management that password complexity rules are dangerous because they provide a false sense of security.

Our password policy is based on the ARM password triad mantra: all passwords must be (1) long, (2) unique, and (3) random.

“FourScoreAndSevenYearsAgo” is a long password. But it is neither unique, nor is it random. Try again.

“4vd23swds3” is a random password and is a unique password, but it is not long. It’s only ten characters. I have more digits on my hands and feet.

“SweepSlaveryDespairHouse4” is a long, unique, and random password. Well, it was unique, before we published this post, so don’t use it. Use the free password generator Correct Horse Battery Staple for strong, memorable passwords. http://correcthorsebatterystaple.net/

“Sweep slavery despair house4” is a long, unique, and random password. Well, it was unique, before we published this post, so don’t use that. But it’s a great example of a strong password. Use our free password generator for strong, memorable passwords: www.riskaligned.com/passwords

While they are arguably more susceptible to dictionary attacks, these passwords are infinitely more secure than “September2018!”. The tradeoffs are that each end user now creates a truly secure password, in exchange for not having to reset their password every 90 days. That, and…

USE TWO FACTOR AUTHENTICATION OR MULTI-FACTOR AUTHENTICATION WHEREVER POSSIBLE.

You need to rely on something other than passphrases alone.

Read more on two factor authentication here: www.riskaligned.com/2fa

Repeal your organization’s password aging rules. They do not help.

Also, here’s some guidance from the National Institute of Standards and Technology on good password practices: https://www.nist.gov/blogs/taking-measure/easy-ways-build-better-p5w0rd

“Careful with those password rules: they’re antiques!”

Memo: requirements of a Business Associate Agreement (BAA)

According to the US Department of Health and Human Services, a written contract between a covered entity and a business associate must:

  1. establish the permitted and required uses and disclosures of protected health information by the business associate;
  2. provide that the business associate will not use or further disclose the information other than as permitted or required by the contract or as required by law;
  3. require the business associate to implement appropriate safeguards to prevent unauthorized use or disclosure of the information, including implementing requirements of the HIPAA Security Rule with regard to electronic protected health information;
  4. require the business associate to report to the covered entity any use or disclosure of the information not provided for by its contract, including incidents that constitute breaches of unsecured protected health information;
  5. require the business associate to disclose protected health information as specified in its contract to satisfy a covered entity’s obligation with respect to individuals’ requests for copies of their protected health information, as well as make available protected health information for amendments (and incorporate any amendments, if required) and accountings;
  6. to the extent the business associate is to carry out a covered entity’s obligation under the Privacy Rule, require the business associate to comply with the requirements applicable to the obligation;
  7. require the business associate to make available to HHS its internal practices, books, and records relating to the use and disclosure of protected health information received from, or created or received by the business associate on behalf of, the covered entity for purposes of HHS determining the covered entity’s compliance with the HIPAA Privacy Rule;
  8. at termination of the contract, if feasible, require the business associate to return or destroy all protected health information received from, or created or received by the business associate on behalf of, the covered entity;
  9. require the business associate to ensure that any subcontractors it may engage on its behalf that will have access to protected health information agree to the same restrictions and conditions that apply to the business associate with respect to such information; and
  10. authorize termination of the contract by the covered entity if the business associate violates a material term of the contract. Contracts between business associates and business associates that are subcontractors are subject to these same requirements.

“Business Associate Contracts”. United States Department of Health and Human Services. Retrieved September 6, 2018.

Memo: use of email by healthcare providers to discuss health issues and treatment with patients

From Health and Human Services

“Yes. The Privacy Rule allows covered health care providers to communicate electronically, such as through e-mail, with their patients, provided they apply reasonable safeguards when doing so. See 45 C.F.R. § 164.530(c). For example, certain precautions may need to be taken when using e-mail to avoid unintentional disclosures, such as checking the e-mail address for accuracy before sending, or sending an e-mail alert to the patient for address confirmation prior to sending the message. Further, while the Privacy Rule does not prohibit the use of unencrypted e-mail for treatment-related communications between health care providers and patients, other safeguards should be applied to reasonably protect privacy, such as limiting the amount or type of information disclosed through the unencrypted e-mail. In addition, covered entities will want to ensure that any transmission of electronic protected health information is in compliance with the HIPAA Security Rule requirements at 45 C.F.R. Part 164, Subpart C.

“Note that an individual has the right under the Privacy Rule to request and have a covered health care provider communicate with him or her by alternative means or at alternative locations, if reasonable. See 45 C.F.R. § 164.522(b). For example, a health care provider should accommodate an individual’s request to receive appointment reminders via e-mail, rather than on a postcard, if e-mail is a reasonable, alternative means for that provider to communicate with the patient. By the same token, however, if the use of unencrypted e-mail is unacceptable to a patient who requests confidential communications, other means of communicating with the patient, such as by more secure electronic methods, or by mail or telephone, should be offered and accommodated.

“Patients may initiate communications with a provider using e-mail. If this situation occurs, the health care provider can assume (unless the patient has explicitly stated otherwise) that e-mail communications are acceptable to the individual. If the provider feels the patient may not be aware of the possible risks of using unencrypted e-mail, or has concerns about potential liability, the provider can alert the patient of those risks, and let the patient decide whether to continue e-mail communications.”

Patient Consent

Communicating with a patient via email is subject to the patient’s consent to be communicated with through that channel. If appropriate procedures are in place regarding email collection, the act of the patient providing that email address to the provider can be considered tacit consent.

Patients may initiate communications with a provider using email. If this situation occurs, the health care provider can assume that email communications are acceptable to the individual, unless the patient has explicitly stated otherwise. If the provider feels the patient may not be aware of the possible risks of using unencrypted email, or has concerns about potential liability, the provider can alert the patient of those risks, and let the patient decide whether to continue email communications.

Taking email address from public lists or spam lists is never acceptable.

Electronic Communication

The HIPAA Privacy Rule does allow covered healthcare providers to communicate electronically, such as through email, with their patients. This assumes that reasonable safeguards are applied when doing so. (45 C.F.R. § 164.530(c))

Certain precautions must be taken when using email to avoid unintentional disclosures. Precautions such as ensuring the accuracy of an email address before sending or sending an email alert to the patient for address confirmation prior to sending the message that contains protected health information are important.

Further, while the Privacy Rule does not prohibit the use of unencrypted email for treatment-related communications between healthcare providers and patients, other safeguards should be applied to reasonably protect privacy. These safeguards might include limiting the amount or type of information disclosed through unencrypted email. These safeguards can be addressed through appropriately drafted policies and procedures.

Patient Portal

Always try to encourage patients to use the patient portal when possible. This should be considered the prefered method of communication between patient and provider.

Disclaimer

When communicating by email, it is a best-practice to include appropriate disclaimers. The best method for ensuring the inclusion is to incorporate the disclaimer as a footer below the signature line, thus guaranteeing that the disclaimer is included on every email.

Summary

Yes, email is an acceptable method of communication for healthcare providers, as long as the patient approves of using email for this purpose. Approval can be as simple as asking for the patient’s email address to use for sending forms. If the patient provides the address, this can be considered tacit consent. Always document these actions in policies and procedures.

Communication via the patient portal should be the preferred method of communication.

Warn the patient that email is an inherently insecure method of communication. Do this when the patient requests to be contacted through email and again in the initial email.

This article contains direct quotes and information from the United States Department of Health and Human Services.

“Does the HIPAA Privacy Rule permit health care providers to use e-mail to discuss health issues and treatment with their patients?”. United States Department of Health and Human Services. Retrieved September 6, 2018.

Memo: IP address as a second factor of authentication

Properly implemented, we consider a known IP address to be an effective second factor. As far as it represents a physical location, an IP address is of the category Something You Are. Almost like a bio-metric.

Of course, it all depends on how well that IP address’ network is protected. If anyone can walk into your client’s waiting room, plug into an Ethernet port, and get a connection, so much for the second factor. And if anyone can connect to the VPN with nothing but a password, the IP address degrades down to Something You Know, and there goes your second factor.

The good news for you is that if either of those things happens, it constitutes a breach of your client’s systems and controls. Likewise, protecting passphrases is the responsibility of the client. So about the only way a malicious actor could exploit your authentication controls would be by first breaching a client system. I call that sitting pretty.

You have probably heard that is possible to spoof an IP address. True, it is not that hard to make incoming traffic appear to be originating from a false IP address, but it is very difficult to ex-filtrate data back to that spoofed IP address, especially with SSL on the pipe. For any realistic threat model, you can consider IP spoofing to be effectively impossible.

So go for it! It’s not as perfect as trusted device but I’d say it beats face recognition. I think you can call this true two-factor authentication, but it does make some assumptions about network security.

Aligned Risk Management joins HIMSS

Aligned Risk Management is proud to announce its membership in Healthcare Information and Management Systems Society (HIMSS).

HIMSS is an American not-for-profit organization dedicated to improving health care in quality, safety, cost-effectiveness, and access through the best use of information technology and management systems. It was founded in 1961 as the Hospital Management Systems Society. It is now headquartered in Chicago, Illinois. The society has more than 68,000 individual members, over 600 corporate members, and more than 400 not-for-profit organizations, as of March 2018.

Visit the official HIMSS website for more information: https://www.himss.org/

Memo: SOC vs NIST

NIST SP 800-30: Guide for Conducting Risk Assessments

NIST Special Publication 800-30 provides guidance for conducting risk assessments of federal information systems and organizations, amplifying the guidance in Special Publication 800-39. Risk assessments, carried out at all three tiers in the risk management hierarchy, are part of an overall risk management process—providing senior leaders/executives with the information needed to determine appropriate courses of action in response to identified risks.

NIST SP 800-53: Recommended Security Controls for Federal Information Systems and Organization

Everyone interested in advancing design and planning of IT systems must become knowledgeable of the accomplishments of NIST by reading their Special Publication 800-series reports. The 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and collaborative activities with industry, government, and academic organizations. The NIST Special Publication 800-53 “Recommended Security Controls for Federal Information Systems and Organization” list pages of specific controls that would be considered in the preparation of a standardized list of IT system controls for the private sector.

NIST SP 800-66: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule

The HIPAA Security Rule specifically focuses on the safeguarding of electronic protected health information (EPHI). All HIPAA covered entities, which include some federal agencies, must comply with the Security Rule, which specifically focuses on protecting the confidentiality, integrity, and availability of EPHI, as defined in the Security Rule. The EPHI that a covered entity creates, receives, maintains, or transmits must be protected against reasonably anticipated threats, hazards, and impermissible uses and/or disclosures.

Special Publication 800-66 Revision 1, which discusses security considerations and resources that may provide value when implementing the requirements of the HIPAA Security Rule, was written to:

  • Help to educate readers about information security terms used in the HIPAA Security Rule and to improve understanding of the meaning of the security standards set out in the Security Rule.
  • Direct readers to helpful information in other NIST publications on individual topics addressed by the HIPAA Security Rule.
  • Aid readers in understanding the security concepts discussed in the HIPAA Security Rule. This publication does not supplement, replace, or supersede the HIPAA Security Rule itself.

Service Organization Controls (SOC)

The American Institute of Certified Public Accounts (AICPA) has developed and adopted a set of guidelines and regulations for CPA audits in response the requirements of the Gramm-Leach-Bliley Act entitled, Service Organization Controls (SOC).  SOC is divided into two general types of audits SOC 1 and SOC 2 that are described on this site in detail.  SOC  is very specific as to the types of assessments that are to be made for each type of audit. SOC guidelines and regulations do not define the controls to be evaluated as part of an accounting audit to the same depth as controls identified by NIST.

SOC 1 audits according to the requirements of SSAE No. 16 reports  ”On Controls at a Service Organization” that is processing private and nonpublic data that is personal for it’s customers. The controls obviously would vary differently in approach even though there would be some overlap.  Standardizing would require developing different categories of controls for each type of audit.

SOC 2 audits deal with five different concerns: security, availability, integrity, confidentiality, and privacy. There are specific controls that come into play for each of these areas include overlap of controls to prevent possible financial theft, timely transmission, intrusion/manipulation, limited access and nondisclosure.

Concluding Notes

SOC guidelines and regulations do not define the controls to be evaluated as part of an accounting audit to the same depth as controls identified by NIST.

Aligned Risk Management follows NIST SP 800-30, the framework for conducting risk assessments, and evaluates and reports on controls aligned to NIST SP 800-53 and NIST SP 800-66.

This article contains direct quotes and information from the National Institute of Standards and Technology (NIST), Integrated Accounting Services.

“SP 800-30: Guide for Conducting Risk Assessments”. National Institute of Standards and Technology. Retrieved September 4, 2018.

“SP 800-66: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule”. National Institute of Standards and Technology. Retrieved September 4, 2018.

“NIST Special Publication 800-53”. National Institute of Standards of Technology. Retrieved September 4, 2018.

“Information Technology Laboratory”. Integrated Accounting Services. Retrieved September 4, 2018.

Memo: HIPAA log retention requirements

The subtle distinction between HIPAA medical records retention and HIPAA record retention can cause confusion when discussing HIPAA retention requirements.

There is No HIPAA Medical Records Retention Period

The reason the Privacy Rule does not stipulate how long medical records should be retained is because there is no HIPAA medical records retention period. Each state has its own laws governing the retention of medical records, and – unlike in other areas of the Healthcare Insurance, Portability and Accountability Act – HIPAA does not pre-empt them.

Consequently, each Covered Entity and Business Associate is bound by the laws of the state with regard to how long medical records have to be retained rather than any specific HIPAA medical records retention period. The states´ retention periods can vary considerably depending on the nature of the records and to whom they belong. For example:

  • In Florida, physicians must maintain medical records for five years after the last patient contact, whereas hospitals must maintain them for seven years.
  • In Nevada, healthcare providers are required to maintain medical records for a minimum of five years, or – in the case of a minor – until the patient is twenty-three years of age.
  • In North Carolina, hospitals must maintain patients´ records for eleven years from the date of discharge, and records relating to minors must be retained until the patient is thirty.

The HIPAA Retention Requirements

Although there are no HIPAA retention requirements for medical records, there is a requirement about how long other HIPAA-related documents should be retained. This is covered in CFR §164.316(b)(1), which states Covered Entities must maintain the policies and procedures implemented to comply [with HIPAA] and records of any action, activity or assessment.

CFR §164.316(b)(2)(i) stipulates the documents must be retained for a minimum of six years from when the document was created, or – in the event of a policy – from when it was last in effect. Therefore if a policy is implemented for three years before being revised, a record of the original policy must be retained for a minimum of nine years after its creation.

The list of documents subject to the HIPAA retention requirements is extensive depending on the nature of business conducted by the Covered Entity or Business Associate. The following list is an example of the most common type of documents but, for example, health plans and healthcare clearing houses do not issue Notices of Privacy Practices, so would not be required to retain copies of them:

  • Notices of Privacy Practices.
  • Authorizations for the Disclosure of PHI.
  • Risk Assessments and Risk Analyses.
  • Disaster Recovery and Contingency Plans.
  • Business Associate Agreements.
  • Information Security and Privacy Policies.
  • Employee Sanction Policies.
  • Incident and Breach Notification Documentation.
  • Complaint and Resolution Documentation.
  • Physical Security Maintenance Records.
  • Logs Recording Access to and Updating of PHI.
  • IT Security System Reviews (including new procedures or technologies implemented).

Contains information obtained from HIPAA Journal.

“Clarifying the HIPAA Retention Requirements”. HIPAA Journal. Retrieved September 3, 2018.

HIPAA Security Rule Standards and Implementation Specifications

HIPAA is a set of standards introduced by the U.S. Congress in 1996. The Act consists of rules governing protected health information (PHI) including Security, Privacy, Identifiers, and Transactions and Code Sets. The purpose of the HIPAA Security Rule is to promote the protection and privacy of sensitive PHI used within the healthcare industry by organizations called “covered entities.” As a result of the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009, both covered entities and business associates are now accountable to the United States Department of Health and Human Services (HHS) and individuals for appropriately safeguarding private patient information.

The HIPAA Security Rule Standards and Implementation Specifications has four major sections, created to identify relevant security safeguards that help achieve compliance: 1) Physical; 2) Administrative; 3) Technical; and 4) Policies, Procedures and Documentation Requirements.

Organizations must implement reasonable and appropriate solutions and management policies and procedures to comply with HIPAA technical standards and implementation specifications. It’s important to perform a formal security risk assessment for each of the safeguards in the HIPAA Security Rule. Management’s decisions related to risk aversion and tolerance must be documented in the security risk assessment to identify potential compliance gaps. For many organizations, it is difficult to determine how the Rule applies. Navigating the type of technologies and processes that are needed to achieve compliance can be challenging.

Under the HIPAA Security Rule, implementation of standards is required, and implementation specifications are categorized as either “required” (R) or “addressable” (A). For required specifications, covered entities must implement the specifications as defined in the Security Rule. For addressable specifications, a covered entity must assess whether the implementation of the specification is reasonable and appropriate for its environment and the extent to which it is appropriate to protect ePHI. Following the security risk assessment, the covered entity must either implement the addressable specification, or document why it would not be reasonable and appropriate to implement and identify alternative and/or compensating safeguards as reasonable and appropriate.

Administrative Safeguards

  • 164.308(a)(1)(ii)(A) Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.
  • 164.308(a)(1)(ii)(B) Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).
  • 164.308(a)(1)(ii)(C) Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.
  • 164.308(a)(1)(ii)(D) Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
  • 164.308(a)(2) Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart [the Security Rule] for the entity.
  • 164.308(a)(3)(ii)(A) Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
  • 164.308(a)(3)(ii)(B) Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
  • 164.308(a)(3)(ii)(C) Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) [the Workforce Clearance Procedure] of this section.
  • 164.308(a)(4)(ii)(A) If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
  • 164.308(a)(4)(ii)(B) Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
  • 164.308(a)(4)(ii)(C) Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.
  • 164.308(a)(5)(ii)(A) Periodic security updates.
  • 164.308(a)(5)(ii)(B) Procedures for guarding against, detecting, and reporting malicious software.
  • 164.308(a)(5)(ii)(C) Procedures for monitoring log-in attempts and reporting discrepancies.
  • 164.308(a)(5)(ii)(D) Procedures for creating, changing, and safeguarding passwords.
  • 164.308(a)(6)(ii) Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes.
  • 164.308(a)(7)(ii)(A) Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
  • 164.308(a)(7)(ii)(B) Establish (and implement as needed) procedures to restore any loss of data.
  • 164.308(a)(7)(ii)(C) Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.
  • 164.308(a)(7)(ii)(D) Implement procedures for periodic testing and revision of contingency plans.
  • 164.308(a)(7)(ii)(E) Assess the relative criticality of specific applications and data in support of other contingency plan components.
  • 164.308(a)(8) Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operations changes affecting the security of electronic protected health information, that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart [the Security Rule].
  • 164.308(b)(4) Document the satisfactory assurances required by paragraph (b)(1) [the Business Associate Contracts and Other Arrangements] of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of §164.314(a) [the Organizational Requirements].

Organizational Requirements

  • 164.314(a)(2)(i) Business associate contract must meet certain requirements.
  • 164.314(a)(2)(ii) Applies to government organizations only.
  • 164.314(b)(1) n/a
  • 164.316(a) Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in 164.306(b)(2)(i), (ii), (iii), and (iv) [the Security Standards: General Rules, Flexibility of Approach]. This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. A covered entity may change
  • 164.316(b)(1)(i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.
  • 164.316(b)(2)(i) Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.
  • 164.316(b)(2)(ii) Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.
  • 164.316(b)(2)(iii) Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.

Physical Safeguards

  • 164.310(a)(2)(i) Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.
  • 164.310(a)(2)(ii) Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.
  • 164.310(a)(2)(iii) Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision.
  • 164.310(a)(2)(iv) Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors and locks).
  • 164.310(b) Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information.
  • 164.310(c) Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users.
  • 164.310(d)(2)(i) Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored.
  • 164.310(d)(2)(ii) Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use.
  • 164.310(d)(2)(iii) Maintain a record of the movements of hardware and electronic media and any person responsible therefore.
  • 164.310(d)(2)(iv) Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.

Technical Safeguards

  • 164.312(a)(2)(i) Assign a unique name and/or number for identifying and tracking user identity.
  • 164.312(a)(2)(ii) Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
  • 164.312(a)(2)(iii) Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
  • 164.312(a)(2)(iv) Implement a mechanism to encrypt and decrypt electronic protected health information.
  • 164.312(b) Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
  • 164.312(c)(2) Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
  • 164.312(d) Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
  • 164.312(e)(2)(i) Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
  • 164.312(e)(2)(ii) Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

 

Enforcement Results by Year

The data table below shows the enforcement results by calendar year according to the type of closure for each category. This is the number of investigations that the Office of Civil Rights had resolved. There were:

Outcome of Complaint Investigations

Investigated:
No Violation
Investigated:
Corrective Action Obtained
Resolved After Intake and Review Technical Assistance Total Resolutions
2013 994 3470 6917 2753 14134
2014 668 1288 10401 5128 17485
2015 360 730 12634 3817 17541
2016 204 706 16780 6204 23894

Outcome of Breach Compliance Review Investigations

Investigated:
No Violation
Investigated:
Corrective Action Obtained
Resolved After Intake and Review Other Total Resolutions
2013 21 121 6 4 152
2014 6 216 7 10 239
2015 9 126 8 5 148
2016 25 283 8 3 319

Outcome of Other Compliance Review Investigations

Investigated:
No Violation
Investigated:
Corrective Action Obtained
Resolved After Intake and Review Other Total Resolutions
2013 1 21 3 0 25
2014 2 27 0 1 30
2015 7 24 2 3 36
2016 3 10 1 1 15

Total Cases Investigated

Investigated:
No Violation
Investigated:
Corrective Action Obtained
Total Investigated Of Those, Settlements or CMPs % of Total Investigated
2013 1016 3612 4628 5 0.11%
2014 676 1531 2207 7 0.32%
2015 376 880 1256 6 0.48%
2016 232 999 1231 13 1.06%

Total Cases

Complaints Compliance Reviews Total Cases Of Those, Settlements or CMPs % of Total Cases
2013 14134 177 14311 5 0.0349%
2014 17485 269 17754 7 0.0394%
2015 17541 184 17725 6 0.0339%
2016 23894 334 24228 13 0.0537%

“Enforcement Results by Year”. Health and Human Services, US. Retrieved July 26, 2018.

Use the RFP Process to Find Best HIPAA Security Risk Assessment Vendor

A Request for Proposal (RFP) is one of the best ways to find out what each HIPAA security risk assessment vendor has to offer your organization, provided you structure it properly

From the August 2004 Issue of HIPAA Security Compliance Insider.

The annually required HIPAA Security Risk Assessment isn't a joke....Like many organizations, your organization may not have the resources to conduct a HIPAA security risk assessment that compares your technical and nontechnical security measures to HIPAA’s requirements. That’s where an outside security assessment vendor can help. It can identify and explain your security weaknesses and the potential threats and vulnerabilities to your electronic protected health information (EPHI). Plus, a security assessment vendor can give you advice on what security measures you should implement to comply with HIPAA’s security regulations and stay in business.

But how do you know which security assessment vendor is the best one for your organization? One good way is to put together a request for proposal (RFP) that you send to prospective HIPAA security risk assessment vendors. Creating an RFP for prospective vendors will help you focus your security assessment project. And it will give you a chance to review and compare prospective vendors’ written responses to questions tailored to your organization. “Done well, an RFP is an indispensable tool for visualizing a project; and it provides a concrete roadmap for your relationship with the vendor you select,” says information technology attorney Jay Hollander.

We’ll tell you the steps you should take to start the process of choosing the right HIPAA security risk assessment vendor, including how to set up an RFP. And to help you set up your own, we’ll give you a Model Form of an RFP that you can adapt and distribute to potential vendors.

Follow Three Steps to Start Your HIPAA Security Risk Assessment Vendor Selection Process

According to Hollander, choosing a vendor to perform a HIPAA security risk assessment should start with three steps.

  1. Assess needs/scope of project. First you must identify what areas your HIPAA security risk assessment should include. Do you need an assessment of your physical access controls and security policies? Should the vendor conduct a penetration test of your internal and external networks to see how easily they can be breached? “Each organization’s needs will be different,” says information security consultant Earl Crane. For example, smaller organizations that don’t transfer EPHI over extranet connections probably won’t need a security assessment of their extranet, he explains. 

    Insider Says: For a list of the various areas an organization’s security assessment might need to cover, click here. You can use this list to help you identify your own needs so you can communicate them to prospective vendors.

  2. Narrow list of vendors. Next, you will need to get a list of prospective vendors. To do this, you can search for security assessment vendors on the Internet or ask colleagues for recommendations. Narrow your list by considering the vendors’ experience, general pricing approach, and the services they provide, says Hollander. 

    Focus on vendors that have the ability to assess both your technical and nontechnical security, recommends Crane. To get a complete picture of your security practices, you will need a technical assessment and a policy assessment, preferably by the same vendor, he explains. “Look for a vendor with a good understanding of HIPAA’s security regulations, and a good technical reputation,” he adds.

  3. Prepare RFP. Once you’ve narrowed your list of prospective vendors down to four or five, it’s time to create an RFP. Your RFP, like ours, should include the following provisions:
  • Purpose and goals. Begin your RFP with a brief explanation of the reason you’re seeking a HIPAA security risk assessment vendor and your goals for the assessment—that is, to identify and repair security gaps and comply with the HIPAA security regulations.
  • Proposal contact and method of evaluation. Give prospective vendors the name and contact information of a knowledgeable person in your organization to whom they can go for more information. And tell them who should receive the proposals and any additional information your organization might need [Form, sec. 2(a)]. Also tell them the factors that will affect your decision to accept a proposal. Explain that your consideration of the proposals will be based on more than cost, says Crane. This way, they’ll understand that they may be rejected even if they have the lowest bid.
  • Schedule. Vendors will also need a schedule that outlines the RFP process from beginning to end, including the date when:
    • Responses to the RFP are due;
    • Vendor interviews will be held;
    • Supplemental information must be received;
    • A decision will be made; and
    • The project should start and finish.
  • Organization information. To understand the scope of the project and price it appropriately, prospective vendors will need a basic description of your organization and the information systems it currently uses. Be sure to describe all hardware and software, and let prospective vendors know how many active IP addresses your organization uses.
  • Scope of project. Based on the needs assessment you conducted before you narrowed down your vendor list, define the scope of the project in your RFP. Be precise, says Crane. Otherwise, your vendors might not bid on the same project, resulting in service and pricing differences that could be hard to identify and compare. And ask your vendors to break down their costs and the amount of time they require for each type of assessment you list in your RFP, Crane adds.

Confused? That’s okay! Call Aligned Risk Management for help:

505-908-9040

“Use RFP to Find Best HIPAA Security Assessment Vendor”. HIPAA Security Compliance Insider, US. Retrieved July 3, 2018.