Article
Test supplier incident contact routes before an outage
Run a bounded supplier contact drill that checks acknowledgement, backup channels and handover without simulating a real emergency.
Contrata editorial team · Published · Prepared on
A supplier contact list can be accurate and still fail during an incident. The account manager may be on leave, the support portal may require the identity service that is unavailable, or a message may reach an unattended mailbox.
For a lean Australian risk team, a useful test is narrower than a full disruption exercise: can the right people exchange and acknowledge a clearly labelled test message through an agreed route when the normal route is unavailable?
This guide offers an original contact-drill method, not a regulatory test standard. It does not test the supplier’s recovery capability or establish that notification obligations have been met.
Test a route, not just a phone number
Start with one service and one scenario. For example: “Our normal email and supplier support portal are unavailable, but a pre-agreed telephone route remains usable.” Do not disable production systems to create that condition. Simulate their unavailability within the exercise.
Write down the chain: who initiates contact, which supplier role receives it, how the recipient verifies the caller, who acknowledges the request and how the internal deputy receives the outcome. A successful call to a switchboard does not prove that chain works.
ASD’s incident-response planning guidance includes primary and secondary reporting contacts, availability, roles and communications arrangements. Use those categories to expose missing links rather than collecting every employee’s mobile number.
Agree the exercise boundaries first
Obtain agreement from the supplier and your incident owner before making test calls. Set the date, participating roles, permitted channels, identifying phrase, stop condition and what must not happen. A live emergency takes priority; participants should know how to end the drill immediately.
Do not send an unannounced “breach” message, open a false critical ticket or call emergency services. Use harmless fictional details. Do not include credentials, personal information, production incident records or instructions to change access.
Agree the acknowledgement target for this exercise and record its basis. It might reflect your operational need and the supplier’s contracted support coverage. It is not automatically a new contractual commitment, recovery target or regulatory deadline.
If after-hours coverage matters, test it only through a mutually approved arrangement. A weekday call cannot demonstrate weekend reachability.
Check whether the fallback has the same weakness
A second messaging app may still require the same identity provider, corporate device or network as the first. Ask the technical owner which dependencies the proposed fallback shares with the simulated failure. Separate “another channel” from “a channel available in this scenario”.
MITRE’s out-of-band communications guidance describes an alternative path that does not depend on potentially compromised primary network infrastructure. The point is separation from the affected environment, not the name of an application.
For further context, SANS Internet Storm Center’s discussion of out-of-band networks explains why using an external communications service from an affected endpoint can still expose a conversation. A working login alone does not establish that a fallback is suitable for sensitive incident information.
Keep contact details in an approved location available under the scenario, with appropriate access and retention controls. Availability is not a reason to publish a private contact list or copy it indiscriminately to personal devices.
Use a small observation sheet
Record observed steps separately from assumptions. The following is an original worksheet, not a pass threshold prescribed by a regulator.
| Field | What to record |
|---|---|
| Scope | Service, simulated unavailable route and approved participants |
| Initiation | Time, time zone, sender role and route used |
| Verification | How the recipient’s identity and the test caller’s authority were checked |
| Acknowledgement | Who acknowledged, when, and whether they could route the request |
| Handover | Whether the internal owner or deputy received and understood the outcome |
| Unproven boundary | Untested shifts, dependencies or people |
| Follow-up | Specific defect, owner, due date and retest evidence |
Use an independently verified, pre-agreed contact route when checking identity. Do not treat a callback number supplied in an unexpected message as sufficient verification.
Fictional example: the number works, the handover does not
A fictional insurer, Harbour Mutual, agrees a contact drill with its document-processing supplier. Their scenario makes email and the support portal unavailable. The exercise is scheduled for 10 am AEDT on 29 October 2026; the teams choose a 15-minute acknowledgement target for this drill only.
At 10:02, the service owner calls the previously verified duty number. The supplier authenticates the caller using its agreed procedure and acknowledges at 10:08. That is six minutes after initiation, within the exercise target.
The supplier then sends the confirmation to the service owner’s ordinary email address. The internal deputy cannot see it under the scenario. The team records two findings: supplier acknowledgement worked for the tested weekday shift; the internal handover failed.
They do not mark the overall route “passed” merely because someone answered. The internal incident owner agrees a permitted alternate handover route and retests that step. Weekend coverage and a compromised-device scenario remain explicitly untested.
Close the defect, then keep the result useful
Retain a concise record of the agreed scope, observations, unresolved limits and retest result. Remove unnecessary personal details from broadly shared summaries. Revisit the route when contacts, support coverage, authentication or communications dependencies change, and fit further exercises into your organisation’s risk-based programme.
Once a real supplier notice arrives, use the supplier-incident intake guide to capture facts and support escalation. For a wider disruption scenario, see the outsourced claims exercise.
The useful outcome is not “contact list checked”. It is a bounded statement about which route worked, under which conditions, and what still needs attention.