Kanban in Regulated Environments

In the last unit you learned to forecast honestly and shorten lead time. In a regulated environment (health-tech, finance, medical devices), the question shifts from "how fast?" to "can you prove it?" An auditor can point at any shipped change and ask you to show that the requirement behind it was tested and actually deployed. The fear most teams carry is that this drags Kanban back into heavyweight stage-gates that wreck the flow you just built. The whole argument of this unit: you can satisfy audit and protect flow at the same time, as long as the evidence is a by-product of normal work rather than a paperwork sprint before the audit.

Start with the traceability chain: requirement → test → increment. The goal is that each link builds itself in the tools the team already uses. Every card carries a requirement ID, the pull request links back to that card, the automated test run attaches to the requirement, and the deployment record names the build and commit that shipped. Done well, "prove this was tested and released" becomes a click-through, not a reconciliation exercise.

• Dan: Audit's in six weeks. Should we block a sprint to assemble the evidence pack?
• Nova: What if the pack assembled itself? Every card already carries its requirement ID, the PR is linked, the test run is attached.
• Dan: So when they ask "prove this was tested and shipped," I just click the card?
• Nova: Right. The trail is a by-product of how you already work, not a binder you build under pressure.
• Dan: That only holds if nobody skips the linking step.
• Nova: Which is why it becomes a pull policy, not a good intention.

Notice the last move: the trail only stays trustworthy if the linking is enforced by the workflow, not left to memory.

You already write explicit pull criteria for column transitions. In regulated work, you extend those criteria to capture audit evidence at the same moment. A card cannot leave "In Review" unless the linked test run is green and the reviewer is recorded; a card cannot enter "Done" without a deployment record. The evidence is captured continuously, as part of the pull, rather than reconstructed at a release gate.

This is the conversation to have with compliance. Their instinct is a thick documentation pack before every release, because a pack feels safe. Your job is to separate what audit genuinely requires from habit and over-caution, then show that an explicit, continuously-enforced policy produces the same evidence without freezing flow. Minimal ceremony means the policy is short, posted where the work happens, and checked by the tool, not performed as a separate ritual.

Not every change carries the same risk, so not every change deserves the same control. Earlier you defined classes of service by urgency (standard, expedite, fixed-date, intangible). Here you add a risk dimension. A change to a dosage calculation or a payment path warrants more control than a copy tweak or an internal dashboard tweak. High-risk changes get heavier change control: an extra reviewer, a documented approval, a recorded rollback plan, more test evidence. Low-risk changes flow under the standard pull policy.

The skill is choosing the minimal control set that still satisfies audit for that risk level. Over-control everything and you reintroduce the bureaucracy Kanban was meant to dissolve; under-control the high-risk path and you fail the audit (and put users at risk). Match the control to the risk, deliberately, and write down which is which.

The principle that ties the unit together is as-light-as-allowed, as-heavy-as-required. The common failure is documenting everything to the same heavy standard "to be safe," which slows low-risk work and quietly teaches the team that documentation is theater. Instead, tier it. Give the team a one-line decision rule: does this change touch a regulated function, patient data, or a safety-critical path? If yes, heavy tier; if no, light tier. Make the criteria explicit so the tier isn't decided by mood in the moment, and protect the heavy cases plainly so nobody can argue a high-risk change into the light lane.

The throughline of this final unit: in regulated work you don't trade flow for compliance, you make the evidence fall out of normal flow and you size control to risk. A short cluster of practice sits ahead: a quick judgment check on picking the minimal class-of-service and change-control set, a traceability approach you could hand to compliance, a live alignment with a documentation-heavy compliance manager, and a tiered documentation recommendation. Before any of it, try one move on your own board: pick a recently shipped card and see whether you can trace it requirement-to-test-to-deployment in clicks, then fix the first broken link you find.