Blog

Master the complexities of cloud compliance with expert resources and relevant insights.

HIPAA & HITRUST Self-Assessment

Introduction

This HIPAA worksheet is meant to illuminate the cloud requirements of HIPAA that you need to plan for in your own digital health product. What does "HIPAA Compliant" really mean? Frequently it is just a marketing label that some companies bestow upon themselves and not really an attestation of compliance. That's risky.

A more comprehensive risk assessment, such as the HITRUST CSF Self-Assessment, is also necessary. Use this checklist to understand what compliance controls are needed, and assess your compliant state at several cloud layers:

  • The Physical Layer

  • The Operating System and Application Layers

  • The Administrative Layer

Once you've completed this checklist you'll have a much better understanding of what it will take to be HIPAA compliant in the cloud.

Physical Layer Controls

Item

Description

Assessment

Entry to data center is managed

Personal access to physical hardware is managed via technical processes and administrative procedures, like badges. As a cloud customer, your CSP provider (e.g. AWS, Azure, GCP, etc) will cover this control in their BAAs and privacy agreements because it will be impossible for you to manage otherwise. If you don't have a BAA with your cloud service provider, then you are out of compliance. This is a requirement to run compliant workloads on any cloud.

Do you have a BAA in place with your cloud service provider that takes on the risk of this control?

Physical repairs are managed and observed

Beyond access, managing a procedure that ensures repairs are monitored appropriately is required. For example, HVAC or electrical systems. As a cloud customer, your CSP provider (e.g. AWS, Azure, GCP, etc) will cover this control in their BAAs and privacy agreements because it will be impossible for you to manage otherwise. If you don't have a BAA with your cloud service provider, then you are out of compliance. This is a requirement to run compliant workloads on any cloud.

Do you have a BAA in place with your cloud service provider that takes on the risk of this control?

Physical firewall in place

Networking segmentation at the physical layer is a requirement. As a cloud customer, your CSP provider (e.g. AWS, Azure, GCP, etc) will cover this control in their BAAs and privacy agreements because it will be impossible for you to manage otherwise. If you don't have a BAA with your cloud service provider, then you are out of compliance. This is a requirement to run compliant workloads on any cloud.

Do you have a BAA in place with your cloud service provider that takes on the risk of this control?

The Operating System and Application Layers

Item

Description

Assessment

Encryption of data at rest

Basic block-level 256-bit AES encryption is required. There is debate if 128-bit is sufficient enough. Ultimately, it's a debate since there are no hard rules. We suggest deploying 256-bit AES in order to future proof future regimes, like what happened with the advent of GDPR in 2018.

Have you encrypted all volumes with 256-bit AES encryption?

TLS / Network encryption

TLS is often terminated after the firewall or load balancer. You should re-encrypt it before passing back through to the cloud environment because encryption of data "in transit" is interpreted as a requirement for HIPAA.

Do you re-encrypt traffic from the network perimeter?

Encryption of data between services (e.g. app and db)

One of the most controversial and misunderstood parts of HIPAA compliance, and newer compliance regimes coming out like GDPR, is the requirement for network-level encryption of data "in flight" between services within a cloud environment, whether the environment is physically or logically separated from other tenants in the cloud. Ultimately, network encryption between services IS required in order to achieve certain HITRUST, NIST, GDPR, etc controls. One example is a database and app service, if both are contained inside a Docker container. Traffic in between those containers must be encrypted with proper key rotation. So, for example, Kubernetes was technically not compliant until Datica submitted a change to the Kubernetes project updating cri-o, the main interface between Docker containers and the k8s orchestration tooling, to use encryption in flight.

Is all traffic between services within your cloud workloads encrypted with proper key rotation?

Subnetwork segregation at hardware and software firewalls

A best practice in leveraging the cloud is to use dedicated network spaces for you organization or for each application. This logical network segmentation adds a layer of protection against other cloud customers and services.

Are you segmenting all network traffic via physical and logical separation of hardware and software firewalls? Are you using dedicated, logical networks for each application?

Nightly backups of data

As part of a business continuity plan required for compliance, continuous backup of data containing PHI must be done in a compliant manner. For example, if you are backing up data to an offsite server, then that server must also have the entire list of compliance controls implemented too, like encryption and everything else listed here. There is debate as to what specific frequency of backups will meet compliance, but we have seen nightly backups be the right balance of not too burdensome while meeting the demands of HIPAA, HITRUST, GDPR, etc.

