How do you prepare for a healthcare software audit?

What is an auditor actually reading?

Your records. An auditor's day is spent in documents, and the running product is opened only where a document says something about it that the auditor wants to check. This is the part that surprises a chief executive three weeks before the date, because the company has spent two years making the software good and none of that effort was aimed at the question being asked.

The question is narrower than the one your engineering team has been answering. Whether you can show how you knew the software worked on the day you shipped it, in a form somebody outside the company can follow, is a separate property of the business from whether the software is good. A company can hold one and hold none of the other, and most companies of a certain age do.

IEC 62304 states the shape of that gap more precisely than any other document a software company is likely to already hold. Subclause 5.7.5, as rewritten by Amendment 1, lists seven items a software system test record has to document, for the stated purpose of supporting the repeatability of the test, and it is marked [Class A, B, C] in Edition 1.1, so it binds even at the lowest software safety class. Which class your items carry, and what that changes elsewhere in the file, is set out on IEC 62304 software testing requirements.

The seven items split cleanly into two kinds, and the split is the whole of what follows on this page.

Of the seven items an IEC 62304 test record must document, five are true of one moment and cannot be supplied later.

The record has to document	Kind of fact	Can it be supplied later?
The test case procedures, with required actions and expected results	A property of the test design	Yes, if the design was decided before the run
Pass or fail, with the list of anomalies	An observation	Only if the run is repeated
The software version under test	True of one moment	No
The hardware and software test configuration	True of one moment	No
The test tools in use	True of one moment	No
The date of the test	True of one moment	No
Who executed the test and recorded the result	True of one moment	No

Five of the seven are facts about a moment. A test runner captures none of them unless somebody decided in advance to capture them, and no budget applied afterwards recovers a moment that has passed. So the preparation work is a sorting exercise before it is anything else: find the records missing facts of the first kind, find the records missing facts of the second, spend the weeks you have on the first, and write a plain account of the second.

Which audit is this, and what does its date bind you to?

Read the letter and find out who is coming, because the four common visitors read different documents first and are bound by different clocks.

An auditor working the MDSAP programme arrives with a task list. FDA's MDSAP Audit Approach, at Task 15, names the applicable clauses for validation of software used in production and service provision as ISO 13485:2016 subclauses 4.1.6, 7.5.6 and 7.6, and instructs the auditor that where the selected process is software controlled, or where software is used in production equipment or in the quality management system, the auditor is to confirm that it was validated for the use it was put to. The same audit approach maps internal audit to clause 6.2 and clause 8.2.4, so your own internal audit records are themselves an audit subject. What each of those three validation clauses covers, and why quoting one of them usually underprices the work, is on ISO 13485 software validation requirements.

A HITRUST external assessor arrives with a test plan they did not write from scratch. Handbook criterion 8.1.1 requires external assessors to use HITRUST's illustrative procedures as the basis for their more detailed assessment test plans, and those procedures are published only inside HITRUST's own MyCSF platform. Criterion 8.1.2 states that all evaluative elements in each requirement statement must be addressed, and a requirement statement contains one or more enumerated elements, so the unit of evidence is the element and not the statement. The assessor's fieldwork window is capped at 90 days for the e1, the i1 and the r2 alike. Which of those three you were asked for changes everything downstream, and the difference is set out on HITRUST testing requirements.

An OCR investigation has no timetable published in advance, which is the point worth planning around. The Security Rule's evaluation standard at section 164.308(a)(8) requires a periodic technical and nontechnical evaluation establishing the extent to which security policies and procedures meet the requirements of the subpart. The rule sets no interval, names no method, and does not require the evaluation to be external. A company that has never performed one has an open item that predates the letter.

A customer's security team arrives with a contract and a questionnaire, and what binds you is whatever that contract says. The documents behind it are usually the same ones the other three want.

What an ISO 13485 auditor, a HITRUST assessor, an OCR HIPAA investigator and a customer security team read first, and which clock is already running.

Who is coming	What they read first	The clock already running
MDSAP or notified body auditor	The task list, then your records against ISO 13485 subclauses 4.1.6, 7.5.6, 7.6 and your internal audit records under 8.2.4	Set by the certificate cycle and the audit notice
HITRUST external assessor	The illustrative procedures in MyCSF, then evidence per evaluative element	Fieldwork capped at 90 days for e1, i1 and r2
OCR investigator	Documentation under 45 CFR 164.316, held for six years after creation or after the day it last applied	No published interval; the six-year retention is the window
A customer's security team	The contract, then whatever the questionnaire names	Set by the contract

What happens if the file is assembled in the last week?

The findings stop being about your product and start being about your paperwork, and those are the expensive kind, because a paperwork finding says something about how the company operates rather than about one defect.

