Resilience is broader than a vulnerability list
A security audit asks where a website is exposed. A resilience assessment also asks what happens when hosting, email, a supplier or an administrator becomes unavailable. For example, a working checkout can still fail to fulfill orders if its notification service stops. We map these dependencies without presenting a website review as a full organizational continuity program.
Map recovery dependencies beyond hosting
Domain ownership, DNS, email, payment providers and recovery accounts can block a restored website. Map these dependencies against the customer journeys that the business must recover.
- Agree critical functions and recovery objectives.
- List providers, owners and access paths.
- Review backups and permitted test options.
- Record untested dependencies and priorities.
Recovery dependencies and missing evidence
Distinguish document review, tabletop exercise and executed restore. RTO/RPO are objectives until a test supports a measured result. Deliver a dependency map, gaps and actions without promising uninterrupted service.
| Dependency | Question | Evidence |
|---|---|---|
| DNS | Who can restore control? | Owner and access path |
| Payments | Will checkout work afterward? | Approved test or explicit gap |
| Storage | Available if hosting fails? | Independent retrieval/restore result |
Example: a backup cannot restore domain ownership
A database copy is usable, but only a former contractor controls DNS. Ownership is documented as a recovery blocker rather than treating the backup as a complete solution. This is an illustrative scenario, not a customer case or a promised result.