Start with an inventory of everything your product is built from, tie it to the HIPAA safeguards you already owe, add a handful of secure development practices, and prepare the two documents regulators and hospital buyers ask for: a software bill of materials and a breach notification path. Do it in three 30 day steps.
Why is healthtech different?
Two sets of rules meet in healthtech software. If you handle electronic protected health information, the HIPAA Security Rule applies to covered entities and business associates. If your product is, or ships with, a medical device that has software and can connect to the internet, section 524B of the Federal Food, Drug, and Cosmetic Act adds device requirements. Many healthtech products are the first kind only. Work out which you are before you plan.
Days 1 to 30: what do you build first?
An inventory. List your code repositories, the open source packages in each, container images, build tools and the cloud services that touch patient data. An SBOM, in the NTIA's words, is a nested inventory of the ingredients in software. Generate one per release, in a standard format.
A risk analysis. The Security Rule's administrative safeguards require a covered entity or business associate to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information, and to implement security measures that reduce those risks to a reasonable and appropriate level. A component inventory feeds this directly: you cannot assess the risk of software you have not listed.
A security owner. The same section requires you to identify the security official responsible for the policies and procedures.
Days 31 to 60: what practices do you add?
NIST's Secure Software Development Framework, SP 800-218, is a core set of high-level practices that can be added to any development process to reduce the number of vulnerabilities in released software and to address root causes. It also gives buyers and suppliers a common vocabulary. Pick a small first set:
- Scan dependencies on every pull request and block critical, reachable issues.
- Review third-party components before they are added, and pin versions.
- Keep secrets out of repositories and scan for them.
- Sign or checksum release artifacts and record which commit built them.
- Keep a way for researchers and customers to report vulnerabilities.
Technical safeguards in the rule are also specific enough to test: unique user identification, access control, audit controls, integrity protection and authentication. Check that your product and your build systems meet them.
Days 61 to 90: what do you prepare for outsiders?
For hospital buyers: a one page security overview, the current SBOM, a vulnerability management summary and your incident contact.
For breaches: the business associate rule requires you to notify the covered entity after discovering a breach of unsecured protected health information without unreasonable delay and in no case later than 60 calendar days after discovery. A breach is treated as discovered on the first day it is known, or would have been known with reasonable diligence. The notice should identify each affected individual to the extent possible. Your customer contracts may set shorter limits, so write the faster number into your runbook.
For devices: section 524B requires a sponsor of a cyber device submission to provide a plan to monitor, identify and address postmarket vulnerabilities, including coordinated vulnerability disclosure, to make updates and patches available on a justified regular cycle and out of cycle for critical issues, and to provide an SBOM covering commercial, open source and off-the-shelf components. If this is your product, treat the SBOM and the postmarket plan as release gates.
A constructed example
A telehealth startup with six engineers runs the plan. In month one, it finds 14 services and 400 packages and discovers two unmaintained libraries in the video path. In month two, it adds pull request scanning and replaces one library. In month three, it assembles a buyer packet and runs a tabletop breach exercise, which shows its on-call contact list is out of date. It fixes the list. The next hospital questionnaire takes an afternoon.
What to do
- Decide whether HIPAA, device rules, or both apply to each product.
- Generate an SBOM per release and store it.
- Run and document a risk analysis that names software components.
- Name a security official and record the assignment.
- Adopt five SSDF aligned practices and automate them in CI.
- Write a breach runbook with your own deadline inside the 60 day limit.
- Build a buyer packet and keep it current.
- Review the programme quarterly.
Safeguard dependency scanning, SBOM generation and compliance automation can support steps 2, 5 and 7. They do not make a company HIPAA compliant or FDA ready. See the dependency inventory demo.
Quick check
Does every healthtech product need an SBOM by law?
Not by the same law. Section 524B requires an SBOM for cyber devices in certain submissions. Many buyers ask for one anyway, so it is good practice.
How fast must a business associate report a breach?
Without unreasonable delay and no later than 60 calendar days after discovery, under the rule. Contracts may require less.
Sources
- 45 CFR 164.308 Administrative safeguards
- 45 CFR 164.312 Technical safeguards
- 45 CFR 164.410 Notification by a business associate
- 21 U.S. Code 360n-2: Ensuring cybersecurity of devices
- NIST SP 800-218: Secure Software Development Framework
- NTIA: Software Bill of Materials
Last reviewed: 18 October 2026.
