We have no customers and no funding yet. Is any of this binding today?

Not through the Security Rule, which reaches you when a covered entity's electronic protected health information does. 45 CFR 164.302 attaches Subpart C to what an organisation is and to the data it holds, and no registration step starts it. Part 11 arrives by a different route again, and 11.1(b) makes it conditional on an agency regulation already requiring the record, which a pre-revenue product usually has none of. What is decided today is what your systems record, and that decides what evidence exists for the period before anything binds.

Should we hire a QA engineer or bring in an outside team first?

Sort the work before you decide who does it. Anything that has to be running continuously, such as the event list your systems record and the regular reading of what they recorded, is operational and belongs with whoever runs those systems every day. Anything that produces a dated artefact against a named build can be bought as an engagement and stopped when the artefact exists. Which of the two is larger in your company depends on how many systems already hold data.

Can the audit log wait until we have real users?

45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use electronic protected health information, and Appendix A to Subpart C marks the standard Required. It carries no implementation specification, and it fixes no event list, no format and no retention period, so those settings are yours to choose and to justify. The period the log covers is not a setting. It begins when the mechanism begins, and every day before that stays unrecorded.

Does 21 CFR Part 11 apply to a digital health product?

Only where some other rule already requires the record. 11.1(b) reaches electronic records kept under a records requirement in agency regulations, and electronic records submitted to FDA under the Act. FDA's 2003 scope guidance then puts records "not required to be retained under predicate rules, but nonetheless maintained in electronic format" outside the part entirely. The phrase predicate rule is FDA's own term from guidance and appears nowhere in the regulation itself.

Our test environment holds no real patient data. Does the logging duty reach it?

45 CFR 164.312(b) is scoped to information systems that contain or use electronic protected health information, so an environment seeded with de-identified records sits outside it. That makes the boundary of the environment worth proving instead of asserting, because the same boundary decides which systems the risk analysis at 164.308(a)(1)(ii)(A) has to cover. Move the boundary and both answers move with it.

Situation

What QA does a digital health startup need first?

Build the parts that only exist if they were switched on beforehand. An audit trail under 21 CFR 11.10(e) records the date and time of an operator action while the action happens, and the information system activity review required at 45 CFR 164.308(a)(1)(ii)(D) has no records to read for any period when nothing was recording. Test automation can be added at any time.

Open the HIPAA safeguards checklist

What has happened: The product works, a first provider contract or a first patient record is close, and nobody has decided what QA has to exist by then. There is no QA function yet, and nothing has been asked of the company so far.
If nothing changes: Some records exist only because something was recording before the event they describe. An audit log switched on after the first customer arrives leaves the months before it empty, and no budget spent later fills them in.

What has to exist before the first real customer?

The parts of a QA function that produce nothing unless they were already running. A test suite written next quarter tests the code as it stands next quarter and loses nothing by having waited. A log switched on next quarter describes next quarter, and says nothing about the months when your first provider contract was live.

That distinction sets the order of work for a company with no QA function and a first customer in sight, and the size of the team does not change it. Almost everything a founder is offered under the heading of QA belongs to the first group and can be bought in any sequence. A short list belongs to the second, and every item on it is named in a regulation that fixes a moment and leaves the method open.

The company is early enough that nothing has been asked of it yet: no auditor holds a date, no diligence team has a data room, no customer has sent a questionnaire with a return-by line on it. Each item in the second group is a configuration decision this month and an unfillable hole in the file afterwards.

Which of these can you never go back and do?

Four, and each one is written as a fact about a moment.

What an audit trail contains. The control at 21 CFR 11.10(e) asks for "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records". It adds that "record changes shall not obscure previously recorded information", and it keeps the trail alive for at least as long as the records underneath it. Every one of those obligations is discharged while the work happens. Part 11 reaches a young company only where some other rule already obliges the record: 11.1(b) bites where an agency regulation already requires it, and FDA's 2003 scope guidance draws the same line from the other side, putting an electronic record that no predicate rule obliges you to retain outside the part altogether. Which rule that would be for your product, and what the agency enforces against what it does not, is on which records 21 CFR Part 11 actually reaches.

Records of information system activity. Two HIPAA provisions depend on the same thing having been switched on. section 164.312(b) reads in full: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." It has no implementation specification under it and Appendix A to Subpart C marks it Required. section 164.308(a)(1)(ii)(D), also Required, then asks you to "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports". The procedure is a document somebody writes in an afternoon. The records it reviews exist for exactly the period the mechanism was running.

That mechanism is scoped to systems that contain or use electronic protected health information, which puts the boundary of your test environments inside the same decision: an environment holding no identifiers is outside the standard, and proving where the line runs is what keeps it that way. What an outside firm may reach on either side of that line is set out question by question at how we work with protected health information.

