HECVAT Category
HIPAA Compliance
HIPAA Compliance covers controls and questions related to that domain. It outlines expectations institutions typically require from vendors. The category helps assess risk posture and operational maturity. It provides structure for consistent evaluation during security reviews.
Assessment Questions
Do your workforce members receive regular training related to the Health Insurance Portability and Accountability Act (HIPAA) Privacy and Security Rules and the HITECH Act?
Workforce HIPAA training is the subject of this item, specifically whether your people receive regular training on the HIPAA Privacy and Security Rules and the HITECH Act.
Have you identified areas of risk?
Risk identification under HIPAA is the focus: the question asks whether you have performed a formal risk assessment to surface vulnerabilities and compliance gaps affecting Protected Health Information.
Have the relevant policies/plans been tested?
Testing of HIPAA-relevant policies and plans is what this examines, confirming that your documented safeguards have actually been exercised rather than left on paper.
Have you entered into a Business Associate Agreements with all subcontractors who may have access to protected health information (PHI)?
Subcontractor safeguards are the concern: the question is whether you have signed Business Associate Agreements with every subcontractor that may touch protected health information.
Do you monitor or receive information regarding changes in HIPAA regulations?
Buyers handling protected health data want to know that you actively track updates, amendments, and new interpretations of HIPAA regulations.
Has your organization designated HIPAA Privacy and Security officers as required by the rules?
HIPAA requires named accountability for privacy and security, and this asks whether your organization has formally designated Privacy and Security Officers as the rules mandate.
Do you comply with the requirements of the Health Information Technology for Economic and Clinical Health Act (HITECH)?
HITECH compliance is the focus here, specifically whether you meet the requirements of the Health Information Technology for Economic and Clinical Health Act, which strengthened HIPAA enforcement. The HITECH Act expanded and strengthened the privacy and security provisions of HIPAA (Health Insurance Portability and Accountability Act).
Have you conducted a risk analysis as required under the HIPAA Security Rule?
HIPAA compliance hinges on this point, which asks whether your organization has carried out the formal risk analysis the HIPAA Security Rule requires. The HIPAA Security Rule requires covered entities and business associates to conduct a thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) that they hold or process.
Have you taken actions to mitigate the identified risks?
Risk remediation is what reviewers want evidence of: whether you have actually implemented measures to address the risks surfaced by your HIPAA risk assessment. Under HIPAA, covered entities and business associates must conduct regular risk analyses to identify potential vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI). However, simply identifying risks is not enough - the Security Rule requires organizations to implement security measures to reduce these risks to a 'reasonable and appropriate' level.
Does your application require user and system administrator password changes at a frequency no greater than 90 days?
Password rotation is the subject here: whether your application forces both regular users and system administrators to change passwords at least every 90 days.
Does your application require users to set their own password after an administrator reset or on first use of the account?
Password ownership at account setup is the focus: reviewers want users to set their own password on first use or after an administrator reset, rather than keeping a temporary one.
Does your application lock out an account after a number of failed login attempts?
Brute-force resistance is what's being tested here, specifically whether your application locks out accounts after a defined number of failed login attempts. This is a fundamental security control that helps prevent brute force attacks, where attackers systematically try many password combinations to gain unauthorized access.
Does your application automatically lock or log-out an account after a period of inactivity?
Session timeout behavior is the subject here: whether your application automatically locks or logs out an account after a period of inactivity.
Are passwords visible in plain text, whether when stored or entered, including service level accounts (i.e., database accounts, etc.)?
Password exposure is under examination here, covering whether any passwords, including service-level and database accounts, are ever visible in plain text when stored or entered. This includes service accounts like database credentials.
If the application is institution-hosted, can all service level and administrative account passwords be changed by the institution?
Credential ownership is the question for institution-hosted deployments, specifically whether the institution can change every service-level and administrative account password itself.
Does your application provide the ability to define user access levels?
Granular access control is the subject here: reviewers want your application to support defined user access levels, often delivered through role-based access control (RBAC). In the context of HIPAA compliance, this is critical because the HIPAA Security Rule requires healthcare organizations to implement technical safeguards that restrict access to Protected Health Information (PHI) based on a user's role within the organization.
Does your application support varying levels of access to administrative tasks defined individually per user?
Granular administrative access is what reviewers want to confirm: whether your application can define different levels of access to administrative tasks individually for each user. In the context of HIPAA compliance, this relates to the principle of 'least privilege' - ensuring users only have access to the minimum information and functions necessary to perform their job.
Does your application support varying levels of access to records based on user ID?
Granular access is what this examines: whether your application can vary the records a user can reach based on their individual user ID.
Is there a limit to the number of groups to which a user can be assigned?
Group-membership limits are the subject: whether your system caps how many security or access groups a single user account can belong to. In the context of HIPAA compliance, this relates to access control mechanisms.
Do accounts used for solution provider-supplied remote support abide by the same authentication policies and access logging as the rest of the system?
Consistency of controls for vendor support is what's being checked, namely whether provider remote-support accounts follow the same authentication policies and access logging as everything else.
Does the application log record access including specific user, date/time of access, and originating IP or device?
Access logging detail is what's under review here, namely whether your application records the specific user, the date and time of access, and the originating IP or device. Specifically, it wants to know if your logs record:
Does the application log administrative activity, such as user account access changes and password changes, including specific user, date/time of changes, and originating IP or device?
Administrative accountability hinges on logging, and reviewers want to confirm your application records account and password changes with the specific user, timestamp, and originating IP or device. For each action, the system should record who performed it (the specific user), when it happened (date/time), and where it originated from (IP address or device identifier).
Do you retain logs for at least as long as required by HIPAA regulations?
Log retention is the focus, specifically whether you keep system and access logs for at least the minimum duration that HIPAA regulations require.
Can the application logs be archived?
Log retention is the focus of this HIPAA-related control, asking simply whether your application's logs can be archived for later reference.
Can the application logs be saved externally?
Log portability sits at the center here: whether application logs can be exported or shipped to an external system beyond the application itself.
Do you have a disaster recovery plan and emergency mode operation plan?
HIPAA resilience requirements are in scope, covering whether you maintain both a disaster recovery plan and an emergency mode operation plan. A Disaster Recovery Plan (DRP): This is a documented process for recovering IT systems, data, and infrastructure after a disaster (natural or human-caused) that disrupts normal operations. For healthcare organizations, this ensures that critical patient data remains accessible even after significant disruptions.
Can you provide a HIPAA compliance attestation document?
Evidence of HIPAA compliance is being requested here, specifically whether you can supply a compliance attestation document covering the Health Insurance Portability and Accountability Act.
Are you willing to enter into a Business Associate Agreement (BAA)?
Willingness to sign a Business Associate Agreement (BAA) with the assessing entity is what's being confirmed here.
Do your data backup and retention policies and practices meet HIPAA requirements?
HIPAA-aligned backups are the focus: whether your data backup and retention policies meet the Act's requirements for safeguarding Protected Health Information.
ResponseHub is the product I wish I had when I was a CTO
Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.
As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!
I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.
