If your custom software creates, stores, or transmits protected health information (PHI), HIPAA isn't optional and it isn't a feature you bolt on at the end — it's an architecture decision that shapes the build from day one. This HIPAA compliance checklist for custom software covers what a PHI-handling application actually needs, whether you're building it in-house or commissioning it from a HIPAA-experienced custom software developer. It's the same ground we walk with every healthcare client before a line of code gets written.
First, clear up the biggest myth. There is no official government "HIPAA certification" for software. HHS and its Office for Civil Rights do not certify or endorse any product as "HIPAA compliant," and a vendor claiming a government HIPAA certificate is making a misleading claim (HHS). Compliance is something you demonstrate through documented safeguards and a risk analysis — not a badge you buy. And the stakes are real: healthcare has had the most expensive data breaches of any industry for 14 straight years, averaging $9.77 million per breach in 2024 (IBM).
The HIPAA Security Rule starts with process, not code. Before launch, and repeatedly after, you need the paperwork that proves you thought this through.
Complete a documented risk analysis. This is explicitly required, not optional — an accurate, thorough assessment of the risks to the confidentiality, integrity, and availability of all ePHI you handle, repeated whenever the system materially changes (45 CFR 164.308(a)(1)).
Define role-based access policies built on the minimum necessary principle — each role sees only the PHI it needs to do its job (HHS).
Have a breach-notification plan. The Breach Notification Rule requires notifying affected individuals and HHS without unreasonable delay and no later than 60 days after discovery (HHS).
These are the build requirements — the controls that live in the code and infrastructure, drawn from the Security Rule's technical safeguards (45 CFR 164.312).
Unique user IDs for every user — no shared logins, ever, so activity is attributable to a person.
Encrypt PHI in transit and at rest. Both are technically "addressable" specs, but addressable does not mean optional — you implement it or document an equivalent alternative, and in practice encryption is the expected control.
Authentication and automatic logoff — verify users are who they claim to be (multi-factor is now the baseline expectation) and end idle sessions automatically.
Audit controls — record who accessed or changed which PHI and when. Audit logging isn't a nice-to-have; it's a named requirement.
Integrity controls — mechanisms to detect improper alteration or destruction of PHI.
Host on infrastructure with facility, workstation, and device controls (45 CFR 164.310). For most modern builds this means a cloud provider whose physical safeguards you've confirmed — and whose scope you understand, because their compliance covers their layer, not your application.
This is where teams get caught, because the obligation extends to everyone you rely on.
Sign a Business Associate Agreement (BAA) with every vendor that touches PHI — your cloud host, transactional email service, SMS provider, analytics, error monitoring. The requirement flows down to their subcontractors too (HHS). If a tool in your stack won't sign a BAA, it can't touch PHI.
Keep your documentation audit-ready — the risk analysis, access policies, BAAs, and audit-log samples. Since there's no certificate, this documentation is your proof of compliance.
If your software handles substance-use disorder records from a federally assisted program, 42 CFR Part 2 applies on top of HIPAA and is stricter — it generally requires patient consent for disclosures that HIPAA alone would permit. A 2024 final rule brought Part 2 closer to HIPAA but didn't eliminate it (HHS). If you're building for a mental-health or addiction-treatment practice, treat consent management and record segmentation as first-class features — we go deeper on this in our guide to 42 CFR Part 2-compliant software and our work on Zoho for behavioral health.
Work top-down: risk analysis first, because it tells you which of these safeguards matter most for your specific data and workflows, then the technical controls, then the vendor paperwork. Don't treat this as a launch-day checklist — the risk analysis and audit posture are ongoing.
If you're scoping a healthcare build and want to get the compliance architecture right the first time, book a free consultation and we'll walk your data flows, flag the HIPAA and Part 2 questions specific to your product, and tell you honestly where the real risk sits. It's a lot cheaper than the alternative — and the alternative averages $9.77 million.
By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a custom software engineering firm writing from work we've actually shipped for clients.
In a no-risk discovery we look at how a patient moves from intake to billing across your systems today and show what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Database Design Basics for Custom Software: A Practical Guide (article)
Zoho CRM Modules Explained: When to Build a Custom One (and When Not To) (article)
The Field You Add Today Is The Migration You Pay For Later | Zoho CRM Custom Fields (video)
No. HIPAA applies to covered entities, meaning health plans, clearinghouses and providers that bill electronically, and to the business associates that handle protected health information on their behalf. A consumer wellness app that a person uses on their own, with no provider or insurer involved, is generally outside HIPAA, though other privacy laws may apply. The same app becomes subject to HIPAA the moment a provider uses it to handle patient data.
The Security Rule requires that policies, procedures and records of required actions be retained for six years from the date they were created or last in effect. Audit log retention is set through your own policy under that rule, and six years is the figure most organisations adopt for logs that document access to PHI. Design the storage for that horizon from the start, because moving years of logs between systems later is expensive and error prone.
Protected health information is any individually identifiable health information that a covered entity or business associate creates, receives, stores or transmits, in any form. In a build that means not only diagnoses and treatment notes but also appointment dates, billing records, device identifiers and contact details when they are linked to care. Treat any field that could connect a person to a health service as PHI unless you have confirmed otherwise.
Data that has been de-identified under the HIPAA rules is no longer PHI and can be used without the Privacy Rule's restrictions. De-identification means either removing the eighteen identifiers listed in the rule, including dates and small geographic areas, or having a qualified expert determine that the risk of re-identification is very small. Simply deleting names is not enough, and the process you used should be documented.
The rule requires an accurate and thorough risk analysis but does not set a fixed interval. Common practice is to repeat it at least once a year and whenever the system changes materially, for example a new integration, a new hosting arrangement, a new category of data or a significant change in who has access. A build that ships monthly should treat the risk analysis as a living document that is updated with the release notes.
A business associate agreement sets out what the vendor may do with PHI, requires appropriate safeguards, obliges the vendor to report breaches and security incidents to you, flows the same obligations down to its subcontractors, gives individuals access to their data where required, and says what happens to the data when the contract ends. Keep a signed copy for every vendor that touches PHI, and check that the vendor's standard agreement actually covers the service you use.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
