When technology fails during a busy morning, everyone wants to do something. One person restarts the router, another changes a password, and a third starts restoring files. Soon the original symptom is buried under several new changes.
The first ten minutes should produce a clearer picture and a coordinated response. They do not need to solve every possible cause.
First, decide whether this looks like an incident
A ransom demand, unexpected file encryption, or signs of unauthorized account activity should go to the designated incident lead immediately. Follow the business containment process and the response team’s instructions. Do not start experimenting with deletion, restoration, or mass restarts.
For an ordinary outage, name one coordinator. That person collects observations and keeps a record of actions. This prevents several well-intended helpers from changing the environment in different directions.
Describe the scope
Ask what failed, who is affected, and when it last worked. One user unable to open a file is a different situation from everyone losing access to the entire shared drive.
- Which task cannot be completed?
- Is one person, one room, or the whole business affected?
- What exact message appears?
- What changed immediately beforehand?
- Is any critical work or physical safety affected?
Record facts and label guesses as guesses. Keep screenshots free of sensitive client details when sharing them outside the approved support route.
Check known information safely
Use a separate working device or connection to check a provider’s official status page or contact support through a known number. Do not use a surprising outage email as proof of where to sign in.
If email is unavailable, use the communication method the business has already approved. Avoid moving confidential records into personal messaging accounts simply to keep the conversation going.
Keep work moving within a boundary
Ask the process owner which tasks can continue safely and which must wait. A temporary paper log may be appropriate for some operations, but it needs an owner, a secure location, and a plan for reconciling it later.
Do not invent an alternate workflow for regulated, financial, or safety-critical work on the fly. The person accountable for that process should approve the fallback.
Hand off a useful record
Tell support the scope, timing, messages, and changes already made. Ask who owns the next action and when the next update will occur. Avoid promising a recovery time before the cause is understood.
After the disruption, record what would have reduced confusion: a contact list, clearer escalation, a tested fallback, or a recovery procedure. Keep those instructions accessible outside the failed system.
A calm response is not inactivity. It is choosing actions that improve the picture, protect the work, and give the right person room to resolve the problem.