A business continuity plan can be technically sound and still fail at the first call. An operations manager may have left, a cloud supplier may have changed its emergency support channel, or a power contractor may require a contract number stored on the failed network. Lists of names and dependencies are deceptively simple artifacts: their value depends on ownership, availability, accuracy and tested escalation routes. A controlled maintenance process should treat the information as a live operational capability, not an annual appendix that becomes obsolete the day after it is approved.
01Distinguish contact purpose from directory information
Define the actions for which each contact is needed: incident command, worker safety, site access, IT recovery, critical suppliers, regulators and customer communications. A name and phone number without role, authorization scope or fallback path may not support a response. Record who can decide, who can implement and who is only an informed recipient. Arrange emergency details around the order in which a response team will need them.
Keep personal data proportionate to the response purpose. Use business contact details where possible, restrict sensitive personal information, and decide who may access private channels in a genuine emergency. The information needed to contact a senior incident commander differs from the technical details required to reset a protected server. Avoid a single open spreadsheet that combines all privileged recovery credentials with employee personal details.
Contact specification. For a critical person record both the emergency responsibility and the substitute route. Sending a message to a general mailbox is not equivalent to reaching someone authorized to isolate equipment or approve continuity expenditure. Protect any sensitive personal contact data through appropriate access.
Technical context: ISO 22301:2019 — Business continuity management systems — Requirements (with Amd 1:2024) is one verified source for the concepts discussed here.
02Give each dependency a live business owner
A dependency is not merely the supplier name on a purchase order. For a process to continue, it may require a particular software service, skilled operator, utility capacity, data interface, material specification or permission to operate. The owner should explain what minimum level is required and what breaks if the input becomes unavailable. This connects dependency records to the BIA and recovery strategy.
Assign a maintainer for each contact or relationship and a business owner who verifies operational significance. Central BCMS staff can set the control method but usually cannot know whether every local contractor and specialist has changed. For external services, identify the agreement owner and verify how an actual emergency request would be accepted outside normal business hours.
Dependency ownership. Purchasing can maintain a supplier relationship while a local plant owns the exact emergency service needed. Assign both responsibilities clearly. An accurate legal entity name will not help the duty manager if the contract excludes after-hours callouts or a crucial site.
03Use event-driven maintenance triggers
Annual review is insufficient for fast-changing information. Trigger targeted updates when a role changes, a supplier contract is renewed, an application is migrated, a site closes, a phone provider changes, or a recovery procedure is revised. Integrate these triggers into HR offboarding, supplier management, IT change and facilities maintenance where possible. The burden is manageable when updates occur within processes that already detect the change.
Ask the outgoing role holder or process owner to transfer recovery contacts, delegated authority and live response dependencies before the transition closes. Confirm access to shared mailboxes and emergency services rather than assuming an IT account transfer preserves all knowledge. Record the last successful verification date and the event that caused the current version to be issued.
Change trigger. During employee offboarding, transfer decision authority and emergency access before accounts are disabled. When suppliers renew agreements, confirm operational escalation and capacity rather than merely their billing contact. Those changes are natural opportunities for a concise verification record.
04Test reachability rather than relying on signatures
A signed confirmation that a directory is current does not show that the recipient can be reached during a disruption. Run targeted call or message tests at sensible intervals, including a deputy and an external provider. Do not test sensitive information by sending confidential incident details to personal channels. The exercise result should distinguish unanswered calls, wrong numbers, slow acknowledgment and a person with no authority to act.
Test cascading routes rather than isolated names. If the first contact fails, the team should know who to try next and how to document the decision to escalate. A contact test that succeeds only because the BCMS coordinator privately knows the recipient’s new number reveals a plan dependency on an individual rather than a working process.
Reachability evidence. The first phone call may ring successfully while the recipient cannot take the decision required. Include acknowledgment, delegated authority and an actual next action in the test. Record wrong numbers and delays so the organization understands which step of the cascade failed.
05Make essential details accessible through an outage
Contact and dependency information stored only in the primary collaboration platform will be unavailable during many ICT disruptions. Define offline copies or separately hosted access appropriate to security and confidentiality risks. Protect printed lists from casual access, label their versions and distribute them to authorized custodians. Availability and data protection must be designed together rather than treated as competing afterthoughts.
Consider how people will authenticate, what devices are required, whether a corporate VPN remains available and how temporary copies are withdrawn after the event. An encrypted offline file is useless if its password is stored in the unavailable password manager. Test the retrieval path on a device and network condition representative of the disruption you are planning for.
Offline access. Store essential contact information separately from the single application it supports. A securely encrypted copy can still be unusable when the recovery key depends on the same unavailable identity service. Test the real device, credentials and network conditions, not only the presence of a backup file.
| Decision domain | Owner or objective | Observable evidence |
|---|---|---|
| Role contact | Incident command and deputy | Verified reachability and authority |
| Provider | Emergency support activation | Contract reference and escalation path |
| Offline copy | Controlled access route | Retrieval test without primary system |
| Change trigger | Staff or service transition | Versioned update and confirmation |
06Reconcile changes across sites and providers
Multisite businesses often hold overlapping local, regional and corporate directories. Determine which record is authoritative for a role, contract and technical dependency. Where local contact information differs, record the intended scope rather than deleting the local detail as a duplicate. A central incident commander may require a location-specific escalation route that corporate procurement does not ordinarily use.
Create an exception process for disputed entries or missing supplier confirmations. A manager should be able to see which entries are verified, which are pending and what temporary fallback is available. If a critical provider refuses to participate in contact testing, treat that as a supplier continuity exposure to be managed contractually or through an alternative route.
Cross-site consistency. A regional controller needs a current local utility responder and a central supplier contact for contract escalation. Both may be correct for different purposes. Record the scope of each route rather than replacing site knowledge with a simplified corporate directory.
07Measure reliability, not directory size
Useful indicators include the percentage of critical roles with tested deputies, verified supplier response paths and successfully retrieved offline lists. A directory with thousands of rows can perform poorly if a small group of essential numbers is obsolete. Review exceptions after exercises, incidents and significant process changes. Protect the integrity of records while enabling authorized users to make urgent updates.
Keep evidence compact: source of update, approver, date, last reachability test and unresolved exception. The BCMS coordinator should report critical gaps rather than celebrate the number of contacts collected. This turns administrative maintenance into a practical assurance measure for whether the recovery team can mobilize when technology or people are unavailable.
Assurance metric. Count critical routes that have been retrieved and used successfully, not total directory rows. An exceptional or unverified contact needs an owner and fallback before it can be considered reliable in the recovery strategy. Make unresolved gaps visible to operational leadership.
Practical Review Questions
- Which critical contacts have no tested deputy or after-hours alternative?
- What changes automatically trigger review of this dependency record?
- Can an authorized responder retrieve the directory without normal ICT?
- Does the test verify authority and supplier acceptance, not only a working number?
Create a Contact and Dependency Verification Cycle
Select a small critical subset first: incident leadership, essential technical specialists, emergency facility providers and customer notification owners. Give each entry a maintained role, clear escalation purpose and verification date. Connect updates to staff changes, application migrations and contract renewals. Store the necessary emergency version so that it is both controlled and reachable without depending on the system likely to fail. Protect private information and privileged access details using appropriate restrictions.
Then test the actual response route: retrieve the directory without the normal platform, call the primary contact, confirm their authority, and progress to the deputy or provider escalation if required. Record elapsed steps only if they were actually measured. Treat inaccurate entries or untested external routes as live continuity risks rather than administrative formatting defects.
Closing Perspective
Current recovery information is the product of reliable change detection, clear ownership and practical testing. The best contact directory is the one an authorized responder can use at the moment normal systems are unavailable.
References & Further Reading
Official ISO publications informing the continuity method discussed above. Guidance publications provide recommendations; ISO 22301 contains BCMS requirements. The organization must validate any sector-specific legal duties separately.
- ISO 22301:2019 — Business continuity management systems — Requirements (with Amd 1:2024)
- ISO 22313:2020 — Guidance on the use of ISO 22301
- ISO/TS 22318:2021 — Supply chain continuity management guidance
- ISO/TS 22330:2018 — People aspects of business continuity
- ISO/IEC 27031:2025 — ICT readiness for business continuity