Do you have automated nightly backups in place to a destination that is also configured to be compliant and has been included within scope of your audit?

Cross-region Disaster Recovery automation in place

Should a specific physical location become unavailable due to a disaster, a combination of automated technology and administrative protocols must be in place to make available the data and supported services via another geography that didn't suffer from the disaster. On the cloud, this basically means ensuring you are replicated across different regions. It does NOT mean you must be replicated across different cloud, like say AWS and Azure for example. However, that level of DR policy is looked upon favorably by assessors.

Do you have a DR plan in place across different regions?

Access Control Lists (ACLs) for access to OS level

ACLs a basic compliance administrative requirement, but the challenge with them is that they are spread across different layers of the technology stack. At the operating system level, ACLs include concepts like security groups, user provision management, and user-based hardening.

Do you have security groups implemented? Are you managing user access via an administrative ACL procedure?

Password management for all systems at the OS level

There are many controls that feel like overlap but are in fact specific isolated tasks needing to be managed. Password management is an administrative type task that is related to access control, but is its own job. It means that there is a procedure in place to ensure that passwords for users who have access to the operating system layer, and subsequent systems or services within the layer, are set to the appropriate complexity with appropriate rotation. It is also small part of the overall concept of "hardening" by ensuring users and passwords no longer used are removed.

Is there an administrative procedure in place for password management at the OS level? Do single users only have access to their singular password? If any software is used to manage user passwords, is that software configured in a compliant manner?

Intrusion detection

IDS continuously monitors for threats coming into your cloud environments. Like with antivirus and other items on the list, there are great tools available to do the job.

Do you have an IDS tool installed? If so, are you reviewing identified threats on a daily basis? If the tool is a managed service, do you have a BAA in place with that service provider?

Antivirus

The basic chore of scanning your cloud environment for viruses is a requirement. Like with IDS and other items on the list, there are great tools available to do the job.

Do you have an antivirus tool installed? If so, are you reviewing scans on a daily basis? If the tool is a managed service, do you have a BAA in place with that service provider?

Vulnerability scanning for system failure

Vulnerabilities can be gateways for malicious actors, like virus or invaders attempting to hack in from other countries. But vulnerabilities can also be unintended and related to system failure, like a SAN disk filling up. Getting a system in place to scan for vulnerabilities is a requirement.

Do you have a vulnerability scanning tool installed? If so, are you reviewing vulnerabilities on a daily basis? If the tool is a managed service, do you have a BAA in place with that service provider?

Audit logging of all user activity in the system

There must be a trail of all user activity within the system. Keep in mind this means users at the operating system level, not app users who are customers of your healthcare product. Those logs serve as both an input into tools like IDS but are also important for audits or lawsuits should there be a breach of the system.

Do you log all user activity within the cloud environment?

Monitoring and logging of all system events

Events that are generated from the system, and not from users, must also be logged. System event monitoring and logging is the same as user logging in that it serves as an input into other tools like IDS but is also an important paper trail for audits or lawsuits should a breach happen.

Do you log all system activity within the cloud environment?

Application events are logged

Outside of the cloud environment layer, application logs must be stored as well. App logs mean user events, so users who log into an app with a username and password then perform actions within the web or mobile interface of the app. App logs are also events created by the app services, like the codebase and database. All those things should be logged for the same reasons as other logs: As an input for other tools, and as a paper trail for audits and lawsuits should a breach happen.

Do you log all application level events in the similar way as system level event logs?

Logs are protected: encrypted and have proper ACLs in place

Across all logs, it is important to ensure ACLs are in place so that the appropriate users of the system have access. Logs also need to be encrypted at rest and in flight like any other part of the system. If logs are shipped elsewhere, then you need to ensure that destination is compliant to all items in this list, and if it's to a third party service provider, then you need a BAA with them. Why is this important? Because PHI might be in the logs based on certain output from the system or application.

Are logs encrypted at rest and in transit? If you ship them elsewhere, is the destination compliant? If shipped to a third party, do you have a BAA with that service provider?

Logs retained minimum 90 days

