The most valuable phishing response is not a perfect employee who never makes a mistake. It is a business process that makes suspicious activity easy to report, limits what one mistake can expose and helps the response team act quickly without blame.
Phishing is broader than a poorly written email. Socially engineered messages can arrive by email, SMS, chat, QR code or phone and may ask a person to open a file, visit a website, share credentials or verification codes, install software, approve an MFA prompt, transfer money or change bank details. ASD's Australian Cyber Security Centre (ASD's ACSC) updated its guidance in April 2026 to include unsolicited “support”, device-linking requests, QR codes and registration or verification codes (ASD's ACSC detecting socially engineered messages).
Good spelling is not evidence that a message is legitimate. Treat context and requested action as more important than appearance.
Before an incident: make the safe action the easy action
Give every worker one obvious reporting route—a mail-client report button, a dedicated address or a help-desk option—and tell them what happens next. A report should be welcomed even when the message proves harmless. If people fear embarrassment or punishment, they may hide the event until damage becomes harder to contain.
Put independent verification into business processes, especially payments, payroll, credential resets, customer-data exports and changes to supplier details. A callback must use a number obtained from an existing trusted record or official website, not the number in the suspicious message. ASD's business email compromise guidance recommends a clear and consistent process to verify payment and sensitive-information requests (ASD's ACSC BEC guidance).
Technical layers still matter: MFA, unique credentials in a password manager, restricted administrator access, supported updates, endpoint protection, email filtering and domain authentication. None proves that every delivered message is safe. Pair controls with logging and an escalation path so the business can investigate account changes, new sessions and unusual mailbox rules.
Recognise the request, not just the design
Pause when a message introduces one or more of these conditions:
- an unexpected change to bank or supplier details;
- urgency, secrecy, authority or pressure to bypass a normal approval;
- an unexpected attachment, shared document, QR code or login link;
- a request for a password, recovery code, MFA approval or remote access;
- “support” that contacts you first and asks you to install software or link a device;
- a sender name that looks familiar but a domain, reply address or conversation context that does not; or
- a request that is plausible but unusual for that person, customer or supplier.
When uncertain, go independently to the organisation's official website or app, or call a known number. ASD advises users not to enter credentials into a website reached through a message link and to use an out-of-band contact method to confirm unexpected attachments or requests (ASD's ACSC detection guidance).
Response path 1: the message arrived, but nobody interacted
Do not reply, click, scan the QR code, call a supplied number or forward the message casually. Use the organisation's reporting method. Where an IT or security team may need headers or the original item, follow its preservation instructions rather than deleting the evidence immediately; ASD's guidance tells workers who suspect a socially engineered message not to delete or forward it, but to contact their IT help desk or security team.
The person handling the report should check whether other staff received the same campaign, block known malicious indicators where appropriate and warn the specific people who may be targeted. Avoid sending a clickable malicious link in the warning.
Response path 2: somebody clicked a link, but entered nothing
Report the event immediately and record the time, device, account, message and observed page. A click does not by itself establish that the device or account is compromised, but it warrants triage. Do not keep browsing the page to “test” it.
If a download ran, an attachment opened, software was installed, a browser extension appeared or the device behaves unexpectedly, stop using the device and contact the response owner. Isolate it from normal business connectivity if the response procedure calls for that. Do not use a potentially compromised device to reset important credentials.
Response path 3: a password, code or MFA approval was provided
Treat the account as potentially compromised. From a known-clean device and trusted route to the service:
- contact the internal response owner or provider;
- change the affected credential and any reused credential;
- sign out or revoke other sessions and tokens where the service supports it;
- verify recovery email addresses, phone numbers, MFA methods and delegated access;
- check for new mailbox forwarding rules, filters, application permissions and administrators;
- review available sign-in and audit logs; and
- preserve a timeline of what was observed and changed.
ASD's recovery guidance for business email compromise specifically includes changing the passphrase, checking recovery details, signing out other sessions and enabling MFA (ASD's ACSC BEC recovery guidance). If the account can reset other services, assess those services too.
Response path 4: an attachment or remote-support tool may have executed
Separate the affected device from business networks without wiping or “cleaning” it first, unless qualified responders direct otherwise. Record what ran and when. Preservation matters because logs and files may be needed to establish scope. The response team can then decide whether to collect evidence, scan, rebuild or restore the device.
Change exposed credentials from a clean device, not from the suspected endpoint. Review access from the device to file shares, cloud storage, password stores and administrative systems. A factory reset or antivirus scan alone does not establish what data or credentials were accessed.
Response path 5: money, bank details or identity information may be at risk
Contact the financial institution immediately using an independently verified number. Ask about recalling or stopping the transaction and securing affected accounts. Notify the legitimate supplier or customer through a trusted channel. Preserve invoices, account details, message headers and the sequence of approvals; do not continue negotiating with the suspected sender.
Report cybercrime through ReportCyber or seek help from the 24/7 Australian Cyber Security Hotline on 1300 CYBER1 (1300 292 371). ASD also directs people whose identity information is at risk towards relevant support services, including IDCARE (ASD's ACSC hacking recovery guidance). Call 000 if there is an immediate threat to life or safety.
Assess privacy and notification obligations—do not guess
Determine what information and people may be affected, who may have accessed it, whether access was prevented or remediated and what harm could result. Preserve the basis for the decision.
Not every phishing event is an eligible data breach. For entities covered by the Notifiable Data Breaches scheme, however, reasonable grounds to suspect a serious breach trigger an assessment obligation. The OAIC says the entity must take all reasonable steps to complete that assessment within 30 calendar days and should treat that period as a maximum, not a waiting period (OAIC data-breach preparation and response guide). Obtain appropriate legal or privacy advice when the facts or obligations are unclear.
Run a 20-minute rehearsal
Use a fictional supplier email requesting an urgent bank-detail change. Ask the team:
- How does the recipient report it?
- Who independently verifies the request?
- Who checks accounts, sessions and mail rules?
- Who calls the bank and supplier if payment was made?
- Where is evidence recorded?
- Who assesses customers, contracts and privacy obligations?
- What continues if email is temporarily unavailable?
Record owners and gaps, then repeat the exercise after changes. This article supports the broader Australian SME cybersecurity baseline. For a scoped review of account, email and incident-response controls, see Ozlin Info's cybersecurity uplift service or contact Ozlin Info.
General-information disclaimer
This article provides general information only. It is not legal, privacy, insurance, financial, forensic or incident-response advice. Do not delay urgent assistance to follow a generic checklist. The appropriate actions depend on the message, device, accounts, data, contracts and active threat.
AI-assistance disclosure
AI tools assisted with outlining and copyediting this draft. A human reviewer must verify every factual claim, link, response step and publication decision before release. No claim is made that following this playbook will prevent or fully contain an incident.
Primary sources checked
- ASD's ACSC — Detecting socially engineered messages
- ASD's ACSC — Protecting against business email compromise
- ASD's ACSC — Recover from business email compromise
- ASD's ACSC — Report and recover from hacking
- ASD's ACSC — ReportCyber
- OAIC — Data breach preparation and response
Source access date: 28 August 2026.