The risk you define is about your system, without any of the mitigations. If this aspect of your system fails, then what happens? Someone dies, someone is injured or someone gets a minor injury or someone is scared out of his wits but essentially unharmed. For these types of risky conditions you can determine acceptability through probability So is 1 death in the lifetime of the device OK for the intended use of this device? Like for an emergency response system where chances of survival are already slim and application of the device might save or kill a patient (like the application of current with a heart start device), this might be OK, but for a bloodpressure measurment device we'd never get it approval. So you also need to take a look at the competition. How acceptable is the risk? We accept X-ray in order to get a better view of a broken bone or to perform life saving surgical operation on the heart. But it isn't harmless. You need to define the DIRECT contribution of the failure to the nasty situation. If you have done that, you know what kind of failure your mitigation will have to prevent or will allow for. And with software assume that the chance of failure is 100%. So then for your mitigation and if you go towards a software only solution, that means you might end up having to accept that your software will not sufficiently reduce the risk for it to become acceptable and you might still have to look at a hardware solution. In order to design such a safeguarding system you need to look at other standards. There are many and all have their perks. Most can be found in the particulars of the 60601 or the 80801 series. Like for warning systems there are standards like for example IEC61508, and there are a lot more. So check the IEC 60601 series or the IEC 80601 series for specifics about your system, the safety and essential performance requirements and compliance to them, or go through the IEC 16142-1 for an idea on where to look. There are several series and standards on the subject of safety systems, warning and alerting systems. You need to find the right one. After you have defined how important it is for this software (and hardware system) that guards your medical device to not fail, you can then define requirements as to the allowed failure rate, durability, operational safety, etc. And that will then determine how redundant stuff needs to be designed, how stringent you need to monitor and how carefull you need to be with updates in order to meet the specified criteria.