Hi @SamPorter1984,
Welcome to the community 
Some interesting ideas for controlling upgrades.
I would suggest rather than modifying the proxy, that you place any required logic at the upgrades admin level.
If you modify the proxy, then you should appropriately test and audit the code. You won’t be able to use OpenZeppelin Upgrades Plugins for deploying and upgrade safety checks. Though you could use the Upgrades Plugins for testing and this could be used for upgrade safety checks.
We recommend that the upgrades admin (owner of ProxyAdmin contract) should be a multisig.
https://docs.openzeppelin.com/learn/preparing-for-mainnet#set-admin
We have a guide on how to upgrade via a multisig using OpenZeppelin Defender:
https://docs.openzeppelin.com/defender/guide-upgrades
We also have guides upgrading via Gnosis Safe:
- OpenZeppelin Upgrades: Step by Step Tutorial for Truffle
- OpenZeppelin Upgrades: Step by Step Tutorial for Hardhat
OpenZeppelin Defender also supports a PartiallyDelayedMultisig variant developed by dYdX.
https://docs.openzeppelin.com/defender/admin#gnosis-multisigwallet
You could also look at using TimelockController to add timelocks to actions
https://docs.openzeppelin.com/contracts/3.x/api/access#timelock
From the PAID network postmortem it sounds like they had a single key controlling the upgrades admin which was compromised, rather than using a multisig.
For investor confidence you could have some of your investors and or community be owners of the multisig controlling the upgrades.
As an example, the Graph Council has a mix of stake holders for their multisig. See some of our Multi-signature wallet resources.
I suggest checking out OpenZeppelin Defender (if you haven’t already):
https://defender.openzeppelin.com/