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.

GateRequired artifactSystem of record
Requirement approvedRequirement record + approver ID + timestampRequirements tracker
Design reviewedDesign review record + dispositionDesign review log
Code mergedCommit + review approvalVersion control history
Verification executedTest run ID + pass/fail + environmentCI run history
Release approvedRelease record referencing all of the above by IDAppend-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 |

Download audit-evidence-map-template.md

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

Sign in or sign up

Enter your work email to receive a temporary sign-in link.

By continuing, you agree to our Terms of Service and Privacy Policy.