What Makes Software HIPAA Compliant: A Buyer's Checklist

No application is automatically “HIPAA compliant.” HIPAA compliance is an ongoing organizational responsibility: risk analysis, policies, workforce practices, vendor oversight, and technical safeguards all have to work together. Software can support that responsibility—or make it much harder to meet.

For a buyer or technology leader, the useful question is not “Is this product HIPAA certified?” There is no official HIPAA certification for software. The better question is: does this system give our organization the controls, evidence, and operational visibility needed to protect electronic protected health information (ePHI)?

This guide explains what to look for when buying or building software that handles ePHI, which technical safeguards matter, what a Business Associate Agreement does and does not prove, and how to evaluate a vendor without relying on vague “enterprise-grade security” claims.

HIPAA-Compliant Software at a Glance

Question	Practical answer
Can software be HIPAA certified?	No. HIPAA does not offer a formal software certification program.
Who is accountable for compliance?	The covered entity and, where applicable, its business associates. A vendor cannot take that responsibility off your hands.
What should software provide?	Access control, audit controls, data protection, secure transmission, recovery capability, and evidence that those controls operate as intended.
Does a BAA prove security?	No. A BAA establishes contractual obligations. It should be supported by architecture, security, and operational evidence.
Where should a project start?	With a documented risk analysis that identifies where ePHI is created, stored, transmitted, accessed, and backed up.

Important: This article is general technical information, not legal advice. HIPAA obligations depend on your role, contracts, systems, jurisdictions, and risk profile. Work with qualified privacy, security, and legal professionals when making compliance decisions.

Table of Contents

• What Does HIPAA-Compliant Software Actually Require?
• Technical Safeguards to Evaluate or Build
• Administrative and Physical Safeguards
• What a Business Associate Agreement Does—and Does Not—Do
• Vendor Due-Diligence Checklist
• Common Implementation Failures
• A Practical Implementation Plan
• How Ridiculous Engineering Can Help
• FAQ
• Sources

What Does HIPAA-Compliant Software Actually Require?

The HIPAA Security Rule organizes safeguards into three categories: administrative, physical, and technical. Software lives mostly in the technical category, but it cannot compensate for missing policies, unclear ownership, untrained staff, weak vendor oversight, or an organization that does not know where its ePHI resides.

The U.S. Department of Health and Human Services treats a documented risk analysis as the foundation of the Security Rule. Before selecting controls, your organization needs to understand:

• Which systems create, receive, maintain, or transmit ePHI
• Where ePHI is stored, including backups, logs, exports, and analytics platforms
• Which users, administrators, vendors, and subcontractors can access it
• How data moves between applications, devices, environments, and integrations
• What could reasonably compromise confidentiality, integrity, or availability
• Which safeguards reduce those risks to an appropriate level

That inventory is also a good starting point for software consulting and delivery support. Many compliance problems are not caused by one missing security feature. They come from an unclear system boundary: a production application is controlled, but a support export, analytics replica, or third-party integration is not.

Required vs. Addressable Specifications

HIPAA implementation specifications are categorized as either required or addressable.

• Required specifications must be implemented as written.
• Addressable specifications must be assessed. If a specification is not reasonable and appropriate in your environment, you need to document why and implement an equivalent alternative safeguard where appropriate.

“Addressable” does not mean optional. It means the decision must be based on risk, documented, and defensible. Encryption is a common example: HIPAA does not prescribe one universal implementation for every system, but an organization that decides not to encrypt ePHI needs a strong, documented risk-based rationale.

HIPAA documentation, including policies, procedures, risk assessments, and related records, generally must be retained for six years under 45 CFR §164.316.

Technical Safeguards to Evaluate or Build

Technical safeguards should be visible in the application architecture, cloud configuration, operational runbooks, and evidence a vendor can provide. A feature checklist is not enough; the controls must be correctly implemented and operated over time.

1. Unique Identity and Access Control

Every user who accesses ePHI should have an individual identity. Shared accounts make access review, incident investigation, and offboarding unnecessarily difficult.

At a minimum, evaluate:

• Unique user IDs rather than shared credentials
• Role-based or attribute-based access control tied to job responsibilities
• Multi-factor authentication for privileged and remote access
• Session timeouts and reauthentication for sensitive actions
• Formal joiner, mover, and leaver processes
• Regular access reviews, especially for administrators and support personnel

A billing user may need access to demographic and claim information but not clinical notes. A support engineer may need operational telemetry but not unrestricted access to patient records. Those distinctions should be represented in the authorization model, not left to policy alone.

2. Audit Controls and Useful Logs

HIPAA requires mechanisms to record and examine activity in systems containing or using ePHI. In practice, useful audit logging should answer: who did what, to which record, when, from where, and whether the action succeeded.

For applications handling sensitive health data, log events commonly include:

