Engineers often make these decisions months in advance, without realizing they are setting regulatory policy. Fixing them later is costly, but making the right choices from the start is almost free.
Your Customer's Responsibilities Become Yours
If your software creates, receives, maintains, or transmits protected health information on behalf of a covered entity, you're a business associate. That status follows from what you do with the data. Signing a business associate agreement documents the relationship rather than creating it, so a vendor that starts handling PHI before the contract is in place is already in scope.
The exposure also runs in more than one direction. HHS publishes a list of provisions establishing direct liability for business associates, including failure to comply with the Security Rule, failure to notify a covered entity of a breach, and impermissible uses and disclosures of PHI. Your customer can pursue you under the agreement. The Office for Civil Rights can pursue you on its own.
Teams used to general SaaS often stumble first on classification. An email address in a CRM is just personal data, but if that same address appears in a system that includes appointment reasons, intake answers, or provider notes, it is treated differently. This affects how you store data, who can access it, how long you keep it, and which third-party tools you can use. Another common mistake is thinking a signed agreement with a cloud provider solves everything, but major platforms only provide the right infrastructure; you still have to set it up properly. These are some of the main HIPAA misunderstandings that catch out founders new to healthcare, and they are much easier to fix during design than after launch.
Map the PHI Boundary Before Choosing Your Stack
Knowing that your company handles PHI is only the beginning. The more useful exercise is identifying all the places where information can travel once it enters the product. A patient record may originate in the primary application database but also appear in application logs, error-monitoring tools, analytics platforms, customer support systems, backups, data warehouses, and automated notifications. Each additional destination expands the system that has to be evaluated and controlled.
That makes architecture decisions compliance decisions. Before adding a vendor to the stack, determine whether PHI can reach it, whether that access is actually necessary, and whether the vendor can support the contractual and security requirements that come with it. A tool that is perfectly reasonable for an ordinary SaaS product may create unnecessary complexity when used inside a healthcare environment.
The same exercise can reduce the compliance burden. If a support platform does not need patient information, design the integration so it never receives it. If analytics can function with de-identified or aggregated information, avoid sending identifiable records. The smaller the PHI footprint, the fewer systems that need to be considered when responding to a security questionnaire, investigating an incident, or terminating a customer relationship.
Work Out Early Whether The Product Is Itself A Regulated Device
The second question catches teams that see themselves as building workflow tools. FDA regulates software functions that meet the device definition in section 201(h) of the Food, Drug, and Cosmetic Act, and it applies that standard to the function rather than the platform. The same logic, whether running on a phone, in a browser, or inside an instrument, is evaluated the same way. Section 3060 of the 21st Century Cures Act removed certain functions from the device definition, and the agency also exercises enforcement discretion over lower-risk functions that help patients manage a condition without suggesting specific treatment, or that automate simple tasks for providers.
The key factor is intended use, which is strongly influenced by your public messaging. For example, a dashboard that just shows lab results is one thing. If you add marketing language saying it identifies patients at risk of sepsis, it becomes a different regulatory case. Product marketing and regulatory planning need to work together, since even a launch page can change your product’s status without any code changes.
On The 510(K) Path, One Early Choice Sets Your Engineering Scope
If your client is launching a device or qualifying software, the most important early decision is which legally marketed device to use as the predicate. This choice sets the intended-use language and the technical features your submission must meet, and it shapes your verification and validation plan. Even small differences between your product and the predicate, such as specimen type, output format, cutoff values, or patient population, can lead to additional study requirements later. Picking the wrong predicate early on can cause unexpected clinical work much later in the process.
This is important for software vendors, even if the client handles the submission. The FDA stops the 510(k) review clock when it requests additional information, so every avoidable question can delay your delivery schedule. If your timeline depends on receiving clearance by a certain quarter, you need to understand the predicate decision rather than treating it as just a client detail.
There have also been recent changes to quality system requirements. Since February 2, 2026, 21 CFR Part 820 has been the Quality System Regulation and now includes ISO 13485:2016. If your code is part of a regulated device, your design controls, change records, and supplier documentation must fit into that system, and your development process needs to create evidence a quality engineer can use.
Compliance Artifacts Are Engineering Deliverables
Healthcare buyers will eventually ask for features built into your system, not just documents you create at the end.
Audit logging is a good example. You need to be able to show who accessed a record, when, and why, in a way a reviewer can understand, for as long as your retention policy says. Adding this after launch often means updating a database that never had those fields. The same goes for role-based access. If you started with just one admin role, splitting it into clinical, billing, and support roles later will affect every part of your system.
You should decide on retention and deletion policies before your first pilot. Deleting a customer’s data at the end of a contract is more complex when that data is PHI stored in backups, logs, analytics warehouses, and vendor queues. Teams working in regulated environments know that oversight, traceability, and documentation must be built in from the start, not added later. This approach applies to any healthcare product, with or without a model.
Design for the Questions Buyers Will Eventually Ask
Healthcare procurement teams tend to ask questions that expose architectural shortcuts. They may want to know whether privileged access is logged, how quickly access can be revoked when an employee leaves, whether production data appears in development environments, or how a customer’s information is removed when the contract ends.
Those questions are easier to answer when the product was designed with them in mind. For example, role-based access should follow the principle of least privilege rather than granting every internal user broad administrative access. Employee access to production systems should be attributable to an individual account rather than a shared credential. Changes to sensitive records should leave enough history to determine what happened if a customer raises a question months later.
Testing environments deserve the same attention. Copying a production database into staging may be convenient for debugging, but it can also duplicate sensitive information into an environment with different access controls and retention practices. Using synthetic or appropriately de-identified data for development reduces that exposure while making the boundary around production PHI easier to explain.
These are not features that customers necessarily notice during a product demonstration. They become visible during diligence, which is precisely when rebuilding them is most disruptive.
Procurement Is The Real Gate
Even if your product is not a device, you will still undergo a vendor security review, which includes a list of required documents. Be prepared to provide:
- A completed security questionnaire, often HECVAT or the health system's own variant
- A SOC 2 Type II report, or HITRUST certification for larger health systems
- Recent penetration test results along with your remediation status
- A current subprocessor list showing each vendor's role and level of data access
- An incident response plan with defined breach notification timelines
You can’t pull these documents together quickly at the last minute, and the questionnaire often reveals problems at the worst time. Vendors who collect evidence as they build the product can close deals in weeks. Those who wait for the questionnaire may wait months or never receive it at all.
Requirements are changing too. In January 2025, HHS proposed major updates to the HIPAA Security Rule that would remove the "addressable" designation and make measures such as encryption and multi-factor authentication mandatory. These changes are not final yet, and enforcement is expected in 2027. Still, most buyers already ask for these features in their contracts, so it’s smart to have multi-factor authentication, an up-to-date asset inventory, and a current risk analysis ready.
Treat Security Evidence as Part of the Sales Pipeline
The procurement package should develop alongside the product rather than after a salesperson lands the first large health system. A SOC 2 audit, penetration test, risk analysis, incident response process, and documented vendor inventory all require work that cannot be compressed into the final week of a deal.
The engineering team also produces much of the evidence those processes depend on. A policy stating that access is reviewed periodically is only useful if the company can demonstrate that reviews actually occur. An incident response plan needs defined technical owners and escalation paths. A subprocessor list has to reflect the services actually present in the architecture rather than the vendors someone remembers using.
Keeping this evidence current changes procurement from a scramble into a repeatable process. The first health system may ask a hundred questions that take weeks to answer. If those answers are documented and the underlying controls remain in place, the next customer’s questionnaire becomes substantially easier.
That makes compliance work part of revenue infrastructure. A feature can be technically ready for customers while the company selling it is still months away from being ready for procurement.
A Workable Sequence
The order of these decisions matters because each one narrows the choices available later. Start by defining the product’s intended use before writing launch copy or making clinical claims, since those decisions help determine whether FDA oversight may apply. Map the PHI boundary next so the team knows exactly which systems, vendors, and workflows fall within the regulated environment.
From there, choose infrastructure and subprocessors that can support those requirements rather than trying to negotiate compliance around tools already embedded in the product. Build role-based access, audit logging, retention controls, and deletion workflows before the first pilot, when changing the underlying data model is still relatively inexpensive. If the software supports a regulated medical device, make sure development records and change controls also produce the evidence the client’s quality system will require.
At the same time, begin building the procurement file. Maintain the subprocessor list, document security practices, conduct risk assessments, plan penetration testing, and assign ownership for the questionnaires and evidence customers will request.
The goal is not to turn every software company serving healthcare into a regulatory organization. It is to recognize that selling into healthcare changes what “finished” means. A product is not commercially ready simply because the software works. The company also needs to be able to explain where sensitive data goes, demonstrate how it is protected, support the regulatory obligations attached to the product, and provide buyers with evidence that those controls exist.
Most of those decisions are inexpensive when made during product design. They become expensive when discovered during a security review with a contract waiting on the other side. Building for regulated healthcare customers from the beginning therefore does more than reduce compliance risk. It removes obstacles between a finished product and a customer who is actually allowed to buy it.