Three consequences have numbers on them. Under HIPAA, the documentation duty at section 164.316(b) reaches every action and assessment the Security Rule obliges you to document, and section 164.316(b)(2)(i) sets the retention at six years, counted from creation or from the day the document last applied, whichever falls later. An absence opened this year is therefore an absence a reader can still find in 2032. The full documentation set the rule names, and which of it a test can evidence, is on what the HIPAA Security Rule requires of your software.

Under HITRUST, a missed deadline removes the certificate outright. Handbook criterion 15.4.10 attaches suspension or revocation of the assessed entity's certification to non-submission of the r2 interim assessment by its deadline, and criterion 15.7.4 states that HITRUST does not extend an expiration date under any circumstances. Late fieldwork therefore opens what HITRUST names a certification gap, and the entity is not considered certified while it lasts.

Under IEC 62304, the evaluation the auditor performs has nothing to read. Subclause 5.7.4 requires the manufacturer to evaluate the appropriateness of verification strategies and test procedures, then verify that all software requirements were tested or verified some other way, that the trace joining requirements to tests exists on paper, and that test results meet the required pass and fail criteria, at [Class A, B, C]. Where the trace was never written down, that subclause has nothing to verify and the auditor records the absence.

Which parts of the gap can you still close?

Anything whose evidence is a present-tense fact. If the document can be written today and dated today without saying anything untrue, it is inside the window, and the list is longer than most teams expect.

Missing test runs are the clearest case. A test that was never executed can be executed this week, and the record it produces carries this week's date and every one of the seven items subclause 5.7.5 asks for, because you are there while it happens. That record is worth more than a reconstructed one about a run from two years ago, and it costs less to defend.

The requirements trace is the second case, provided the tests themselves exist. Subclause 5.7.4 asks for traceability between software requirements and tests to be recorded. It fixes no day on which the recording had to happen. Building the trace now also tells you where the rest of the holes are, in both directions at once, which is why it comes before anything that currently looks more urgent. What that document set contains, and how it survives the next sprint, is the subject of validation documentation and requirements traceability.

Three HIPAA items are writable today by design. A risk analysis under section 164.308(a)(1)(ii)(A) assesses the risks to your ePHI as they stand, so the current one is the correct one. The evaluation standard at section 164.308(a)(8) permits the work to be done inside the company, so it waits on no supplier's calendar. And where an addressable implementation specification went unimplemented, section 164.306(d)(3)(ii)(B) asks for a written record of the reasoning and of the equivalent alternative measure adopted. Teams read that as a hole in the evidence. It is a document nobody wrote, and it can be written this month.

IEC 62304 carries a named route for the hardest version of this problem, and teams under time pressure rarely know it is there. Subclause 4.4, added by Amendment 1, governs legacy software and offers an alternative to working through Clauses 5 to 9 in full. Its gap analysis at 4.4.3 compares the deliverables you hold against those asked for by 5.2, 5.3, 5.7 and Clause 7, those four and no others, then asks whether what you hold is still valid and how much risk reduction generating each absent item would actually buy. The floor it sets, at 4.4.3 c), is the set of software system test records described by 5.7.5. Subclause 4.4.4 wants a documented plan for the deliverables you decide to produce, and 4.4.5 wants the version of the legacy software recorded with a rationale for keeping it in use. A partial file assembled that way is a partial file the standard itself contemplates, with the reasoning visible.

For a quality system audit the ISO 13485 side is largely an inventory problem, and inventories are quick. Per software item the MDSAP regulators look for four record types: the intended use and user needs, the protocol, the results, and evidence that later changes were controlled. Off-the-shelf tooling does not require a code review, and it does require acceptance criteria fixed ahead of the run. Criteria agreed on Monday for a run on Thursday meet that condition. Agree them, then run.

Which parts cannot be closed, whatever you spend?

Five, and a chief executive should know all five before approving a budget, because a plan that quietly promises any of them is a plan that fails in the room.

The order of dates. A protocol whose approval postdates its own execution record announces on its face that nothing was approved in advance. Under 21 CFR 11.50(a) a signed electronic record has to show who signed, when, and in what capacity, review or approval or responsibility or authorship, so the capacity claimed and the date it was claimed on travel together. Today's approval can be attached to today's work. Last year's cannot.

An audit trail that was switched off. Section 11.10(e) requires the trail to be retained at least as long as the records it covers and to be available for agency review and copying. Enabling logging in week three starts a trail in week three. The months before it stay empty, and the workable answer is to record that in writing and to state what other evidence covers the period.

The identity of whoever ran a test in 2024. Subclause 5.7.5 wants the person who executed it and recorded the outcome. Where the record names nobody and no one remembers, the file carries an anomaly, and an anomaly described plainly survives better than a name taken off an old rota.

