SUMMARY: A dependency register records everything a critical workflow needs to function, including services, people, credentials, data, assumptions, and recovery paths.
Systems fail sideways. A website can remain online while its domain renewal, email delivery, identity provider, payment method, or only knowledgeable administrator becomes unavailable. Each component looks secondary until the moment it blocks the primary service.
A register makes those relationships explicit. It is narrower than a complete architecture diagram and more practical than a vendor inventory. Its unit is the workflow: what must be true for this outcome to continue?
Create the First Entry
Choose one critical workflow, such as publishing an urgent correction or restoring member access. Name its owner and acceptable interruption window. Then trace every required service, account, person, secret, approval, and data source until each dependency reaches something independently controlled or physically retained.
Record What Matters
Function: state what the dependency contributes and which step stops without it.
Ownership: identify the person and institution able to change, renew, or revoke it.
Failure signal: document the earliest observable sign that the dependency is degrading.
Alternative: name the fallback path and the last date it was tested.
Concentration: flag dependencies shared by several workflows, because one failure can disable them together.
Test One Link
Simulate the loss of a noncritical dependency and run the fallback without the usual operator. Record missing instructions, inaccessible credentials, stale contact details, and recovery steps that depend on the failed service itself.
The register extends the redundancy map by tying alternatives to real workflows. Use recovery authority to identify who controls restoration when a dependency fails.
Operator rule: a fallback is only a capability after someone other than its designer has tested it.