Do I need HIPAA compliance testing for my app?

Does HIPAA reach your product at all?

Two definitions decide it, and neither one asks what kind of company you are. Under 45 CFR 160.103 a covered entity is one of three things: a health plan; a health care clearinghouse; or a health care provider transmitting any health information in electronic form in connection with a transaction that subchapter C covers. A business associate, in the same section, is anyone outside the workforce of a covered entity or an organized health care arrangement who handles that entity's protected health information on its behalf, for a function or activity the subchapter regulates. section 164.104 applies Part 164 to those three kinds of covered entity, and its paragraph (b) extends the standards to a business associate where the text so provides.

Most founders read the first definition, establish that they run neither an insurer nor a clinic, and stop. The second definition is where a software company usually sits, and it is written around functions. The examples inside it are claims processing or administration, data analysis, processing or administration, utilization review, quality assurance, patient safety activities listed at 42 CFR 3.20, billing, benefit management, practice management and repricing, together with legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation and financial services where providing the service involves disclosure of PHI. Paragraph (3) of the same definition then names three further inclusions: a Health Information Organization, E-prescribing Gateway or other person providing data transmission services with respect to PHI that requires access on a routine basis; a person who offers a personal health record to individuals on behalf of a covered entity; and a subcontractor that creates, receives, maintains or transmits PHI on behalf of a business associate.

The load-bearing words are "on behalf of". They mean your customer's status decides yours. The same code, in the same repository, sits outside the rule while it serves consumers and inside it the week a provider network starts sending records through it. Nothing about the product changes on that day, which is why the question usually arrives late.

Protected health information is individually identifiable health information transmitted by electronic media, maintained in electronic media, or transmitted or maintained in any other form or medium. 160.103 excludes four things from it: education records covered by FERPA, records described at 20 U.S.C. 1232g(a)(4)(B)(iv), employment records held by a covered entity in its role as employer, and information about a person who has been deceased for more than 50 years. Individually identifiable health information is defined a few lines above as a subset of health information, including demographic information collected from an individual, that is created or received by a health care provider, health plan, employer or health care clearinghouse; that relates to past, present or future physical or mental health, to the provision of health care, or to payment for health care; and that either identifies the individual or carries a reasonable basis to believe it can be used to identify them.

Electronic protected health information narrows the field once more. 160.103 defines it as information within paragraphs (1)(i) or (1)(ii) of the PHI definition, meaning PHI transmitted by or maintained in electronic media. The Security Rule at 45 CFR Part 164 Subpart C governs that subset alone. Paper records in a filing cabinet answer to the Privacy Rule instead, and a founder worried about a fax workflow is asking a different question from the one this page answers.

The three HIPAA definitions in 45 CFR 160.103 that decide whether the rule reaches a company, and where in the company to look for each.

The definition	Where it sits	What to look at in your own company
Covered entity	45 CFR 160.103, applied by 164.104	Whether you bill as a provider, operate a plan, or run clearinghouse functions on claims data
Business associate	45 CFR 160.103, paragraph (1)	Your signed customer contracts: which counterparties are providers, plans or clearinghouses, and what data they send you
Subcontractor as business associate	45 CFR 160.103, paragraph (3)(iii)	Your own supplier list: hosting, analytics, support tooling, contract engineering, testing

That third row reads back at any firm you bring in. A testing supplier that receives ePHI from you is itself a business associate under 45 CFR 160.103, paragraph (3)(iii) where you are a business associate yourself, so the terms it works under belong in the conversation before an environment exists. Ours are written out at how we work with protected health information.

The other definitions question lands on a founder's desk in the same month and turns on function in the same way: whether the product is regulated as a device. That one is answered separately under is my app a medical device, and the two answers are independent. A wellness app can be a business associate and no device at all.

When did the answer become yes?

It became yes on the day a covered entity's ePHI first reached you, which is usually before anybody drafted a document about it. section 164.302 is written as a status: a covered entity or business associate has to comply with Subpart C in respect of a covered entity's electronic protected health information. No enrolment, registration or notification step starts that clock, and no regulator tells you it has started.

