HIPAA does not issue a general certification declaring software developers "HIPAA compliant." Whether a development partner must comply with HIPAA depends on its role, the services it performs, and whether it creates, receives, maintains, or transmits protected health information (PHI) on your behalf. If it does, it is likely a business associate under HIPAA and must enter into a Business Associate Agreement (BAA) with you before accessing PHI. Signing a BAA is necessary where required, but it does not, by itself, make an application or a vendor compliant. Compliance depends on the actual safeguards, practices, and responsibilities in place across the entire development lifecycle.
A "HIPAA-compliant developer" is one that understands its legal role, signs a BAA where required before accessing PHI, implements appropriate administrative, technical, and physical safeguards, and can demonstrate those practices through documentation and evidence. HIPAA has no official certification for software development agencies -- claims require verification.
What Does "HIPAA-Compliant Developer" Actually Mean
The phrase gets used loosely. Vendors use it in sales materials, on their websites, and in proposals -- but it can mean several different things, and buyers should ask exactly what a vendor means by it.
A covered entity is a health plan, healthcare clearinghouse, or healthcare provider that transmits health information electronically. A business associate is a person or organization -- including technology vendors and software developers -- that performs functions or services for a covered entity (or for another business associate) that involve creating, receiving, maintaining, or transmitting PHI. A covered entity may disclose PHI to a business associate only after obtaining satisfactory assurances through a BAA.
Not every technology vendor that works with a healthcare organization is automatically a business associate. An IT contractor who has only incidental access to PHI without performing a function involving PHI may not be. A cloud-based software developer building a patient portal and hosting it in production -- with direct access to ePHI -- almost certainly is. The answer turns on the facts of the arrangement.
Here is what the phrase can legitimately describe -- and what it cannot:
- The vendor has acted as a business associate, signed BAAs, and operates under applicable HIPAA obligations
- The development process includes safeguards designed to meet applicable HIPAA Security Rule requirements
- The vendor understands its responsibilities and can demonstrate them through documentation
- A formal government certification -- HIPAA has no official certification program for software developers
- A guarantee that any specific application is compliant with all applicable requirements
- That the vendor's compliance posture automatically extends to the product it builds for you
When a vendor offers a logo, badge, or certificate as proof of HIPAA compliance, ask what it represents: which assessment was conducted, who conducted it, what it covered, and when. the HIPAA-compliant software development report lists firms that serve healthcare clients -- but no report listing substitutes for your own due diligence on a vendor's specific practices.
The Actual HIPAA Requirements a Development Partner Must Understand
1. Business Associate Agreement
If a software development company will create, receive, maintain, or transmit PHI on your behalf, it is a business associate and a BAA is required before it accesses that PHI. This is not optional. The BAA must describe the permitted uses and disclosures of PHI, prohibit unauthorized use or further disclosure, require the vendor to implement applicable Security Rule safeguards, and require reporting of security incidents -- including breaches of unsecured PHI.
If the vendor uses subcontractors -- a cloud provider, a logging service, an AI vendor -- those subcontractors who handle PHI are also business associates. Each requires its own BAA. Buyers should ask which subcontractors will touch PHI and confirm that downstream agreements exist.
A signed BAA is a necessary condition, not a sufficient one. It documents responsibilities; it does not enforce them. The safeguards still have to be real.
2. Administrative Safeguards
The HIPAA Security Rule requires covered entities and business associates to implement administrative safeguards including: a risk analysis to identify threats and vulnerabilities to ePHI; a risk management process to reduce identified risks to a reasonable and appropriate level; workforce access controls and training; assigned security responsibilities; contingency planning; and incident response procedures. A development partner should be able to describe how it manages these for its own organization and how it accounts for them in the systems it builds.
3. Technical Safeguards
The Security Rule requires technical safeguards to control access to ePHI. Required specifications include unique user identification, emergency access procedures, and audit controls -- mechanisms to record and examine activity in systems containing ePHI. Addressable specifications -- which must be implemented if reasonable and appropriate, or documented with an alternative -- include automatic logoff, encryption and decryption, and integrity controls.
In practice, a development partner building a system that handles ePHI should implement:
- Access controls based on the least-privilege principle -- users and services access only what they need
- Unique user identification and appropriate authentication, including multifactor authentication for sensitive access
- Audit logging -- who accessed what, when, and what action occurred
- Encryption of ePHI at rest and in transit, with documented key management
- Integrity controls to detect unauthorized alteration or destruction of ePHI
- Session management and secure application design practices
The Security Rule does not specify a required encryption algorithm or a universal key-rotation schedule. "Addressable" does not mean optional -- it means the covered entity or business associate must assess whether the specification is reasonable and appropriate for their environment, and document the decision either way.
4. Physical Safeguards
Physical safeguards cover facilities, workstations, and devices. For a software development partner, this includes controls over who can physically access systems containing ePHI, how workstations are secured, and how devices (laptops, storage media) are managed and disposed of. Remote development environments and bring-your-own-device practices should be addressed explicitly.
5. Secure Development and Testing
One of the highest-risk areas for development partners is the handling of PHI in non-production environments. Development, test, staging, and QA environments are frequent points of exposure -- particularly when production data is used without restriction. A responsible partner should use synthetic or appropriately de-identified test data, restrict production access to only those who need it, manage secrets (API keys, credentials) securely, perform dependency management and vulnerability scanning, and apply release controls before deploying to production.
If you are evaluating firms that build patient-facing mobile applications, review their specific controls for device-level data handling -- see the HIPAA-compliant mobile app developers report for firms specializing in this area.
6. Audit Logging and Incident Response
Useful audit logs should help an organization determine who accessed information, what action was taken, and when it occurred -- and should support investigation of suspicious activity. Audit logging is a required Security Rule specification. Incident response -- the process for identifying, responding to, mitigating, and documenting security incidents, and reporting breaches to covered entities within the timeframes required by the Breach Notification Rule -- is a separate and equally important requirement.
7. Cloud Providers and Subcontractors
Using AWS, Azure, Google Cloud, or any other cloud platform with a HIPAA-eligible service offering does not make an application compliant. HHS guidance confirms that a cloud service provider that creates, receives, maintains, or transmits ePHI -- even if it stores only encrypted data and holds no decryption key -- is a business associate and requires a BAA. The BAA and the application configuration, access controls, and organizational practices all remain the covered entity's or business associate's responsibility. OCR does not endorse or certify any cloud provider.
For AI systems that process PHI -- including AI models integrated into healthcare applications -- the same logic applies. Any AI vendor or model provider that handles ePHI on your behalf is a business associate. the healthcare AI development report covers firms building in this space.
Need a shortlist of firms with verified HIPAA compliance practices? Browse development partners who serve healthcare clients.
HIPAA-Compliant Developers ReportHow to Verify a Development Partner Before Signing
You cannot verify compliance from a website. Verification requires requesting specific evidence, reviewing it critically, and confirming that it is relevant to your specific project.
HHS notes that the HIPAA Rules do not require cloud service providers (or vendors generally) to provide security documentation or allow customer audits -- but they can be required to do so contractually. Buyers should negotiate for the evidence they need as part of the engagement. A vendor that refuses to share any documentation should be treated with caution.
| What to verify | Evidence to request | What it helps establish |
|---|---|---|
| BAA and contractual responsibilities | Proposed BAA and relevant contract terms | Whether responsibilities are documented before PHI access |
| Risk management | Risk assessment process and remediation examples | Whether risks are identified and addressed systematically |
| Access controls | Role and permission model, access review process | Whether access to PHI is restricted appropriately |
| Encryption | Architecture documentation and key-management approach | How ePHI is protected at rest and in transit |
| Audit logs | Sample or redacted logging design | Whether access and actions can be investigated |
| Development practices | Secure SDLC and testing procedures | Whether security is built into the delivery process |
| Incident response | Incident response plan and reporting commitments | How incidents are handled and when you are notified |
| Subcontractors | Subprocessor inventory and applicable agreements | Whether downstream responsibilities are addressed |
SOC 2, ISO 27001, and HITRUST are different assurance mechanisms and frameworks -- none should be treated as interchangeable with HIPAA compliance, or as automatically proving that a specific application meets all applicable HIPAA requirements. A SOC 2 Type II report covers controls relevant to its defined scope over a specified period. ISO 27001 is an information security management standard. HITRUST includes HIPAA-relevant control categories. Each provides useful evidence, but buyers should evaluate the scope, date, and exclusions of any report against their specific project requirements.
Five Questions to Ask Before Hiring a HIPAA Software Development Partner
A BAA is legally required where the developer is a business associate. Without one executed before PHI access, you have a compliance exposure regardless of the vendor's technical capabilities. Subcontractors that handle PHI require their own BAAs.
The vendor should confirm its business-associate status, explain that the BAA is executed before PHI access begins, and provide a list of subcontractors (cloud providers, monitoring tools, logging services, AI vendors) that will touch PHI and confirm downstream BAAs exist.
Development and test environments are common points of PHI exposure. Support tickets, error logs, and analytics tools can inadvertently capture PHI. Each represents a potential unauthorized disclosure.
Specific practices: use of synthetic or de-identified test data, restricted production access, log scrubbing or redaction, review of third-party tools for PHI ingestion, and controlled access to troubleshooting environments.
These are not optional features. Access controls, audit logging, and encryption of ePHI are Security Rule requirements. "Verify" matters as much as "implement" -- controls that are not tested or reviewed are controls that may not work.
A specific architecture explanation: role-based access with least privilege, how encryption is implemented and keys are managed, what audit logs capture, how they are retained, and how they are reviewed. Not a generic claim about "bank-level security."
Risk analysis is a required Security Rule standard. Incident response and breach notification obligations are contractual and legal requirements. You need to know how fast they will tell you about a problem and what their process looks like.
Named security responsibilities, a documented risk assessment process, how vulnerabilities are tracked and remediated, incident escalation steps, and what breach notification commitments they will contractually commit to (timing, format, scope of notification).
General claims about a vendor's security posture may not be relevant to your project's specific PHI flows, integrations, hosting environment, and risk profile. Evidence should be specific to what you are building.
Relevant documentation, appropriately scoped assurance reports (SOC 2, HITRUST, or similar -- with the buyer evaluating scope and recency), project examples demonstrating relevant healthcare experience, and a transparent account of where gaps exist and how they will be addressed.
Building a HIPAA-compliant mobile app? See firms specializing in HIPAA-compliant mobile development with clinical deployment experience.
HIPAA Mobile App DevelopersRed Flags That Should Make You Pause
- The vendor claims a logo or certificate proves complete HIPAA compliance without explaining its scope or what was assessed
- The vendor resists discussing a BAA when the arrangement would require one, or wants to defer it until after work begins
- The vendor cannot explain how PHI is controlled in development, testing, support, and logging environments
- All developers or contractors receive broad access to production systems and PHI by default
- The vendor cannot describe its audit logging design or incident response process
- The vendor assumes the cloud provider's HIPAA-eligible service handles every compliance responsibility
- Security is treated as a final QA step rather than a practice built into the development lifecycle
- The vendor cannot account for which subcontractors will touch PHI or whether those subcontractors have BAAs
None of these individually necessarily proves a legal violation in every context. But each reflects a gap in understanding or practice that warrants direct follow-up -- and that should influence your risk assessment of the vendor.
What to Address in Your Contract and Statement of Work
Before engaging a healthcare software development partner, work with your legal, compliance, and security teams to address the following areas in your contract and statement of work:
- Scope of work and data flows -- which PHI the vendor will access and for what purpose
- Responsibility allocation between parties for each applicable Security Rule requirement
- BAA execution and applicable subcontractor agreements, including downstream vendors
- Security requirements and acceptance criteria for the delivered system
- Access approvals and restrictions -- who can access production data and under what conditions
- Incident reporting obligations: timing, notification format, and escalation path
- Documentation and evidence delivery -- what security artifacts the vendor will provide on request
- Vulnerability remediation SLAs and ongoing maintenance responsibilities
- Data retention, return, and deletion at the end of the engagement or on termination
- Change management and production deployment controls
- Exit procedures and transition support
The specific terms should be tailored to the project, the parties' roles, and qualified legal advice. This checklist is a starting point for your conversations with counsel -- not a substitute for it.
Need a development partner with EHR integration and compliance expertise? Browse firms in the EHR/EMR development report.
EHR / EMR Development ReportChoosing the Right Partner for Your Healthcare Software Project
The best partner is not the one making the strongest compliance claim. It is the one that can explain its responsibilities clearly, demonstrate appropriate security practices through documentation, understand your product's healthcare workflows, and work collaboratively with your legal, compliance, and security teams throughout the engagement.
Healthcare product experience and security capability are related but distinct. A vendor with deep healthcare workflow knowledge may have gaps in its security practice. A vendor with strong security credentials may not understand clinical workflows, HL7 FHIR integrations, or the user-experience requirements of patient-facing products. Verify both independently.
For custom healthcare platforms and interoperability requirements, healthcare software development report covers firms across specializations. For patient-facing apps, the healthcare app development report is a useful starting point. Teams building patient portals and web-based care tools can explore healthcare web development firms. Telehealth and video consultation applications carry specific requirements around secure messaging and third-party services -- the telemedicine app development report covers firms in this space. For connected device and remote monitoring work where PHI flows across device ecosystems, the healthcare IoT development report is relevant.
Use this checklist when making your vendor decision:
- The type of product -- mobile app, web platform, device integration, AI system -- and its specific PHI flows
- Which PHI the vendor will access and in which environments (development, test, production, support)
- Required integrations -- EHR systems, payers, device data, third-party services -- and their security implications
- The vendor's access to data and production systems throughout and after the engagement
- The quality and relevance of security documentation and contractual commitments
- Ongoing maintenance, patching, vulnerability response, and incident handling responsibilities