Build a Personal Dependency Map Before One Failure Spreads

A household function can look like one service and behave like a chain. “We can contact each other” may depend on charged phones, a carrier account, a home internet connection, cloud contacts, remembered passwords and one person who knows the plan. “We can access family records” may depend on a laptop, an encryption key, a sync account, a payment method and a recovery email hosted by the same provider.

A dependency map makes the chain visible before a failure chooses where to reveal it. This is not enterprise continuity planning and it is not a reason to build a bunker of duplicate equipment. It is a practical way to identify where a small, inexpensive fallback protects a function that matters.

Start with a function, not a device

“Keep the Wi-Fi working” is a device-centered goal. “Keep one route for urgent communication” is a function. The second statement allows more solutions: cellular voice, a neighbor's number on paper, a charged radio or a meeting point may matter more than preserving every connected screen.

Choose one function with a meaningful consequence of delay. Good first candidates include contacting household members, accessing medication information, paying an essential bill, recovering a primary email account or reaching stored legal documents. If the outcome is vague, the map expands without limit.

The National Institute of Standards and Technology's contingency planning guide is written for federal information systems, not households. Its durable idea is still useful: identify essential functions, dependencies and recovery priorities before disruption. The field guide below is a deliberately smaller adaptation for ordinary life.

Map seven dependency layers

1. Outcome: the minimum result a person needs.
2. Front door: the device, app, number or physical place normally used.
3. Identity: passwords, multifactor methods, recovery email, account holder and billing status.
4. Transport: electricity, cellular service, internet, local network, roads or mail.
5. State: the contacts, records, settings, keys or data the function requires.
6. People: who knows how to operate, authorize, repair or approve the fallback.
7. Vendor: the external organization whose continued operation and policy the chain assumes.

Draw arrows only when one node actually requires another. A password manager may require a device but still provide an offline cache. A smart lock may have a physical key. A cloud file may also exist on an encrypted drive. The map should show real paths, not brand slogans.

The dependency-map worksheet

Replace the examples with your actual systems. Do not put live passwords, full recovery codes or alarm details in an exposed worksheet. Record where protected credentials are stored rather than copying them into the map.

Find the nodes that appear in several chains

A single point of failure is a node whose loss removes the only path to the outcome. The most important nodes often appear in several maps: primary email, phone number, home power, internet service, payment card, password manager or one knowledgeable person.

Shared dependencies deserve attention because one failure can spread. If primary email resets the password manager and the password manager stores the email recovery codes, the system may contain a loop rather than a path. If every smart-home fallback needs the same router that failed, it is not a fallback.

Rank nodes by consequence and replaceability. A short internet outage is inconvenient if cellular service remains. Losing the only decryption key can be permanent. A complex plan should not receive priority merely because it is technically interesting.

Choose one control per high-consequence node

• Alternative path: a different channel, device or provider that does not share the same failure.
• Offline copy: current data in a usable format with the key and reader required to open it.
• Manual mode: a documented way to operate the essential function without automation.
• Power boundary: safe, correctly sized backup power or an orderly shutdown—not improvised electrical work.
• Second person: someone else who knows the procedure and has appropriate authority.
• Exit route: a tested export, replacement or cancellation path if the vendor changes terms or disappears.

Keep controls proportional. A paper contact card can solve a critical phone dependency for almost no cost. A second paid service may add complexity without independence. The correct control reduces a named consequence.

Run a safe dependency test

Choose one low-risk node and temporarily remove it. Turn off Wi-Fi and verify the intended communication fallback. Put a device in airplane mode and confirm an offline document opens. Use a spare account to walk through recovery instructions without changing the production credential. Ask the second person to locate—not expose—the protected recovery material.

Do not simulate a failure by bypassing electrical safety, disabling alarms, interrupting medical devices, locking people out, cutting fuel or power, or changing a production system you cannot restore. For life-safety, electrical, fuel, security or model-specific equipment, follow the manufacturer and use a qualified professional.

Record the test date, actual result, failure discovered and next review. A fallback that has never been used is a hypothesis. The test converts part of the map into evidence.

The 45-minute mapping session

1. Five minutes: name one essential outcome and the maximum tolerable delay.
2. Ten minutes: draw the normal path and seven dependency layers.
3. Ten minutes: circle shared nodes, loops and single points of failure.
4. Ten minutes: choose the smallest useful control for the highest-consequence node.
5. Ten minutes: test one safe fallback and schedule the next review.

Stop after one function. A small map that changes one decision is more useful than a complete diagram no one maintains. Add another function only after the first map has an owner and review date.

Sources and further reading

• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems, for formal contingency-planning concepts.
• Ready.gov: Make a Plan, for household communication, meeting-place and plan-maintenance guidance.
• Life in the Simulation: A System Is Not Resilient Because It Has Never Failed, for the companion recovery-evidence framework.