There is debate, like other items in this list, to the exact duration required in which logs should be retained to meet compliance. We suggest in the 90 day range. Interestingly, a BAA often governs this value. For example, some covered entities might want logs to be destroyed very quickly to minimize the threat vector of stale logs hanging around. Some covered entities prefer to have logs retained for several years in the event a law suit might occur. Facilitating the variability required by potential partners is a wonderful demonstration to the headache of aligning BAAs.

Do you retain your logs for 90 days?

Patch management of all systems and components

Security vulnerabilities are continually discovered. Unpatched systems expose your cloud environment to risk of unauthorized access. This is one of the most commonly exploited threats.

Do you have a policy and associated procedure to identify, test, and install patches for your cloud services?

Penetration testing done periodically within 12 month window

A penetration test is a required job to meet compliance. Officially, it must be done annually in order to pass annual audits. We suggest considering a test more often than that if possible.

Have you conducted a penetration test in the last 12 months? Do you have one scheduled before your next audit season?

System clocks synchronized and locked down from being changed

This is a trivial concept in writing, but a major and central isolated control called out by most compliance regimes. System clocks must be centralized or just about every control on this list is deemed untrustworthy.

Are the system clocks powering the cloud environment synchronized?

Disable remote access by 3rd parties

You should restrict direct access to your cloud networks and environments from the Internet. The only way to directly access your cloud environments should be through secure, restricted connections like VPNs and bastion hosts.

Have you disabled public access to your cloud environments?

Administrative Layer

Item

Description

Assessment

Privacy and Security officers appointed

A basic requirement of HIPAA compliance is appointing Privacy and Security Officers. Ideally they are two different people for business continuity reasons. We suggest aligning the Privacy Officer with the business and compliance part of the business while aligning the Security officer with the cloud native technical side of the business.

Have you appointed a Privacy Officer? Security Officer?

Policies administering all cloud controls in place

You must have a set of organization policies in place to meet even Maturity Stage 1 of the HITRUST CSF. Datica has open sourced their policies designed specifically for cloud companies. You can find it at datica.com/open-source

Do you have written policies in place?

Policies reviewed within last 12 months

Once you have administrative policies in place, it is required to review them annually. Because of the fast pace of the cloud, and the inevitable new cloud technology associated to your environments, you should consider reviewing more frequently. We suggest every 6 months.

Have you reviewed your company policies within the last 12 months?

Risk assessment completed within last 12 months

You should complete an internal company risk assessment every 12 months. A risk assessment is a comprehensive look at your entire organization, not just the cloud technology part. However, the cloud aspects are getting to be a harder part of assessments because of how challenging abstraction and liability is becoming with services on the cloud.

Have you completed a risk assessment in the last 12 months?

Signed BAAs in place for all 3rd party service providers who handle your PHI

You must have BAAs signed for all partners who touch PHI you own. Within the scope of cloud environments, this means any technology service provider, like a managed database service for example, must sign a BAA with you

Do you have a signed BAA with each partner in your cloud ecosystem?

Process for software changes approved by Security Officer

There is debate to the extent at which this HIPAA rule applies, but in essence, major software changes to a cloud environment must be approved by the appointed Security Officer. Your milage may vary as to how this is scoped, but just know that it is a control in which auditors will investigate closely. We suggest at minimum providing a defined policy by which software is determined if it should be reviewed or not, and then in addition, for that which must be reviewed, a procedure in place for the Security Officer to approve the change.

Do you have a policy in place that defines which software changes must be approved by the Security Officer? Do you have a procedure in place for which the Security Officer approves changes that meet that policy?

HIPAA training for all employees with access to cloud systems, data, and software

You must train all employees who touch the organization associated to the cloud environment on HIPAA compliance. Employees must take the training when they start employment, and every year thereafter. The hard part is coming up with the training, but the procedure is easy, which is why Datica open sourced their training available at training.datica. com.

Do you have training content and procedures in place for employees?

Business continuity protocols in place for cloud systems

This control basically wraps everything all up into one. You must have documented policies, processes, and procedures in place for your business to handle any adverse change that could affect the business. So this isn't just disaster recovery should a tornado hit a datacenter, for example. It's also ensuring that if the CTO of your company dies, the root cloud encryption key for all PHI isn't lost forever. Things like that which are littered up and down the cloud stack.

Do you have a business continuity plan in place for all layers of the cloud environment?

Need Compliance Help?

Talk to the experts.

Related