Resilience and disaster recovery get treated as the same discipline more often than they should be. A recovery plan answers the question of what happens after something fails. Resilience asks a different, earlier question: how much disruption can this system absorb before it actually fails in the first place. Organizations that only invest in the first question tend to discover, at the worst possible time, that the second one was the more important one to have answered.
The practical difference shows up in where the investment goes. Recovery-focused planning spends its budget on backups, failover procedures, and documentation that gets reviewed twice a year. Resilience-focused design spends earlier, on architecture: reducing single points of failure, building in graceful degradation so a partial failure doesn't cascade into a complete one, and sizing capacity for the disruption that's plausible, not just the disruption that's typical.
This is a harder case to make internally, because resilience spending doesn't produce a visible result until the day it's tested by something real, and by then it's too late to have made the case. The organizations that get the investment right tend to reframe resilience not as insurance, which is easy to defer, but as a performance characteristic of the system, the same way latency or throughput would be treated, with its own targets and its own accountability.
None of this replaces the need for a recovery plan. It changes what that plan is for. A well-designed resilient system needs a recovery plan for the disruptions it genuinely couldn't absorb, which should be a much shorter list than the one most organizations are currently planning around.