What Do You Actually Do About a Risk?
Once you have identified and scored a risk, you have exactly four options for responding to it. Every risk management decision falls into one of these categories. Knowing which strategy you are applying — and being able to articulate why — is what separates deliberate risk management from accidental negligence.
1. Avoid — Eliminate the risk entirely by not doing the risky thing.
- Example: You are considering using a brand-new, unproven database. The risk of data loss is high because it has not been battle-tested. You avoid the risk by choosing PostgreSQL instead.
- Trade-off: Avoidance often means giving up potential benefits. The new database might have been 10× faster for your workload.
- When to use: When the risk score is in the red zone and the activity generating the risk is not essential to your core value proposition.
2. Mitigate — Reduce the likelihood or impact (or both).
- Example: Your single-region deployment has a risk of regional outage. You mitigate by deploying to two regions with automated failover. The risk is not eliminated — both regions could fail — but the likelihood drops dramatically.
- This is the most common response. Most engineering reliability work — backups, redundancy, monitoring, circuit breakers, rate limiting, health checks — is mitigation.
- When to use: When avoidance is not feasible but the risk score justifies investment.
3. Transfer — Shift the financial or operational burden to someone else.
- Example: You buy cyber insurance to cover the financial cost of a data breach. You use a managed database service like AWS RDS to transfer the operational risk of database administration to AWS.
- Transfer does not eliminate the risk — your customers still experience the outage. It shifts who pays for the consequences.
- When to use: When the residual risk after mitigation is still significant, but the cost of further mitigation exceeds the cost of insurance or a managed service.
4. Accept — Acknowledge the risk and do nothing.
- Example: There is a 0.001% chance that a cosmic ray flips a bit in memory and corrupts a calculation. You accept this risk because the cost of mitigation (ECC memory everywhere, triple-redundant computation) far exceeds the expected loss.
- Acceptance must be conscious and documented. "We did not think about it" is not acceptance — it is negligence.
- When to use: When the ALE is lower than the cost of any available mitigation, or when the risk is genuinely outside your control.
Choosing the right response:
Is the risk score in the red zone?
├── Yes → Can you avoid it without sacrificing core value?
│ ├── Yes → Avoid
│ └── No → Mitigate aggressively; transfer residual financial risk
└── No → Is the cost of mitigation less than the ALE?
├── Yes → Mitigate
└── No → Accept (document the decision, name the person who made it)
If an interviewer asks "How would you handle the risk of [X]?", structure your answer by explicitly naming which of the four strategies you would use and why. For example: "I would mitigate the risk of database corruption by implementing automated backups with point-in-time recovery, and I would transfer the residual financial risk through our cloud provider's SLA guarantees. I would accept the risk of a sub-second data loss window because the cost of synchronous replication to a third region exceeds our budget." This shows structured thinking rather than a list of tools.
Key Point: The most dangerous response is implicit acceptance — risks that nobody has consciously evaluated. Every risk in your register should have an explicit response strategy. If the strategy is "Accept," that is fine — but it must be a deliberate decision with a named person who made it, not an oversight that nobody noticed.