• Authentication attempts and account lockouts
• Patient-record views, changes, exports, and deletions
• Permission and role changes
• Administrative access and support actions
• Bulk data access or unusual query behavior
• Integration failures and retries involving ePHI

Logs should be protected from unauthorized alteration, retained according to your policy and risk requirements, and reviewed through a defined process. A log that exists but is never monitored or cannot be searched during an investigation is only partial evidence of control.

3. Data Protection, Encryption, and Key Management

Protect ePHI in transit with current transport encryption, typically TLS. Protect stored ePHI with encryption appropriate to the risk and system architecture, including databases, object storage, backups, and mobile devices where applicable.

Encryption is only as useful as its key management. Ask who owns keys, where keys are stored, how access is controlled, whether keys are rotated, and what happens if a credential or key is exposed.

The NIST HIPAA Security Rule resource guide is a useful technical reference for mapping safeguards to implementation considerations. It is not a substitute for a risk analysis, but it is considerably more useful than a vendor security slogan.

4. Integrity, Change Management, and Secure Delivery

Systems need controls that help prevent improper alteration or destruction of ePHI. For custom software, that means treating deployment and infrastructure changes as part of the compliance surface.

• Use peer review and controlled source-code repositories.
• Separate development, test, and production environments.
• Restrict production access and record privileged actions.
• Test security-sensitive workflows before release.
• Maintain rollback and incident-response procedures.
• Track dependencies and apply security patches through a managed process.

These practices are core to dependable custom software development. Retrofitting audit trails, permissions, and operational controls after a product has accumulated real patient data is substantially harder than designing the boundaries correctly from the start.

5. Backup, Recovery, and Availability

Availability is part of protecting ePHI. Backups should be encrypted, access-controlled, monitored, and tested through actual restore exercises. A backup strategy that has never been restored under realistic conditions is an assumption, not a recovery capability.

Define recovery objectives that fit the clinical or operational impact of a system outage. A patient scheduling portal, a care-management system, and a historical analytics platform may all warrant different recovery time and recovery point objectives.

Administrative and Physical Safeguards Still Matter

Software is one part of the system. HIPAA compliance also depends on administrative and physical safeguards that no application can provide by itself.

Administrative Safeguards

• Named privacy and security officials with defined authority
• Documented risk analysis and risk-management process
• Policies for access, acceptable use, incident response, and vendor oversight
• Workforce training and evidence that training occurred
• A sanctions process for policy violations
• Regular review of system activity and security events

Physical Safeguards

Physical safeguards may include workstation controls, device inventory, media disposal procedures, facility access controls, and verification of the physical protections provided by cloud and hosting vendors. A properly designed application cannot protect ePHI copied to an unmanaged laptop or exported to an unapproved USB drive.

Patient-facing systems should also be usable by the people who need them. For portals and workflows used by patients, staff, or caregivers, security requirements should be designed alongside accessibility and usability requirements. Our UX design and accessibility practice can help teams avoid turning a secure workflow into one users bypass because it is unnecessarily difficult to use.

What a Business Associate Agreement Does—and Does Not—Do

A vendor is generally a business associate when it creates, receives, maintains, or transmits ePHI on behalf of a covered entity or another business associate. The relationship usually requires a Business Associate Agreement (BAA).

A BAA should establish permitted uses of ePHI, safeguard obligations, incident and breach reporting responsibilities, subcontractor requirements, and procedures for return or destruction of ePHI at contract termination. The organizational requirements are described in 45 CFR §164.314.

But a signed BAA is a contract, not evidence that technical controls are effective. Before relying on a vendor, ask for evidence appropriate to the service and risk profile:

• Architecture and data-flow diagrams showing where ePHI is stored and transmitted
• A list of subprocessors and confirmation of BAA flow-down obligations
• Access-control and identity-management practices
• Audit-log examples or a clear explanation of available audit events
• Vulnerability-management and patching procedures
• Backup, recovery, and incident-response processes
• Relevant independent security assessments, with scope and date clearly stated

“We are HIPAA compliant” without supporting documentation is not a complete procurement answer. Neither is “our cloud provider is compliant.” Your implementation, configurations, data flows, and operational practices still matter.

Vendor Due-Diligence Checklist

Use these questions in an RFP, security review, procurement meeting, or technical discovery session.

• Where is ePHI stored, processed, backed up, and logged?
• Which staff roles can access production data, and how is that access approved and reviewed?
• Can privileged access be time-limited, logged, and revoked?
• Which audit events are captured, how long are logs retained, and how can they be exported?
• How are encryption keys protected, accessed, and rotated?
• Which subcontractors touch ePHI, and are BAAs in place throughout the chain?
• How quickly will the vendor notify your organization about a suspected security incident?
• How are vulnerabilities identified, prioritized, and patched?
• How often are backups restored and recovery procedures tested?
• Can the system support your organization’s access-control, retention, and audit requirements without custom workarounds?

