Memo: Train your staff on the use of password management software

Aligned Risk Management recommends password management software for all staff and especially for staff who work with a large number of external web application accounts.

  • A password manager can help encourage the use of long, complex, and unique passwords.
  • A password manager can reduce the need for users to commit their passwords to memory, making it less likely that they could expose their passwords inadvertently to social engineering attackers.
  • Automated password managers will fail to populate password fields on look-alike phishing pages, which can alert users that they are not accessing the system they expected.
  • Best practices recommended by the National Institute of Standards and Technology (NIST) endorse the use of password managers.

“Verifiers SHOULD permit claimants to use ‘paste’ functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.”

National Institute of Standards and Technology, NIST Special Publication 800-63-3: Digital Identity Guidelines.


Memo: Stop periodic password changes

Requiring users to change passwords periodically may encourage them to create less secure passwords. It may have worked 20 years ago, but it doesn’t work anymore. Stop it. Just stop it.

According to cybersecurity firm SecureState, password complexity policies combined with password aging policies consistently lead, on large systems, to a predictable percentage of passwords chosen by users to serve as seasonal mnemonics, e.g., Spring2017 or January18!.

Periodic password changes mitigate only a small number of risks. Those risks can be more effectively mitigated by other controls, including two-factor authentication.

Check out Aligned Risk Management’s Secure Passphrase Generator.

Cybersecurity research indicates that password aging policies provide only minimal security benefit because users will predictably create new passwords that can be easily guessed by an attacker who knows the old password.

“We believe our study casts doubt on the utility of forced password expiration. Even our relatively modest study suggests that at least 41% of passwords can be broken offline from previous passwords for the same accounts in a matter of seconds, and five online password guesses in expectation suffices to break 17% of accounts.”

Yinqian Zhang, Fabian Monrose, and Michael K. Reiter. The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis.

A number of security experts have begun expressing skepticism about the utility of mandatory password changes, including Lorrie Cranor, Chief Technologist at the Federal Trade Commission, and Bruce Schneier, board member of the Electronic Frontier Foundation.

“But my favorite question about passwords is: ‘How often should people change their passwords?’ My answer usually surprises the audience: ‘Not as often as you might think.’ […] [U]sers who are required to change their passwords frequently select weaker passwords to begin with, and then change them in predictable ways that attackers can guess easily.”

Lorrie Cranor. Time to Rethink Mandatory Password Changes.

“The downside of changing passwords is that it makes them harder to remember. And if you force people to change their passwords regularly, they’re more likely to choose easy-toremember – and easy-to-guess – passwords than they are if they can use the same passwords for many years. So any password-changing policy needs to be chosen with that consideration in mind.”

Bruce Schneier. Changing Passwords.

Latest NIST standards no longer recommend periodic password changes.

“Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

National Institute of Standards and Technology. NIST Special Publication 800-63-3: Digital Identity Guidelines.

Critical Parts of a Quality Risk Management Plan (Part 1)

A Risk Management Plan is the part of your compliance approach that plans, identifies, and analyzes risks.

The premier HIPAA compliance consulting firm, Aligned Risk Management.

Parts of a Risk Management Plan

  1. Risk Planning
  2. Risk Identification
  3. Risk Analysis
  4. Risk Response Plans
  5. Risk Register

Risk Planning

Risk is defined by the Project Management Institute as an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. Risk management is the process of identifying, analyzing, mitigating, and communicating risks.

Definitions

All systems have vulnerabilities. The US Department of Health and Human Services defines a vulnerability as:

[a] flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

The US Department of Health and Human Services defines a risk as:

The net mission impact considering the probability that a particular [threat] will exercise (accidentally trigger or intentionally exploit) a particular vulnerability and the resulting impact if this should occur.

Risks arise from legal liability or mission loss due to:

Unauthorized (malicious or accidental) disclosure, modification, or destruction of information; Unintentional errors and omissions; IT disruptions due to natural or man-made disasters; Failure to exercise due care and diligence in the implementation and operation of the IT system.

When a risk event occurs, it is no longer uncertain. It becomes an issue.

