We have recovery procedures for our important services, but it is becoming clear that the application list alone is not enough. A service may be technically restored while still failing because a DNS record, identity provider, certificate, network route, third-party API, queue, secrets store, or internal database dependency was missed.
We are trying to make dependency mapping useful for real recovery decisions rather than creating a static diagram that becomes obsolete immediately. The ideal outcome would be knowing what must come back first, which dependencies have single points of failure, who owns each one, and how to validate the end-to-end service after restoration.
For teams that have made dependency mapping part of continuity planning, what level of detail has been sustainable? Do you maintain it through CMDB data, observability traces, service catalogs, architecture reviews, or recurring recovery exercises?
Source: r/ITIL · by /u/Primary_Cupcake8557