Documentation of a security incident and what came of it. section 164.308(a)(6)(ii) is Required and asks for the response and reporting procedure to be documented together with security incidents and their outcomes. By the time anyone reads about an incident it is over, and whatever was captured while it was running is the whole of what can be documented about it.

What a test record says about the run. IEC 62304 clause 5.7.5 sets out what has to appear on the record of a software system test, and states why: the test has to be repeatable by somebody working from the record alone. Part of that list describes the design of the test and survives being written up later. The rest is true of the moment somebody started the run: which build was under test, what the hardware and software configuration was, which tools were in use, the day it happened, and who did it and wrote down the outcome. The clause carries the marker [Class A, B, C], so the lowest software safety class does not lift it. Which of your software items carries which class is settled by the classification rules on what IEC 62304 asks of a test record.

Each row below names a record whose content is fixed by the moment it describes, so a later engagement can restart the recording and cannot recover the interval that ran without it.

Four records under 21 CFR Part 11, the HIPAA Security Rule and IEC 62304 that cannot be recreated after the moment they describe.
The record	Where it sits	Why the date cannot be moved
The contents of an audit trail	21 CFR 11.10(e), where a predicate rule reaches the record	The trail stamps date and time as the entry is made, and holds nothing about the period before it ran
Records of information system activity	45 CFR 164.312(b), reviewed under 164.308(a)(1)(ii)(D)	The review reads what the mechanism produced, and a period with no mechanism produced nothing
A security incident and its outcome	45 CFR 164.308(a)(6)(ii), Required	The event has ended; what was captured while it ran is all the evidence there will be
Version, configuration, tools, date and executor on a test record	IEC 62304 subclause 5.7.5	Each item is true of the moment of the run and of no later moment

What can be added later at no cost?

Every artefact whose evidence is a fact about the present, and every technique no regulation names. The second category is larger than founders expect, and it contains most of what gets bought first.

Read 45 CFR 164.302 through 164.318 end to end and no testing technique appears in the text at all. It names no code review, no static or dynamic analysis, no test cases, no vulnerability scanning and no penetration testing, and it adopts no external security standard by reference, so nothing in the subpart can be quoted as the source of a tool your team is choosing between. 21 CFR 11.10(a) has the same shape from the other direction. It asks for "validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records", and those four objectives are the entirety of the requirement, with no test type, documentation set or lifecycle model attached to them. Your automation stack carries no date from either source. Choosing it is an engineering judgement about cost and regression speed, and deferring it costs a founder time and nothing in the file. Which safeguards a test can actually answer for, one provision at a time, is worked through on the HIPAA safeguards a test can be run against.

The written material behaves the same way. 164.316(a) requires policies and procedures to be maintained in writing, and 164.316(b)(1)(ii) asks for a written record of whatever the subpart obliges you to document, whether that is an action, an activity or an assessment. Neither provision fixes the day the writing happens. The periodic evaluation at 164.308(a)(8) carries no interval in the rule, no named method and no requirement that an outside party perform it, so when it happens is a decision you make and defend.

The order that falls out of this is short. Put the recording in place while the systems are still small enough to change it cheaply, and start producing run records against named builds as soon as there are builds worth naming. The automation arrives whenever the regression it would replace has grown large enough to pay for it.

What do you switch on before the first record arrives?

The work that has to happen in this order

Write down which rule reaches you and through which counterparty. Whether a US privacy duty attaches at all is settled by two definitions and by your own signed contracts, worked through at whether the HIPAA Security Rule reaches your product; whether a device regime attaches is a separate test on your published claims, at is my health app a medical device.
Switch the recording on in every system the data will land in, before it lands. 164.312(b) fixes no event list, no log format and no retention period, so write down what you chose to record and why, because that note is the only thing that answers the question later.
Set the retention of the trail against the retention of the records it covers. Where Part 11 reaches you, 11.10(e) measures it that way and not by what your storage tier costs.
Start the run records now, while there is little to record. Fix the acceptance criteria before each execution, and put the build identifier, the environment it ran against, the tooling, the day and the person beside the outcome.
Read the logs once, before anything has gone wrong. The first review under 164.308(a)(1)(ii)(D) should not be the one that follows an incident, because that is the review that discovers the events you needed were never recorded.
Leave the automation until the record exists. Nothing in either rulebook scopes it, so it can be scoped by your own regression time whenever that becomes the constraint.

Step 2 is the one that gets deferred, because it is the only step with no visible output on the day it is done. Its output appears the first time somebody asks what happened in a week that has already passed.

How much of this is it, and whose calendar is it on?

The size is set by where the data lands, and headcount does not enter into it. A system that never holds electronic protected health information is outside Subpart C, so the cheapest way to keep a first engagement small is to prove where that boundary runs before anyone starts testing across it.