Risk is a function of the likelihood of a given threat exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization, mitigated by controls. The relationship among these five concepts forms the basis of our risk assessment approach, which can be thought of as a formula:

(Impact · Likelihood) × (Threat · Vulnerability)
Controls

“Math”

The risk level is calculated using three underlying components:

  • Likelihood: The probability of the event happening. How likely is it that a threat acts on the vulnerability?
  • Impact: The consequences of the risk event. What happens if the threat acts on the vulnerability?
  • Effectiveness of Existing Controls: Existing controls and their effectiveness at mitigating risk. What is being actively done to mitigate the effects of a risk?

Likelihood × Impact − Controls ⇒ Risk Level

To illustrate, a plane crashing into your office has a high impact, but a low probability. In fact the probability is so low that the overall risk is probably insignificant. On the opposite end of the scale, a road construction project getting delayed due to rain is an event with a low impact but a high probability of occurrence. Thus, it is a significant risk.

A HIPAA Risk Management Plan should begin with an analysis of the risk tolerance of the organization, a Risk Assessment.

  • What projects have been completed in the past and what unexpected issues occurred?
  • What was the response of the organization?
  • What permanent changes were made? Were they justified?
  • Did the response cause a corresponding loss of business?
  • Did the response cause a corresponding loss of future projects?

Risk Levels

Another part of the risk planning portion of the Risk Management Plan is the definition of risk levels. Here is an example:

  • Very Low: The event is highly unlikely to occur under regular circumstances.
  • Low: The event is unlikely but should be noted by the project team.
  • Medium: The event has a normal chance of occurring and the project team should be aware of it.
  • High: The event has a reasonable chance of occurring. It should be regularly discussed and mitigation actions taken.
  • Very High: The occurrence of the event should be actively managed and mitigation actions taken.

Aligned Risk Management breaks down risk levels into four categories: Negligible, Marginal, Serious, and Critical.

Negligible Risk

Theoretical risk. Unlikely to be a serious concern.

  • Vulnerability is very unlikely to be exercised, OR
  • Existing controls are highly effective at mitigating the risk, OR
  • Potential impact on security, privacy and availability of ePHI is low

Marginal Risk

Unlikely to be an immediate concern, especially in light of other, more severe risks.

  • Some likelihood that vulnerability could be exercised
  • Existing controls provide some effective mitigation of risk

Serious Risk

Potential for significant impact on operations. Effective Risk Management or reasonable plan for such recommended in near future.

  • Vulnerability is likely to be exercised
  • Existing controls provide inadequate mitigation of risk
  • Potential for significant impact on security, privacy or availability of ePHI

Critical Risk

Failure to implement controls required by HIPAA. Potential liability and exposure to penalties. Potential for malicious exploitation. Exercise of vulnerability could cause mission-critical damage to business operations. Prompt intervention strongly recommended.

  • Vulnerability is very likely to be exercised or is currently being exercised
  • Existing controls provide little effective mitigation of risk
  • Potential for high or even catastrophic impact on security, privacy or availability of ePHI

Assumptions

A good brainstorming tool is to consider the assumptions made by the project. Most projects have disclaimers in their underlying contracts absolving the performing party of various obvious risks, but what about the next most obvious ones?

  • What assumptions has the project budget made?
  • What assumptions has the project schedule made (completion date, milestones, etc.)?
  • What expertise or prior experience does the company have in this work? How long ago was this experience? What areas require additional training?
  • Which relationships are being assumed to be strong that are not necessarily (owner, sponsor, client, contractor, consultant)?
  • How many previous projects with similar components have been completed successfully? What were the project issues?

Stay tuned for Part 2 of Aligned Risk Management’s series, Critical Parts of a Quality Risk Management Plan.

Project Engineer, Building Better Project Managers.

Does HIPAA and the HITECH Act Impact Medical Device and Pharma Companies?

The Question:

Are medical device or pharmaceutical companies designated as a qualifying entity subject to HIPAA and HITECH?

The Answer:

Yes.

Classifying the entity