Independence, where an assessor is involved. HITRUST handbook criterion 3.3.5 bars external or internal assessor personnel who were involved in the prior 12 months in the implementation or operation of the controls being assessed from working on that validated assessment, and requires a separate team including a separate engagement partner. That is a twelve-month lookback and it cannot be shortened in week three. Criterion 3.3.4 closes the other door: management of the assessed entity must not be able to restrict the nature, scope and extent of testing the assessor determines to be required.

The fifth limit catches product companies in particular, and it closes the route this page recommended two sections ago. Subclause 4.4 is not open to everything old. Definition 3.36 opens it only to medical device software that was legally placed on the market and is still being marketed, where objective evidence of development to the current standard is insufficient. A product that never reached a market fails the first condition, so a company preparing its first audit before its first release cannot use the route at all, however thin the early records are.

What do you do in the first week?

Step 4 is the step teams skip, and skipping it turns the next four weeks into a search. The two lists are the plan. Everything after them is execution against a known quantity, and the quantity stops changing.

How long does each piece take?

Your own file decides most of it, and no supplier can estimate it before reading the trace. Six durations are fixed by published documents rather than by anyone's judgement, and they are the ones to put in the calendar first.

Six fixed windows set by HITRUST, 45 CFR 164.316 and 21 CFR 11.10(e), with what each constrains in an audit preparation plan.

Fixed window	Where it comes from	What it constrains
90 days maximum	HITRUST Assessment Handbook, chapter 4 comparison table	The assessor's validated fieldwork window, identical for e1, i1 and r2
The 90 days before the one-year anniversary	HITRUST Assessment Handbook, chapter 15.4	When an r2 interim assessment must be completed and submitted
50% or more	HITRUST criterion 15.4.9	The share of required corrective action plans that must be started or complete at the interim
12 months	HITRUST criterion 3.3.5	The lookback that disqualifies assessor personnel who built or ran your controls
6 years	45 CFR 164.316(b)(2)(i)	Retention of HIPAA documentation, counted from creation or from the day it last applied
At least as long as the records it covers	21 CFR 11.10(e)	Retention of the audit trail itself

Two of those rows are constraints on the plan itself. The 12-month independence lookback means the firm that wrote your policies or operated your controls is disqualified from the HITRUST validated assessment, so who does which piece has to be settled before the work starts and not on the day the assessor arrives. The six-year retention means the entry you write this month is read by somebody in 2032, which is the argument for writing the awkward deviation entries properly the first time.

Who is allowed to produce this evidence, and on what terms?

Anyone can produce evidence. Only certain parties may assess it, and the two roles are held apart deliberately. Under HITRUST, the validated assessment that leads to certification may be performed only by an approved External Assessor organisation, and HITRUST reviews the submission and issues the certificate itself. Under HIPAA the position is blunter. HHS OCR states that it does not endorse or otherwise recognise private certifications regarding the Security Rule, that holding one does not absolve a regulated entity of its legal obligations, and that having had one performed does not stop HHS from later finding a violation.

This site lists no certificate, and we issue none. What we produce is test evidence: executed records carrying the five moment-bound items above, a requirements trace that reports its own holes, and written deviations covering what could not be repaired. Whether the auditor accepts any of it is the auditor's call, and the regulatory position never leaves the company that ships the product.

An evidence pack is assembled in order to be handed to outsiders, which is where audits turn into a data problem that ordinary testing does not have. A screenshot taken from a live clinical system to demonstrate that an access control works contains patient data, and it then sits in a folder, in an email thread and in an assessment platform. HITRUST's own MyCSF subscription agreement bars PHI from customer data uploaded to the platform, so an exhibit has to be de-identified or redacted before it reaches the tool it was collected for. We do not need production PHI to test. Environments run on synthetic and de-identified data. What else an outside team may reach during a preparation engagement, and on what written terms, is answered at how we work with protected health information.

What do we do when the date is already fixed?

We read your file the way the auditor is going to read it, entering at the trace, and we come back with the sorted plan: what can be executed and recorded before the date, what has to be written up as a gap with its reasoning, and which pile each open item falls into. That sorting is the deliverable. A supplier who promises the second pile is promising something no supplier can produce.

Then the runs themselves. Acceptance criteria agreed before each execution starts, each record carrying the version, the configuration, the tools, the day and the executor, and the trace kept current while the work happens, so nothing has to be reconstructed at the end. Where a standard offers a route to a defensible partial file, such as the gap analysis at 4.4.3, we work that route and put the reasoning on the record instead of manufacturing the deliverables it permits you to leave out. Execution against a device file belongs to medical device software testing. The safeguard-by-safeguard work behind a HIPAA audit is a separate engagement with its own scope.

Every clause number, criterion number, threshold and retention period on this page was checked against the primary texts of HIPAA, IEC 62304, ISO 13485, HITRUST and 21 CFR Part 11, on 3 September 2026. Where a statement comes from an audit programme or a guidance document instead of from the standard itself, as with the MDSAP Audit Approach, the sentence says which.