For leadership teams deciding between a purchased platform and a tailored system, our build-vs-buy software decision checklist is useful alongside this evaluation. HIPAA concerns do not automatically require custom software, but they often expose where a generic product’s data model, permissions, or integration constraints do not fit the actual operating model.

Common Implementation Failures

Most incidents are not caused by exotic attacks. They result from ordinary controls that were never designed, configured, tested, or assigned to an owner.

• Assuming a BAA makes the implementation compliant. Contracts matter, but they do not configure permissions or validate backup recovery.
• Using shared accounts. Shared credentials undermine accountability and make offboarding risky.
• Logging too little. Recording logins but not sensitive record views, exports, or administrative actions creates blind spots.
• Leaving cloud storage or development environments exposed. Non-production data, test backups, and exports often receive less scrutiny than production systems.
• Skipping restore tests. A backup process that has never been tested can fail when the organization most needs it.
• Granting broad admin access “temporarily.” Temporary access tends to outlive the emergency that justified it.
• Ignoring integrations. ePHI frequently moves through interfaces, queues, analytics tools, support systems, and notification services.

Integrations deserve special attention because data can leave a well-controlled application through a poorly controlled downstream workflow. If your project includes reporting, operational dashboards, or data pipelines, involve data analytics and business intelligence expertise early enough to establish appropriate data minimization, access controls, and governance for replicated datasets.

A Practical Implementation Plan

Do not treat HIPAA preparation as a final pre-launch checklist. Build it into the delivery sequence.

1. Map the data and system boundary. Identify every place ePHI enters, moves, rests, is backed up, or can be accessed.
2. Conduct and document a risk analysis. Prioritize risks by likelihood, impact, and the effectiveness of existing safeguards.
3. Define ownership. Assign responsibility for privacy, security, access reviews, incident response, vendor management, and recovery testing.
4. Design controls into the architecture. Build authorization, auditability, encryption, secure integrations, and recovery into the system rather than adding them after the core application is complete.
5. Validate before production use. Test access boundaries, audit events, incident procedures, backups, and critical workflows with realistic data paths.
6. Operate and improve. Review access, patch vulnerabilities, reassess risk after material changes, test recovery, and keep documentation current.

If the software uses AI for document processing, patient communication, triage support, knowledge retrieval, or workflow automation, give that component its own risk and governance review. The AI capability does not change HIPAA obligations, and it introduces practical questions about model access, data retention, evaluation, and human oversight. Those are areas where AI development and automation should be designed with the same discipline as the rest of the application.

Building Healthcare Software Without the Guesswork

Ridiculous Engineering helps organizations design and build custom systems with real operational requirements in mind: role-based access, meaningful audit trails, secure integrations, controlled delivery practices, and architecture documentation that technical and compliance stakeholders can both use.

We do not certify organizations as HIPAA compliant or replace legal counsel, privacy officers, security officers, or formal risk assessments. We can work alongside those stakeholders to make the technical implementation match the organization’s risk decisions and delivery reality.

FAQ

Is there such a thing as HIPAA-certified software?

No. HIPAA does not provide an official certification for software products. Compliance depends on how a covered entity or business associate designs, configures, operates, and governs systems that handle ePHI.

Does signing a BAA make a vendor HIPAA compliant?

No. A BAA establishes contractual responsibilities for handling ePHI. It does not prove that a vendor’s access controls, logging, encryption, incident response, or recovery processes are adequate or operating effectively.

What is the difference between required and addressable HIPAA specifications?

Required specifications must be implemented. Addressable specifications must be assessed to determine whether they are reasonable and appropriate for the organization’s environment; decisions and alternative safeguards must be documented where applicable.

How long must HIPAA documentation be retained?

HIPAA policies, procedures, risk assessments, and related documentation generally must be retained for six years from the date of creation or the date they were last in effect.

Can custom software support HIPAA compliance?

Yes. Custom software can support HIPAA obligations when it is designed with appropriate access controls, auditability, secure data handling, dependable integrations, and operational processes. The organization still needs risk analysis, policies, oversight, and qualified legal and compliance guidance.

Sources

• U.S. Department of Health and Human Services: Guidance on Risk Analysis
• Electronic Code of Federal Regulations: HIPAA Security Standards
• 45 CFR §164.314: Organizational Requirements and Business Associate Contracts
• 45 CFR §164.316: Policies, Procedures, and Documentation Requirements
• NIST SP 800-66 Rev. 2: Implementing the HIPAA Security Rule

Recommended

• Build vs. Buy Software: A Decision Checklist for Leaders
• Custom Software Development
• Software Consulting and Delivery Support
• UX Design and Accessibility

```