Resilience reviews get treated as a compliance exercise more often than an engineering one. That framing misses the point. A resilience review should answer a narrower question: what happens to this system on its worst day, and who finds out first?
We usually start with dependency mapping instead of architecture diagrams, since diagrams describe the system as it was designed, not as it actually runs. From there, failure injection at the edges of the system (DNS, certificate rotation, upstream rate limits) tends to surface more than injecting failure at the core.
The output that matters isn't a report. It's a short list of single points of failure, ranked by how quietly each one would fail.