Healthcare compliance standards in 2026: HIPAA, ISO 27001, IEC 62304
TL;DR
Healthcare compliance standards in 2026 fall into three families that answer different questions, and the guides ranking for them blur the lines. HIPAA is US law with no certificate behind it. ISO/IEC 27001 is a certifiable management system. IEC 62304 governs software that is a medical device or sits inside one, while the FDA's Computer Software Assurance guidance governs the software that builds and tracks that device.
- HHS does not endorse private HIPAA certifications, and holding one absolves you of nothing.
- ISO/IEC 27001:2022 carries 93 controls in four categories. Certificates against the 2013 edition expired on October 31, 2025.
- FDA recognizes the 2015 consolidated edition of IEC 62304. No second edition has been published.
- Declarations of conformity to the 2012 edition of AAMI TIR45 are accepted until July 2, 2028.
Where the top-ranked guides get this wrong
Two of the pages that own these queries carry arithmetic that has expired.
Scytale sets HIPAA against ISO 27001 and gets the central distinction right: one is federal law, the other is a certificate an accredited body issues for three years. Then it counts 114 ISO 27001 controls and says about 40 line up with HIPAA. Those 114 controls are the Annex A of the 2013 edition, which ISO now lists as withdrawn. The current edition carries 93 controls in four categories, including 11 that did not exist before, among them threat intelligence and secure coding.
IntuitionLabs publishes 35 minutes of reading on IEC 62304 against FDA CSA and calls the scope correctly. Then its two headline statistics turn out to have no document behind them: 80% of device companies following IEC 62304, sourced to informal trade-group surveys, and a 30% cut in validation paperwork, sourced to consultancy pilot data. The same article warns readers not to infer outcomes from unsupported aggregates.
Neither page answers the question buyers ask us first. Which of these applies to the thing I am building?
Four dates that decide your 2026 compliance plan
On February 2, 2026 the FDA's Quality Management System Regulation took effect, and 21 CFR Part 820 now incorporates ISO 13485:2016 by reference. The same day, FDA retired the Quality System Inspection Technique in favor of compliance program 7382.850. One day later the agency reissued its Computer Software Assurance guidance, superseding the final version published in September 2025 and retitling it around the quality management system.
October 31, 2025 has passed and still catches people. It ended the three-year window for moving certificates to ISO/IEC 27001:2022, after which 2013 certificates expire or are withdrawn. Check the edition on any security certificate a vendor sends you.
July 2, 2028 is the deadline nobody circles. FDA recognition of AAMI TIR45:2023 was entered on May 26, 2025, and the agency will accept declarations of conformity to the 2012 edition until that date.
On the HIPAA side, nothing has changed, and that is the news. The Security Rule overhaul proposed in January 2025 is still a proposal, and the projected date for a final rule has moved to July 2027. You will ship under the current rule and operate under the next one, so build for encryption and multi-factor access now rather than retrofitting them in 2028.
How we compared these standards
Four rules, applied to every line below.
- Requirements come from the document that carries them: HHS for HIPAA, ISO for the ISO standards, the FDA recognition database for what the agency accepts, the IEC catalogue for what has been published.
- Law is labeled law and guidance is labeled guidance. FDA guidance is nonbinding, a recognized consensus standard is not a mandate, and a proposed rule is not in force.
- Every date and number links to the record it came from. A claim with no document behind it is not here.
- Where our own delivery work is the evidence, the engagement is named and the case page is linked.
One disclosure. Mercury Development builds healthcare software for a living, so treat the sections about our own work as a supplier's view rather than a survey.
Healthcare compliance standards at a glance
Certifiable means an accredited body can award your organization a certificate. Everything else is an obligation, a control set or a report.
| Standard | What it is | What it binds | Certifiable | What your team produces |
|---|---|---|---|---|
| HIPAA Security Rule | US federal law | Covered entities and business associates handling ePHI | No | Risk analysis, safeguards, business associate agreements, periodic evaluation |
| ISO/IEC 27001 | Management system standard | Whoever adopts it, usually because a customer asked | Yes, three-year cycle | ISMS, risk treatment, statement of applicability across 93 controls |
| ISO 27799 | Health control set based on ISO/IEC 27002 | Health organizations running an ISMS | No, it is guidance | Health-specific reading of each control |
| IEC 62304 | Software life cycle process standard | Software that is a medical device or part of one | Process certification exists, FDA does not require it | Safety classification, architecture, verification records, SOUP controls |
| FDA CSA guidance | Nonbinding FDA recommendations | Software used in production or the quality management system | No | Intended use, process risk call, assurance evidence |
| AAMI TIR45 | Technical information report | Nothing by itself, it interprets IEC 62304 for agile teams | No | Layered plans and per-increment records |
HIPAA vs ISO 27001: one is law, the other is a certificate
The pairing is popular because both words sound like compliance. They are different species.
The HIPAA Security Rule is federal law requiring administrative, physical and technical safeguards for electronic protected health information, with risk analysis at the center and flexibility of approach written into the rule. It binds covered entities and business associates, which is why a wellness tracker that never touches a provider or a plan can sit outside it while a scheduling vendor sits inside it. And there is no certificate. HHS states that no standard requires a covered entity to certify compliance, that the evaluation can be done internally or by an outside firm, and that it does not endorse private certifications, which absolve you of nothing and do not stop HHS finding a violation later.
ISO/IEC 27001 is the opposite shape. Voluntary, international, certifiable by an accredited body against a management system you scope yourself. It proves an audited system exists. It proves nothing about US law.
Applies to: HIPAA to anyone handling ePHI on behalf of the US health system. ISO/IEC 27001 to any organization whose buyers want independent assurance, which usually means enterprise and European deals.
Does not cover: ISO/IEC 27001 does not deliver HIPAA compliance, and HIPAA does not ask for an ISMS. The bridge is published: NIST SP 800-66 Rev. 2 maps every Security Rule standard onto Cybersecurity Framework subcategories and SP 800-53 controls. Use it instead of assuming coverage.
ISO 27799: the health control set most security programs skip
The third edition of ISO 27799 was published on December 18, 2025 and almost nobody in digital health has opened it. It rewrites the implementation guidance of ISO/IEC 27002:2022 for health organizations, and its scope is deliberately wide: electronic health record systems, medical devices incorporating health software, even the building management equipment sitting in the same premises as care.
That last part is the reason to care. Generic security controls assume an office. Health controls assume a ward, a device on a trolley, and a clinician who will not log in twice.
Applies to: health organizations and their suppliers who already run, or plan to run, an ISO/IEC 27001 management system and want the health reading of each control.
Does not cover: certification. You certify against ISO/IEC 27001 and use ISO 27799 to interpret controls. It says nothing about device safety, which belongs to a different family.
IEC 62304 vs FDA CSA: two frameworks that rarely touch the same code
This comparison gets searched constantly and is mostly a category error. The two documents govern different software inside the same building.
IEC 62304 defines life cycle processes for software that is a medical device or is embedded in one, and stops short of validating the finished device. You classify each software item as Class A, B or C by the harm a failure could cause, and the class sets how much architecture and verification evidence you owe. FDA recognizes the consolidated edition in full under recognition number 13-79, entered on January 14, 2019. Recognition is not a mandate. It means a declaration of conformity is accepted evidence, not that the standard is law.
Computer Software Assurance points somewhere else. It covers software used in production or the quality management system: the line controller, the electronic quality system, the analytics tool watching batches. Its risk model is coarser by design, sorting features into high process risk and not high process risk, then matching the testing method to that call instead of scripting everything. Unscripted and hybrid testing are on the table, which IEC 62304 does not offer you.
Applies to: IEC 62304 to the product. CSA to the tooling that manufactures, tests and documents the product.
Does not cover: CSA is not a validation route for software as a medical device. If your product is the software, your route runs through design controls and the premarket submission guidance for device software functions.
A note on the edition everyone is waiting for. Guides published this year put the second edition of IEC 62304 in August 2026. In July 2026 the committee was still working through roughly 1,500 comments on the first draft and heading for a second one, with IEC forecasting publication in October 2028. The catalogue record still shows Edition 1.0 from May 9, 2006 with a stability date of 2028. Develop against the 2015 consolidation.
AAMI TIR45: how agile survives a software safety class
AAMI TIR45 is a technical information report, which means it is not a standard you comply with. It is the document that explains how to satisfy IEC 62304 while working in increments instead of phases, and FDA recognizes the 2023 edition as a complete standard under recognition number 13-143.
Its central move is layering. Instead of one linear pass from requirements to release, work is split across project, release, increment and story layers, and each activity sits at the layer where it belongs. Architecture and risk decisions live high. Unit verification lives low. The design record is assembled continuously rather than reconstructed the month before submission.
Applies to: teams building device software who want sprints and a defensible record at the same time. FDA lists ISO 13485, IEC 62304 and ISO 14971:2019 among the publications behind that recognition, so TIR45 assumes all three.
Does not cover: the quality system itself, and it removes no deliverable. It moves when each one is produced, which is a scheduling change with large consequences and no regulatory discount.
Which standards apply to your product
Fit splits by what your software is, not by the industry you sell into.
If your product handles ePHI for a provider, a payer or anyone acting on their behalf, HIPAA binds you and nothing else does by default. ISO/IEC 27001 becomes worth the money when enterprise buyers or European partners want independent assurance, and ISO 27799 becomes worth reading once you have decided to run an ISMS.
If your software is the device, runs inside it, or drives a clinical decision someone acts on, IEC 62304 and ISO 14971 apply inside a quality system that now points US manufacturers at ISO 13485 through QMSR. Add TIR45 if you intend to work in increments. CSA touches you only through the tools you build and release with.
If you sit in the overlap, and connected health usually does, you own both families: a device life cycle for the firmware and the companion app, a Security Rule program for the cloud holding the readings. Knowing which of those sentences describes your product is worth more than any certificate in this article.
What this looks like in software we have shipped
Two engagements show how far apart the two families sit in practice.
Precision Practice Management provides medical billing services and ONC certified electronic medical records software to doctors and hospitals across 14 states. We built AR Interactive, a claims workflow system on MS SQL and C#.NET. The case page records it as 100% HIPAA compliant, with a secure channel that keeps confidential patient information off the user side. It let Precision increase the number of claims worked by 80% without hiring new staff and cut the average age of claims by 35%. Not one line of that work needed a software safety class. It is Security Rule territory from end to end, and it has stayed there since 2006, now on its fourth major release.
EyeIC sits on the other side. Its MatchedFlicker product is a 510(k) FDA-cleared application that shows change between serial retinal images. We built the original Windows version, then moved it to the web in three months with HIPAA-compliant online access. Here the boundary decides the budget: the cleared functionality, the browser client and the reporting path are not one regulated blob, and treating them as one prices the project out of existence.
Compliance is an architecture decision, not a document phase
Opinion, stated plainly: compliance projects do not fail on the standard. They fail on the boundary drawn before anyone read one.
Every document in this article is knowable in an afternoon. What takes real work is deciding which systems hold regulated data, which software items can contribute to harm, and which of your tools are production tools rather than products. Those three decisions set your safety classes, your control set and your evidence burden. Get them wrong and you either gold-plate a dashboard or under-document a therapy path, and an auditor finds the second one.
So buy the boundary first. Name every component that holds ePHI, classify every software item against the harm it could cause, then write down which standard you are claiming and why. After that, make evidence a by-product of building. Test reports and defect records are ordinary QA deliverables that most teams already produce and then fail to keep in a form an auditor can read. Traceability is cheap while you are writing the code and ruinous afterwards.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder.
Not sure which standards bind your product? Start with the boundary
Tell us what your product does, who touches the data, and whether any part of it is a device or talks to one. We come back with the standards that bind you, the artifacts each of them asks for, and the places where your current architecture already satisfies them.