Tag: incident response

  • Phishing Response Playbook for Australian Small Businesses

    Phishing Response Playbook for Australian Small Businesses

    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:

    1. contact the internal response owner or provider;
    2. change the affected credential and any reused credential;
    3. sign out or revoke other sessions and tokens where the service supports it;
    4. verify recovery email addresses, phone numbers, MFA methods and delegated access;
    5. check for new mailbox forwarding rules, filters, application permissions and administrators;
    6. review available sign-in and audit logs; and
    7. 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

    Source access date: 28 August 2026.

  • Cybersecurity for Australian SMEs: 8 Practical Priorities for 2026

    Cybersecurity for Australian SMEs: 8 Practical Priorities for 2026

    Cybersecurity for a small business is not a shopping list of products. It is the ongoing work of deciding what matters, reducing likely paths to harm, noticing trouble and recovering without losing control of the business.

    That distinction matters. No product, consultant or checklist can make an organisation immune to cyber incidents. A useful baseline should instead lower risk, produce evidence that important safeguards work and give people a rehearsed way to respond.

    For Australian small businesses beginning this work, the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) recommends three immediate measures: turn on multi-factor authentication, update software and back up information. Its small-business guide then points organisations towards Maturity Level One of the Essential Eight after they have covered the basics (ASD's ACSC small-business guide). The eight priorities below turn that advice into a manageable business baseline.

    1. Identify the services and information that cannot be casually lost

    Start with business impact, not tools. List the systems that support quoting, invoicing, customer communication, delivery, payroll, your website and access to money. Record who owns each system, where its data is held, which supplier operates it and what the business would do if it were unavailable for a day or a week.

    Also identify sensitive information: customer records, identity documents, credentials, payment-related records, source code and confidential client material. This does not need to begin as a complex asset-management platform; a maintained register is more useful than an expensive dashboard nobody trusts.

    NIST's Cybersecurity Framework 2.0 is designed for organisations of any size and treats cybersecurity as a business-risk discipline. Its six concurrent functions are Govern, Identify, Protect, Detect, Respond and Recover (NIST CSF 2.0). That sequence is a useful test: if a proposal only talks about prevention, it is incomplete.

    2. Secure identities before adding more software

    Email, cloud administration, banking, accounting, domain registration, website administration and password-manager accounts deserve priority. Use a unique account for each person, remove access promptly when it is no longer required and keep routine work separate from privileged administration where practical.

    Enable MFA, beginning with accounts that can expose sensitive information or reset other accounts. A business password manager can help create and store unique credentials without relying on memory. ASD's 2025 small-business device and account guidance specifically includes MFA, password managers, backups and updates as practical steps (ASD's ACSC device and account guidance).

    MFA reduces risk; it does not make every sign-in safe. Staff should still reject unexpected approval prompts, never disclose one-time codes, and report a suspicious prompt quickly.

    3. Patch operating systems, applications and internet-facing services

    Turn on supported automatic updates where this fits the system, and maintain a process for software that requires testing or manual deployment. Include browsers, plugins, mobile devices, network equipment, website components and cloud integrations—not only desktop operating systems.

    For a more formal target, use the current Essential Eight maturity model and assess against its evidence requirements rather than copying an old patch timetable from a blog post. ASD notes that the model changes as malicious techniques change and encourages use of the latest version (Essential Eight maturity model FAQ). Unsupported systems should have an upgrade or retirement plan, with compensating controls assessed in the meantime.

    4. Make backups recoverable, not merely present

    Decide what must be backed up, how often, how long it must be retained and how quickly it must be restored. Protect backup administration separately from ordinary user accounts and design the backup location so a compromised user or device cannot silently alter every recovery copy.

    Most importantly, test restoration. ASD's technical example says restoration of systems, software and important data should be tested as part of recovery exercises, and unprivileged accounts should be prevented from modifying or deleting backups (ASD's ACSC regular-backup example). Record the result, the time taken and anything that was missing.

    5. Reduce unnecessary access and data exposure

    Give people and integrations only the access required for their role. Review shared accounts, former-worker access, public links, API keys, administrator memberships and third-party app permissions. Separate guest Wi-Fi and untrusted devices from business systems where the environment warrants it.

    Collect and retain only information the business can justify. Data minimisation is not a substitute for security, but less unnecessary data means less information available to expose. Map important data flows, including transfers to SaaS suppliers and contractors, and record contractual, regulatory and privacy obligations that affect them.

    6. Protect business processes from phishing and payment fraud

    Awareness training works best when paired with a process. Give workers a simple way to report suspicious messages and require independent verification for new bank details, unusual payments or requests to bypass approval. Use a known phone number or another separately verified channel—not contact details supplied in the message.

    ASD's business email compromise guidance recommends consistent verification for payment and sensitive-information requests and highlights unexpected bank-detail changes, urgency and requests to circumvent normal processes as warning signs (ASD's ACSC BEC guidance). See the related phishing response playbook for the immediate response steps.

    7. Monitor the small set of signals that matter

    Detection should match the systems identified as critical. Useful starting signals can include privileged sign-ins, new MFA methods, mailbox forwarding-rule changes, new administrators, unexpected exports, backup failures, website changes and security alerts from managed services.

    Someone must own the alerts, know the expected response time and be able to reach the relevant supplier. Retain logs for a period that supports investigation and contractual needs, while avoiding indefinite retention without a purpose. Test whether alerts are delivered and acted upon; a configured alert that nobody reads is not an operating control.

    8. Prepare, test and improve an incident plan

    A concise plan should name the incident lead, decision-makers, technical contacts, insurer or broker contact, legal/privacy support, bank contact and key suppliers. Include an offline copy. Define how staff will report concerns, how affected access may be contained, who preserves evidence, how essential work continues and who approves external communication.

    ASD says organisations should tailor, regularly test and review their cyber incident response plans (ASD's ACSC incident-response planning guidance). Notification duties depend on the organisation and the facts. For entities covered by the Notifiable Data Breaches scheme, the OAIC's current quick reference separates response into contain, assess, notify if required, and review (OAIC data-breach quick reference). Do not assume every security event is notifiable—or that no notification is required—without an appropriate assessment.

    A realistic first 90 days

    Days 1–30: name an owner; inventory critical services, data and suppliers; enable MFA on high-impact accounts; remove stale access; turn on supported updates; verify that backups are completing.

    Days 31–60: perform a restore test; review administrator access and email rules; establish payment-change verification; define the alert and escalation path; document important supplier contacts.

    Days 61–90: run a short incident exercise; record gaps and owners; compare current practices with the latest Essential Eight Maturity Level One requirements; set a funded improvement backlog based on risk.

    Progress should be evidenced by results: a successful restore, an access review, a resolved alert test and a timed incident exercise. A completed questionnaire alone does not prove that controls operate effectively.

    Cyber insurance may transfer some financial risk, subject to policy terms, exclusions and disclosure obligations. It does not replace prevention, detection, response or recovery work. Likewise, a security assessment should describe its scope and limitations; it should not promise that no vulnerability or incident will occur.

    For a scope-first review of accounts, website operations, backups and incident readiness, 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 or incident-response advice, and it is not a complete security standard. Appropriate controls and notification obligations depend on your systems, data, contracts, sector and circumstances. Obtain qualified advice for your organisation and seek urgent assistance when an incident may be active.

    AI-assistance disclosure

    AI tools assisted with outlining and copyediting this draft. A human reviewer must verify every factual claim, link, scope statement and publication decision before release. No client result or security guarantee is asserted.

    Primary sources checked

    Source access date: 28 August 2026.