Are medical device or pharmaceutical companies designated as a qualifying entity subject to HIPAA and the HITECH Act? Yes. In general, a provider that “transmits any health information in electronic form in connection with a transaction covered by this subchapter” is considered a covered entity. Moreover, according to the 45 CFR §160.103(2)(ii)(3), “a covered entity may be a business associate of another covered entity.” In fact, CMS recognized that as a government agency, it is subject to HIPAA, the HITECH Act and related rules in an October 2012 report issued by the Office of the Inspector General, “CMS Response to Breaches and Medical Identity Theft.”

In turn, a business associate, as defined by the HIPAA Rules, is “a person who performs functions or activitieson behalf of, or certain services for, a covered entity that involve the use or disclosure of protected health information” (emphasis added). A subcontractor is a person who contracts with a business associate and stores, handles or transmits PHI. Regardless, under Section 164.308(b) of the Security Rule and 164.502(e) of the Privacy Rule, a covered entity or business associate is required to enter into an arrangement known as a business associate agreement to provide parameters and some legal protection when a contracted entity is handling PHI.

Effective Feb. 18, 2010, Section 13408 of the HITECH Act provides that health information organizations, e-prescribing gateways, vendors of personal health records and other persons that facilitate data transmission and require access to PHI, regardless of their status as a covered entity, business associate or subcontractor, are subject to business associate agreements in accordance with the HIPAA Rules.

Therefore, medical device and pharmaceutical companies can be classified as a qualifying entity subject to HIPAA and the HITECH Act. As such, they are subject to handling, storing and transmitting in accordance with the requisite laws and regulations. The consequences from civil and criminal monetary penalties alone are significant. Since the HITECH Act expressly expanded HIPAA’s requirements to business associates and subcontractors, the same standards for access to medical records, business associate agreements and other provisions equally apply.

Patient access rights

The tension between patients wanting to have access to their health data from a medical device, which is implanted in them, and a medical device company is highlighted. According to a representative of a medical device maker quoted in the article, “Federal rules prohibit giving Ms. Hubbard’s data to anyone but her doctor and hospital. Our customers are physicians and hospitals.” In general, 45 C.F.R. §164.524, Access of Individuals to Protected Health Information, sets forth the parameters of the HIPAA Privacy Rule. Included in these standards are the circumstances for providing protected health information to a patient and exceptions. Nothing in the scenario of the PHI being transmitted from a patient’s implant to a medical device company, who would be classified as a business associate in this instance invokes an exception to deny the patient’s request.

Section 13410(d) of the Health Information Technology for Economic and Clinical Health Act authorizes penalties to be assessed for violations of the Privacy Rule. In February 2011, HHS issued a Final Notice of Determination and held Cignet Health, a business associate, liable for $4.3 million in civil monetary penalties when they denied 41 patients access to their medical records. As OCR Director Georgina Verdugo indicated, “covered entities and business associates must uphold their responsibility to provide patients with access to their medical records, and adhere closely to all of HIPAA’s requirements.” And, “The U.S. Department of Health and Human Services will continue to investigate and take action against those organizations that knowingly disregard their obligations under these rules.” This area should be considered in drafting business associate agreements. Therefore, business associates such as Medtronic are required to release the PHI to the patient requesting the information, unless one of the exceptions is met, and the patient is informed.

“How Does HIPAA and the HITECH Act Impact Medical Device and Pharma Companies?”. Becker Hospital Review, US. Retrieved December 20, 2018.

Memo: subsidiary websites

The question

We have our [redacted] website but just found that our substance abuse team has created another website that just specifically address addiction and the services provided. The only association it has with our office is a small little logo at the bottom of the page. And the telephone number listed goes directly to a staff members cell phone. Do you find this a issue?

The answer

Strictly regarding subsidiary websites, there is no violation or problem that arises from this issue alone. Many hospitals and practices enable the use of separate websites when services are differentiated substantially from the parent organization.

However, the problem with the [redacted, subsidiary] team website is that this website was created without the prior express authorization of the parent organization. The website was created and is managed outside of the normal reach of the parent organization and the project was undertaken in violation of the organization’s policies and procedures (this is assumed, based on unseen policies and procedures).

