Audit-ready SDLC: what the phrase has to mean concretely
Practice · Audit-Ready Engineering
An audit-ready SDLC names, for each of the 5 clauses of IEC 62304 life-cycle process (§5 to §9), the exact artifact and system of record, from a requirements traceability matrix regenerated from source control to 21 CFR Part 11 electronic release records with approver ID and timestamp, so an auditor's question ("show me why this release was approved") has one answer, not a search.
What does an audit-ready SDLC mean concretely?
An audit-ready SDLC names the exact artifact and system of record for each of the 5 clauses of IEC 62304 life-cycle process. An auditor asking why a release was approved then gets one answer, not a search.
"We document everything" is not audit-ready — it's a promise an auditor can't check.
"Audit-ready" is a property of your evidence map, not your intentions
Teams that say "we document everything" and teams that pass an audit cleanly are not the same population. The difference is whether every gate in the SDLC has a named artifact in a named system of record — so an auditor's question has one place to look, not a search across Slack, a wiki, and someone's memory.
Two kinds of evidence, and why the distinction matters
Under IEC 62304, some MedTech evidence is regenerable — a
test run can be re-executed and reproduces the same evidence shape (a
requirements traceability matrix built from source control is
regenerable). Under 21 CFR Part 11, other evidence is point-in-time — a
specific person approved a specific MedTech release at a specific moment,
and that fact can never be regenerated, only recorded once, correctly, and
preserved in an audit trail. An audit-ready
SDLC treats point-in-time evidence as append-only by construction — the
same pattern this repository's own opportunities state
transitions and telemetry_observed_events table use: a
state-transition event is written once, with a timestamp, and never edited
after the fact.
Sovereign audit trails over a vendor's activity log
A third-party project-management or ticketing SaaS's "audit log" feature is convenient, but it's evidence you don't control the retention or export format of — if that vendor changes its data-retention policy, your audit trail changes with it. A first-party, append-only evidence store (even a simple one) that your own team owns the schema and retention policy for is the sovereign-data-control version of the same requirement.
Audit evidence map
A worked example — six release gates, each with its artifact and system of record.
| Gate | Required artifact | System of record |
|---|---|---|
| Requirement approved | Requirement record + approver ID + timestamp | Requirements tracker |
| Design reviewed | Design review record + disposition | Design review log |
| Code merged | Commit + review approval | Version control history |
| Verification executed | Test run ID + pass/fail + environment | CI run history |
| Release approved | Release record referencing all of the above by ID | Append-only release log |
Engineering reference only. Not formal regulatory counsel. Adapt the gate list to your own quality system's actual SDLC.
Artifact: audit-evidence-map-template.md
Generated client-side; no server round-trip, no account required.
# Audit Evidence Map (template, v1.0.0)
One row per release gate: what an auditor asks for, and exactly where it
lives. Engineering reference template only.
| Gate | Required artifact | System of record | Regenerable from source? |
|---|---|---|---|
| Requirement approved | Requirement record with approver ID and timestamp | Requirements tracker | No — point-in-time approval event |
| Design reviewed | Design review record, reviewer(s), disposition | Design review log | No — point-in-time event |
| Code merged | Commit + review approval | Version control history | Yes — git log is the record |
| Verification executed | Test run ID, pass/fail, environment | CI run history / test database | Yes — regenerable by re-running |
| Risk control verified | Verification record linked to ISO 14971 risk ID | Risk management file | No — point-in-time record |
| Release approved | Release record referencing all of the above by ID | Release log (append-only) | No — point-in-time approval event |
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- HIPAA Security Rule, 45 CFR §164.312(b) — U.S. Department of Health and Human Services
- ISO 27001:2022 — International Organization for Standardization
- Ingested from
-