A dispatcher enters credentials into a suspicious login page, then reports it. The immediate task is to coordinate account recovery and shipment protection. Start these workstreams in parallel through your incident process; do not wait for proof of cargo loss or for a complete investigation before escalating.
1. Reach the incident owner through a trusted channel
Notify the organization's security or IT contact and freight operations lead using previously established contact details. If there is no internal IT team, contact the platform's legitimate support channel directly. Stop using the suspect link. IC3 describes deceptive login pages and recommends navigating through known bookmarks rather than search advertisements. IC3 account-takeover guidance.
2. Have the account owner contain access
Tell IT or the provider which account and credentials may have been exposed, without copying passwords or one-time codes into the incident notes. Ask them to apply the platform's recovery procedure. IC3 recommends resetting exposed credentials. For Microsoft 365, Microsoft's procedure also addresses disabling access, revoking sessions, and reviewing authentication methods, application access, and forwarding rules. Other platforms require their own procedures. Microsoft compromised-account response.
3. Preserve the timeline without delaying containment
Record when the suspect page was used, when the concern was reported, and what the user observed. Preserve the original message and URL through the security team's evidence process. Ask the administrator to retain relevant logs. Do not revisit the suspect page to recreate events or circulate a clickable phishing link in a broad dispatch chat.
4. Identify shipments that need immediate review
Operations should list loads the account could access during the suspected exposure period, as far as currently known. Prioritize pending releases and recent changes to carrier identity, driver details, pickup references, destinations, or payment instructions. Mark the exposure window as provisional until the investigator establishes more. Possible access is a reason to review, not proof that each load was altered.
5. Reconfirm affected instructions independently
Use established contact records to verify material changes. A reply from the same suspect account is insufficient confirmation. Give the responsible warehouse, carrier, or customer contact the specific instruction requiring verification and the authorized escalation contact. Any hold or release decision belongs to the responsible operating party under its procedures; track that decision against the load.
6. Route financial and reporting decisions to their owners
Escalate suspected payment diversion to finance immediately. If a fraudulent transfer occurred, IC3 advises promptly contacting the originating financial institution and reporting to IC3. Let the incident owner coordinate other notifications and any additional reporting obligations based on the actual facts. Keep statements precise: distinguish suspected access, confirmed changes, and known losses. IC3 incident steps.
7. Separate account recovery from operational closure
Record both the administrator's recovery status and the disposition of every flagged shipment. A restored login does not show that a warehouse received corrected instructions. Assign outstanding callbacks to an owner and set the next review time. Close the operating incident only when the designated lead has reviewed those unresolved items and documented the decision.
Copyable incident coordination worksheet
| Workstream | Minimum handoff record |
|---|---|
| Incident ownership | Security/provider contact, operations lead, trusted callback channel |
| Account response | Account identifier, administrator action/status, time; no secrets |
| Evidence | Reported event time, provisional exposure window, evidence location |
| Shipment review | Load ID, release status, change requiring verification, owner |
| Verification | Independent contact, response, hold/release decision, timestamp |
| Finance/reporting | Responsible owner, action/status, restricted reference location |
| Closure | Account recovery status, remaining load actions, next review |
Worked example: recovery is only one part of closure
Hypothetically, an administrator begins account recovery while operations finds three pending pickups visible to the account. One load has a destination-change message. Operations asks the established customer contact to verify it and alerts the release owner through a known channel. The incident record shows “destination unverified” until that check finishes. A password-reset confirmation does not clear the destination change or establish that the other two loads were compromised.
Put it to work: Use the ProspectSentinel booking-change verification guide to structure the shipment review alongside your provider's account-recovery process.