The inclusion of a staff member’s cell phone number on the site as the primary method for contacting the substance abuse team creates a problem with chain of custody. A patient suffering from substance abuse might leave sensitive information in a voicemail left on the staff member’s cell phone. Without being able to guarantee any assurances as to the privacy and security of this potentially sensitive information, such an incident could be considered an unauthorized disclosure.

Depending on the organization’s policies and procedures regarding a BYOD (bring your own device) policy and mobile device management, this creates a continual vulnerability for sensitive information to be disclosed, unintentionally or otherwise.

Additionally, the substance abuse website might not sufficiently publicize the organization’s notice of privacy practices (this is assumed, based on unseen website).

Suggested corrective action

The website should immediately be brought under the direct control of the parent organization, be made so that the site is not publicly accessible until corrective action is completed, and evaluated by the designated individuals responsible for website maintenance. Any deficiency should be brought into compliance in accordance with the organization’s policies and procedures. The staff responsible for acting outside of the organization’s policies and procedures should be made aware of the problems their actions have caused, along with appropriate disciplinary sanctions.

Memo: about two-factor authentication

Two-factor authentication (2FA), or multi-factor authentication, is a security process in which the user provides two means of identification from separate categories of credentials; one is something memorized, such as a security code or password, and the other is typically a physical token, such as a card or a previously-authenticated smartphone.

A common example of two-factor authentication is the ATM card most consumers are familiar with. In order to authorize a transaction, the user must present the ATM card (a physical token) and also enter a PIN (a memorized secret). Neither the card alone nor the PIN alone will suffice to authorize a transaction, and it is unlikely that an attacker could obtain both simultaneously.

Stolen passwords are a very common vector for online attacks. Two-factor authentication can drastically reduce the effectiveness of password-related exploits, because stealing a password is not enough to give an attacker access to protected information.

True two-factor authentication requires that the factors be chosen from separate categories of credentials. The three commonly recognized categories are

  • “something you know” (e.g., a password)
  • “something you have” (e.g., a pre-registered smartphone), and
  • “something you are” (e.g., a fingerprint)

Most two-factor authentication today works by leveraging the second category in the form of a physical token or pre-registered smartphone. Smartphone-based solutions are popular since they work with a device most users already carry with them and protect zealously.

Numerous inexpensive 2FA solutions, some based on open standards, are gaining rapid adoption:

  • U2F security keys, an open standard for inexpensive USB tokens, industry leaders, like Yubico and Google.
  • Smartphone apps, usually free, that implement the open standard TOTP protocol (see below). Google Authenticator and Symantec VIP are commonly used.
  • Proprietary solutions, including Microsoft Azure and Duo.

Pre-registered knowledge tokens (PKTs), commonly known as “security questions,” are of the same category as passwords (“something you know”) and cannot be combined with passwords to provide true two-factor authentication.

Two-factor authentication does not replace passwords. Good password practices are still essential, but two-factor authentication can significantly reduce the risk of weak passwords.

Some 2FA solutions work by transmitting a one-time password over a different communication channel, such as via SMS to a pre-registered mobile phone. This is true two-factor authentication, but poor security practices by mobile service providers introduce the risk that the one-time password could be intercepted by an attacker.

More secure solutions can generate one-time passwords without having to transmit them, thus eliminating any risk that they could be intercepted. Transmitting one-time passwords via SMS has been deprecated by the latest NIST cybersecurity guidelines. Non-transmitting solutions should be preferred whenever available.

Cryptographic certificates, when generated and installed by properly authorized administrators, are of the same category as physical devices (“something you have”) and can be used in combination with passwords to implement two-factor authentication. Although a certificate is only data (like a password), it is tied closely to the physical device on which it is installed and it is difficult for the user to access, memorize, or inadvertently breach. The threat of unauthorized cloning does need consideration, but in general, enrolling a trusted device by installing a cryptographic certificate can be a cost-effective and very secure way to implement two-factor authentication.

 

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.

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.