The paperwork is meant to run ahead of the data. 164.502(e)(1)(i) permits a covered entity to disclose PHI to a business associate only where it first obtains satisfactory assurance that the information will be appropriately safeguarded, and 164.502(e)(2) requires the assurance to be written down in a contract or other agreement meeting 164.504(e). The Security Rule repeats the structure for ePHI at 164.308(b)(1), and makes the written contract a required implementation specification at 164.308(b)(3). A pilot that opens with a data export and a promise to paper it next month has inverted that order, and the obligations dated from the export.

Founders miss the second half of the same arrangement, which points back at their own supplier list. Paragraph (3)(iii) of the 160.103 definition makes a subcontractor a business associate in its own right. 164.308(b)(2) lets you pass ePHI to one only on assurances obtained in accordance with 164.314(a), 164.314(a)(2)(iii) carries the contract requirements down that link, and 164.504(e)(2)(ii)(D) sends the restrictions with them. Your hosting account, your error tracker, your contract engineers and whoever tests the product are each a separate signature, and the list of who currently holds one is the thing a customer's counsel asks for first.

What happens if the answer was yes and nobody acted?

Nothing happens until an incident, and then several things happen at once on somebody else's schedule. The sequence is written into the rule, it starts on discovery, and it does not wait for your release cycle.

Start from section 164.402, which treats any use or disclosure of PHI that Subpart E does not permit as a breach until you show otherwise. The showing has a defined shape: a risk assessment weighing at least four named factors, ending in a demonstration that the probability the information was compromised is low. The four are what data was involved and how readily it identifies someone, who used it or received it, whether anyone in fact looked at it, and how far the exposure has since been contained. Under 164.414(b) it falls to you to show either that every notification the rules required was sent, or that no breach occurred.

Each of those four is answered from records that already existed on the day, or it is not answered. Whether anyone looked is a question your audit controls answer or fail to. Which identifiers were exposed is a question your ePHI inventory answers. A company learning on that day that its logs never recorded reads of a patient record has conceded the third factor by default.

The clocks run in calendar days. As a business associate you get 60 calendar days from discovery to tell the covered entity under 164.410(b), and unreasonable delay inside that window is itself a failure. The covered entity is on the same outer limit for notifying individuals under 164.404(b). 164.406 adds notice to prominent media outlets where a breach involves more than 500 residents of a State or jurisdiction, on the same limit at 164.406(b). 164.408(b) sends notice to the Secretary at the same time as individual notice where 500 or more people are involved, and 164.408(c) puts everything below that threshold into a log submitted within 60 days of the end of the calendar year. Subpart D has applied to breaches occurring on or after 23 September 2009.

One definition can switch that sequence off before it starts. 164.402 confines the whole notification machinery to unsecured PHI, meaning PHI that has not been made unusable, unreadable or indecipherable to unauthorized persons by a technology or methodology the Secretary specifies in guidance under section 13402(h)(2) of Public Law 111-5. The Security Rule compels neither encryption specification outright: 164.312(a)(2)(iv) covers stored ePHI, 164.312(e)(2)(ii) covers ePHI in transmission, and both are addressable, which is a documented decision and never a free choice. Those two decisions reach past the safeguard they sit under, because they also decide whether the information counts as unsecured on the day something goes wrong.

What has to happen first?

Six things, in this order. The first two are desk work on your own contracts and supplier list, and they decide how large the remaining four are.

Step 5 is the part an outside team can run for you, and the list to work through first is the HIPAA safeguards checklist. Which check belongs against which provision, and why no technique is named in the regulation at all, is worked through on HIPAA testing requirements for software. The practical effect for a founder is that nobody can hand you a mandated method: you choose one, you run it, and the file records which one you chose.

Step 6 is the part nobody can run for you alone, because it needs a finding about the system and a judgement about your circumstances in the same document. An outside team can produce the finding and draft the row. What counts as reasonable and appropriate in your company is your company's call to make and to record.

How much of this does a company of six people have to do?

