How would you design a hotfix process?

Around one principle: an urgent fix must not have to inherit the risk of whatever is currently in test.

• A hotfix environment that matches what is live in production right now, not what is being regression-tested.
• A branch taken from the release tag that production is running, so the fix carries no unreleased work.
• A proportionate but real test pass — the fix itself plus the critical-path regression around it. "Urgent" is not a reason to deploy untested code, and it is usually the second incident of the day that comes from the fix.
• A named authoriser who can approve outside the normal calendar, agreed in advance so nobody is looking for them at 2am.
• A mandatory back-merge into the mainline and into the in-flight release branch, with a defined window and a visible list of outstanding retrofits.

The back-merge is where hotfix processes actually fail. Everything up to the production deployment happens under pressure and gets done; the merge happens after the pressure lifts and gets forgotten, and the next release quietly reverts the fix. I make it an exit criterion of the hotfix rather than a follow-up task.