Two of the constraints are set outside the company, and both are worth knowing before you commit to a route. The first is the retention of the trail: 11.10(e) measures it against however long the underlying records themselves have to be kept, so the setting follows from a rule about those records and not from a storage budget.

The second arrives if you intend to sell a certified Health IT Module to providers. Under 45 CFR 170.405(b)(1) a developer submits an annual real world testing plan to its ONC-ACB by a date that lets the body publish a public hyperlink to it on CHPL no later than 15 December each year, and the plan has to cover every module certified to the criteria in 170.405(a) as of 31 August of the year it is submitted in. 170.405(b)(2)(i) then adds a duty that surprises engineering teams: where a developer finds a non-conformity with the full scope of any certification criterion during that testing, it has 30 days to tell its certification body. ONC has been exercising enforcement discretion over parts of this since 30 June 2025, in effect until 31 December 2026 or until the Department completes deregulatory action, whichever comes first, so read the current position before planning around either date.

Who does this while there is no QA function?

Somebody who can produce a dated artefact against a named build, which is a different job from running your systems day to day. Sorting the work by that distinction decides what to buy: the recording and the regular reading of it stay with whoever operates the systems every day, while the evidence work can be brought in, finished and stopped.

What an outside team adds here is the run itself and what the run leaves behind: executions against a named version with the acceptance criteria fixed beforehand, a check that the mechanism at 164.312(b) actually records the events you chose and that the record can be read back afterwards, and a written procedure for the review that 164.308(a)(1)(ii)(D) requires. 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. A supplier cannot be the reason a record exists for a period before it was engaged.

We sign a Business Associate Agreement before any engagement that touches PHI. The signature precedes the access, and the access is what opens the period a later reader asks about. We do not need production PHI to test. Environments run on synthetic and de-identified data. The systems holding your data stay yours, and where the engineers sit is part of the engagement terms, settled alongside that agreement and not after it.

The first thing to settle with any supplier is who holds the record and on what terms an outside party may write into it, because that is what separates one firm from another once the technical answers all look alike. The questions that surface it are set out under how to choose a healthcare QA vendor. Where the answer is that the whole function is bought rather than built, what that engagement covers and how it hands work back is on healthcare QA outsourcing.

The section and clause numbers here were checked on 3 September 2026 against the records this site holds behind its standard pages: 45 CFR Part 164 as the eCFR carried title 45 on 31 August 2026, 21 CFR Part 11 together with FDA's scope and application guidance of August 2003, IEC 62304 Edition 1.1 of 2015-06, and 45 CFR Part 170 with the enforcement notice ONC published on its own site.

What do buyers ask about this?

We have no customers and no funding yet. Is any of this binding today?: Not through the Security Rule, which reaches you when a covered entity's electronic protected health information does. 45 CFR 164.302 attaches Subpart C to what an organisation is and to the data it holds, and no registration step starts it. Part 11 arrives by a different route again, and 11.1(b) makes it conditional on an agency regulation already requiring the record, which a pre-revenue product usually has none of. What is decided today is what your systems record, and that decides what evidence exists for the period before anything binds.
Should we hire a QA engineer or bring in an outside team first?: Sort the work before you decide who does it. Anything that has to be running continuously, such as the event list your systems record and the regular reading of what they recorded, is operational and belongs with whoever runs those systems every day. Anything that produces a dated artefact against a named build can be bought as an engagement and stopped when the artefact exists. Which of the two is larger in your company depends on how many systems already hold data.
Can the audit log wait until we have real users?: 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use electronic protected health information, and Appendix A to Subpart C marks the standard Required. It carries no implementation specification, and it fixes no event list, no format and no retention period, so those settings are yours to choose and to justify. The period the log covers is not a setting. It begins when the mechanism begins, and every day before that stays unrecorded.
Does 21 CFR Part 11 apply to a digital health product?: Only where some other rule already requires the record. 11.1(b) reaches electronic records kept under a records requirement in agency regulations, and electronic records submitted to FDA under the Act. FDA's 2003 scope guidance then puts records "not required to be retained under predicate rules, but nonetheless maintained in electronic format" outside the part entirely. The phrase predicate rule is FDA's own term from guidance and appears nowhere in the regulation itself.
Our test environment holds no real patient data. Does the logging duty reach it?: 45 CFR 164.312(b) is scoped to information systems that contain or use electronic protected health information, so an environment seeded with de-identified records sits outside it. That makes the boundary of the environment worth proving instead of asserting, because the same boundary decides which systems the risk analysis at 164.308(a)(1)(ii)(A) has to cover. Move the boundary and both answers move with it.

Which standards does this touch?

Which product types does this apply to?

Which of our services test it?

What does validating your product actually involve?

Answer four questions about your markets, your product type and its integrations. You get the standards that reach you, the artefacts each one asks you to produce, and which of them a test supplier delivers.

See what applies to you hello@qaremed.com