The rule asks for less than the enterprise questionnaire in front of you implies, and it supplies the argument itself. Under 164.306(b) an entity may adopt whichever security measures reasonably and appropriately implement the standards, weighing four things the paragraph names: its own size, complexity and capabilities; the technical infrastructure it runs on, with whatever hardware and software security features come with that; what a measure costs; and how likely a risk to ePHI is together with how bad it would be. Cost sits in the regulation as a legitimate input. Two companies on identical architectures can land on different measures and both hold, provided each one recorded why.

The scope is bounded by the inventory rather than by the size of the estate. A system that never touches ePHI is outside Subpart C, and the fastest way to shrink a first engagement is to prove where that boundary runs. Where a test environment is the thing in question, seeding it from records that carry no identifiers keeps it outside the boundary altogether.

Nothing in the rule sets an interval. The evaluation at 164.308(a)(8) is periodic, technical and nontechnical, and it is triggered first by the standards you implemented and afterwards by operational or environmental change. 164.306(e) puts the same trigger on the measures themselves, which are reviewed and modified as needed to keep the protection reasonable and appropriate. 164.316(b)(2)(iii) puts it on the paperwork. The calendar is therefore yours to choose and yours to defend, and shipping a new integration or standing up a new data store is exactly the kind of event all three sections have in mind.

One deadline does bind, and it runs long. 164.316(b)(2)(i) keeps the documentation Subpart C asks for on file for six years, counted from the day it was created or the day it stopped being in effect, whichever falls later. The risk analysis written this month is a document somebody may ask for in 2032, so the copy that gets filed carries its scope, its date and the system versions it covered. What a first engagement costs, and which of these six steps drives the number, is worked through under what HIPAA testing costs.

What do you tell a customer who asks whether you are HIPAA compliant?

Send them evidence, because the certificate they are picturing does not exist. HHS OCR answers the certification question directly in a FAQ, quoted in full on the HIPAA Security Rule standard page: nothing in the rule obliges a covered entity to certify its compliance, the Department endorses no private organisation's certificate, and a certificate written by an outside firm does not stop HHS from finding a violation later. Its guidance on misleading marketing claims puts the same thing from the buyer's side: no person and no product is certified by HHS or OCR as HIPAA compliant.

The same FAQ says what an outside organisation can be engaged for: the periodic evaluation at 164.308(a)(8) may be performed internally by the entity or by an external organisation, and that choice is a business decision. What travels back to your customer is the material underneath it. Five items answer most of a security questionnaire without a single unprovable sentence:

• The date, scope and system versions of your risk analysis under 164.308(a)(1)(ii)(A), and the register of what it found.
• The safeguard results: which of the 164.312 standards were exercised, on which build, and what each check returned.
• The addressable decision record required by 164.306(d)(3), including the rows where the answer was no and the alternative measure that replaced it.
• The signed agreement and the breach reporting path it obliges you to, under 164.314(a)(2)(i)(C) and 164.410(b).
• Where each of those documents is held and the date its six-year retention under 164.316(b)(2)(i) ends.

No supplier can add a sixth line saying you are compliant. We test against the requirements in these standards and prepare the artefacts an auditor asks for. Compliance itself is held by the organisation that ships the product.

What does a testing engagement add here?

It adds evidence with a date on it, for the steps that need a system to be exercised. The technical safeguards at 164.312 are the part of the rule written about the behaviour of software, and a run against a named build answers there what a design document cannot.

We sign a Business Associate Agreement before any engagement that touches PHI. We do not need production PHI to test. Environments run on synthetic and de-identified data. Where a test genuinely needs a real-world shape, the route to it is agreed in writing before an environment exists, and de-identification is verified rather than assumed. Project data stays in your systems, and the working location of the team is agreed as part of the engagement terms before the contract.

Two engagements answer different halves of the question. The evidence pack behind the periodic evaluation, and the register of addressable decisions, are HIPAA compliance testing. Work that goes looking for the failure itself, against the access routes and the paths that carry ePHI out of the primary store, is PHI security testing.

The definitions in this page come from 45 CFR 160.103 and the section numbers from 45 CFR Part 164, both checked against the eCFR text of title 45 as it stood on 31 August 2026. The two statements attributed to HHS OCR were taken from archived copies of its own pages, since hhs.gov declines automated requests: the FAQ on certifying Security Rule compliance and the guidance on misleading marketing claims.