Speaking Topic: Why Disaster Recovery Belongs at the Board Level
A single-provider dependency chain is a board risk decision wearing an engineering costume.
Disaster recovery usually gets treated as an engineering implementation detail, reviewed by the infrastructure team and reported up as a line item in a quarterly update. I argue the decision to tether DNS, authentication, and a primary database to a single provider is a board-level risk decision, not an engineering preference.
The reason is simple: the blast radius of that decision is business continuity, which is a board responsibility, not an engineering one. Engineering can execute the resilience architecture, but the risk tolerance it is built against should be a decision the board has actually made, not inherited by default from whichever engineer set up the account years ago.
When I advise boards, I ask them to state their resilience risk tolerance explicitly, in writing, before the architecture team designs against it.
Key Takeaways
- 01Single-provider dependency concentration is a business continuity decision, not only an engineering one.
- 02Resilience risk tolerance should be stated explicitly by the board, not inherited by default from legacy engineering decisions.
- 03Engineering executes the resilience architecture; the board should own the risk tolerance it is built against.
Frequently Asked
Why should a board care about a technical dependency chain?
Because the blast radius of a single-provider dependency failure is business continuity, which is squarely a board responsibility, regardless of which team implemented the architecture.
From the Q&A
“How do you get a board to actually engage with this, rather than defer to engineering?”
By framing it as a single, explicit question: what is your acceptable downtime if this one provider has a regional outage, and has anyone ever tested that number.