A HIPAA / GxP evidence pack is not a document you write. It is a fixed set of sections, each one owning a question an auditor will ask, and each one backed by an artefact that already exists somewhere in the deployment. Written-after packs fail because they contain prose where the section calls for primary evidence — a paragraph explaining that access is controlled, rather than the exported access trail with a retention window and a date range.
This piece stays at the anatomy level: what the sections are, what has to sit behind each one, and who signs it. Not why the pack matters — we cover the structural case for it in our work on evidence packs for regulated AI workflows.
What does a HIPAA / GxP evidence pack contain section by section?
Six sections, in the order an auditor tends to walk them. The order is not arbitrary — an auditor establishes who could touch regulated data before asking what the system did with it, and asks what the system did before asking who approved the change that made it do that.
| Section | Question it answers | Primary evidence behind it | Typical sign-off owner |
|---|---|---|---|
| 1. Scope & intended use | Which workflow steps are regulated, and what is this AI component allowed to do? | Signed intended-use statement; workflow map with regulated steps marked | Quality + clinical/process owner |
| 2. Access trail | Who — human or service — read, wrote or derived from regulated data, and when? | Exported access log per regulated step, with retention window and non-human actor identities | IT security |
| 3. Data-handling lineage | Where did this record come from, what transformed it, and where did it go? | Lineage record tied to a specific pipeline commit or DAG version; storage-location and transfer register | Engineering |
| 4. Change control | Who approved each change to the system that ran regulated work? | Change records with named approver, date, and the model/config version each one released | Engineering + quality countersign |
| 5. Training & competency | Were the people operating the workflow qualified to operate it? | Dated training records mapped to named roles and SOP versions | Clinical operations / site training lead |
| 6. Validation evidence per regulated step | Does the system perform acceptably against defined acceptance criteria, per step? | Validation report referencing the protocol it executed, per model version | Validation function, quality-approved |
Everything else people put in packs — architecture diagrams, security policies, vendor attestations, BAAs — is supporting context that lives under one of these six, not a seventh section. A BAA belongs under scope. A hosting-region attestation belongs under data-handling lineage. If a document does not attach to a section, it is usually there to reassure an internal reader, not an auditor.
Why each section needs an artefact, not a description
The distinguishing property of a section is that it can be opened without you in the room. That is the practical test we apply during pre-audit walkthroughs: hand the section to someone who did not build the system and see whether they can answer the auditor’s question from what is in it.
Two claims worth carrying out of this:
A section survives audit only when its evidence has a date, a system of record, and a signatory. A screenshot of an access-control configuration has none of the three — it shows the state of a setting at an unknown moment, exported from an unnamed place, by nobody in particular. An access log exported from a named identity provider, covering a stated window, with the export attributed, has all three.
Section 2 is where AI workflows break the reused clinical log format. EHR, LIMS and PACS audit logs are built around named human sessions. An inference service, a nightly re-scoring job, a retrieval step, or a third-party hosted API reads regulated data without ever appearing as a user login. If the access trail cannot name non-human actors as first-class identities, the section is structurally incomplete no matter how long the log is.
Section 6 behaves differently from the other five, and it is worth saying why. Sections 1–5 are governance records the deployment emits as a by-product of running. Validation evidence is produced by a separate exercise with its own protocol, acceptance criteria and approval route — the validation pack. The evidence pack does not duplicate it; it references the validation report per regulated step and per model version, so an auditor can trace from a step in the workflow to the report that qualified it. Getting that reference right, rather than pasting performance tables into the compliance binder, is the most common repair we make on packs that were assembled late.
Which sections travel, and which get re-populated
The section list itself is invariant. What sits behind each section is not, and the split matters when you go to a second site or ship a new model version.
- Invariant across sites: the six-section structure, the intended-use statement, the validation protocol design, the control-to-requirement mapping.
- Per-site: access grants and the identity source they come from (section 2), local SOP versions the change records route through (section 4), training records for that site’s staff (section 5).
- Per regulated step: validation evidence (section 6) — and, where a step changes what the model consumes, its lineage record (section 3).
- Per model version: change record plus the validation result it releases against, which is why distilled, quantised or fine-tuned variants each need their own row rather than inheriting the parent model’s.
What a pre-audit walkthrough actually produces
Walk the workflow step by step against the six sections and ask, for each regulated step, whether the section’s artefact exists, is dated, and is attributable. The output is a countable list: n missing artefacts, each with a named owner and a close date. That count is the useful number — it converts a vague sense of readiness into something a quality lead can track to zero.
A gap is not “the section is thin.” A gap is a specific regulated step for which a specific section has no retrievable artefact. Thin prose in a section that has a stored artefact behind it is a formatting problem. A well-written section with nothing behind it is a finding waiting to be written up.
Where the pack stops is also worth marking, because scope creep here is expensive. The pack answers what an auditor walking your workflow asks. It does not answer what a regulator asks about a product’s safety and effectiveness claims — that is a submission dossier, with a different audience and a different obligation. And it does not restate a vendor’s own documentation: a cloud provider’s control attestations are referenced from section 3, not reproduced inside it.
Which leaves the question we usually end up asking first in a scoping call: for your workflow, which of the six sections currently exists as an artefact somebody could open tomorrow, and which exists only as a sentence in a proposal?
Frequently Asked Questions
What does a HIPAA / GxP evidence pack contain section by section, and what does each section mean in practice?
Every HIPAA GxP Evidence Pack organizes compliance documentation into seven core sections, each mapping to specific regulatory requirements. HIPAA GxP Evidence Pack rewards a careful definition. HIPAA GxP Evidence Pack has one honest answer. HIPAA GxP Evidence Pack rewards a careful definition. HIPAA GxP Evidence Pack Contents makes this clear: six sections: scope and intended use, access trail, data-handling lineage, change control, training and competency, and validation evidence per regulated step. Each one owns a single auditor question — respectively what the AI is allowed to do, who touched regulated data, where the data came from and went, who approved each change, whether operators were qualified, and whether each regulated step was validated. Supporting documents such as BAAs and vendor attestations sit under one of the six rather than forming sections of their own., each section needs an artefact with three properties: a date, a system of record it was exported from, and an attributable signatory or exporter. In practice that means an exported access log with a stated retention window rather than a screenshot of access settings, a lineage record tied to a specific pipeline commit rather than an architecture diagram, and a change record naming its approver rather than a policy stating that changes are approved.
Who owns and signs off each section — engineering, clinical operations, quality, or IT security — and how is that recorded?
Ownership follows the system of record: IT security owns the access trail, engineering owns lineage and change control, clinical operations owns training records, the validation function owns validation evidence, and quality owns the intended-use statement and countersigns change control. The recording mechanism is the sign-off itself — a named approver with a date inside the source system, not a separate ownership table maintained by hand.
Which sections are invariant across sites and which have to be re-populated per site or per regulated step?
The six-section structure, intended-use statement, validation protocol design and control-to-requirement mapping travel unchanged. Access grants, local SOP references in change records, and training records are per-site. Validation evidence is per regulated step and per model version, which is why a quantised or fine-tuned variant needs its own entry rather than inheriting the parent model’s.
How does the validation-evidence section differ from the rest of the pack, and where does it draw from the validation pack?
Sections 1–5 are governance records the running deployment emits as a by-product; section 6 is produced by a separate exercise with its own protocol and acceptance criteria. The evidence pack does not reproduce the validation pack — it references the validation report per regulated step and per model version so an auditor can trace from a workflow step to the report that qualified it.
What does a pre-audit walkthrough against the section list look like, and what counts as a gap?
You walk the workflow step by step and, for each regulated step, check whether the relevant section’s artefact exists, is dated and is attributable. A gap is a specific regulated step with no retrievable artefact for a specific section — not a section that reads thinly. The output is a countable list of missing artefacts, each with an owner and a close date.
Where does the evidence pack stop — which sections belong to a regulatory submission or a vendor’s own documentation instead?
The pack answers what an auditor walking your deployed workflow asks. Product-level safety and effectiveness claims belong to a regulatory submission dossier, which has a different audience and obligation. Vendor and cloud-provider control attestations are referenced from the lineage section rather than reproduced inside the pack.
Acting on HIPAA GxP Evidence Pack
HIPAA GxP Evidence Pack is rarely the hard part — knowing which of its failure modes you can live with is. That answer is workload-specific, and it is worth writing down before you build.
