Incident Response Plan for Tax Practices

An incident response plan assigns who detects a cyber incident, contains it and approves safe recovery. For a tax practice, it must cover client records, staff accounts and interrupted tax work. Use the blank plan and fictional example below to prepare yours.

What an Incident Response Plan Does

The plan gives staff an agreed sequence for handling suspected compromise before the practice knows the full damage. Staff report the event, the response lead assesses it and the IT provider investigates and restores services.

Classify what the incident threatens. Confidentiality concerns who can see client information. Integrity concerns whether you can trust tax calculations, documents and recorded instructions. Availability concerns whether staff can access the services they need. A service outage can interrupt work without establishing a privacy breach.

Your response policy gives people authority to act. The plan names the people and their deputies. Technical playbooks describe the actions for a compromised device, account or service. Your continuity arrangements decide what work can continue safely while recovery proceeds.

If personal information could have been accessed, disclosed or lost, activate the data breach response plan. Keep that assessment running alongside technical recovery.

Build an Editable Incident Response Plan

Build your incident response plan around the services your practice actually uses and the people available to respond. Before drafting, obtain the IT provider’s incident contact and agree who can authorise account suspension, device isolation and restoration.

1. List where client information sits. Include staff devices, email, document storage, backups, your tax software and ATO access. Record which services depend on the same sign-in account.
2. Assign a response lead and deputy. Agree how staff reach them outside ordinary hours and when the deputy takes over.
3. Agree the IT handoff. Name who accepts the incident, how they confirm receipt and who takes over if the usual provider is unavailable.
4. Attach technical playbooks. Have the provider specify safe isolation, log collection, account recovery and backup restoration for your actual services.
5. Set recovery criteria. Choose the evidence needed before staff rely on restored records or resume lodgement work.
6. Exercise the plan. Use a fictional event to expose missed handoffs, repair them and obtain principal approval of the working version.

Copy-Ready Blank Plan

Copy this plan into a document and complete the empty cells. Add rows for each service and contact. Keep an offline copy available to the response lead and deputy without including passwords or client records.

Plan field	Practice entry
Practice and plan version
Policy authorising the response
Plan owner, principal approver and approval date
Lead, deputy and deputy activation condition
IT provider, after-hours contact and backup provider
Insurer incident contact and policy notification requirements
Offline contact-list location and person maintaining it
Alternate communication channel and clean device to use
Activation triggers and escalation levels
Authority to isolate devices or suspend accounts
Authority to approve reimaging or restoration after evidence capture
Location of attached technical playbooks
Evidence-log owner and restricted storage location
ATO, privacy and other reporting decision owner
Client and staff communication approver
Recovery priorities, acceptance criteria and resumption approver
Review owner, review interval and next exercise

Use the service register to decide what the IT provider must protect and restore first.

Service or device	Client information or work held	Sign-in and other dependencies	Provider and incident contact	Backup location and restore responsibility	Recovery priority

Open an incident record when staff report a suspected event. Record known facts separately from assumptions and update the record as the investigation changes.

Incident-record field	Entry during response
Incident identifier, detection time and reporter
Initial signs, affected device, users and services
Severity, business impact and lead/deputy activation
Containment decision, authority, action and time
Evidence reference, source, collector, collection time and transfers
Known spread, client records affected and unresolved questions
Reporting branch, decision reason, owner, deadline and receipt
Staff/client message, approver and communication record
Remediation and backup assessment evidence
Record reconciliation and controlled work-check result
Resumption scope, approver, time and monitoring
Corrective action, owner, completion target and retest result

These tables are the editable incident response plan template. To make a Word document, copy them into Word, format the tables and save as a .docx file. To make a printable PDF, use the document’s print or export function and select PDF. Inspect page breaks and confirm every field is visible before circulating it.

Classify and Escalate Critical Incidents

Classify a critical incident by its effect on client information, accounting records and the practice’s ability to work safely. Use consequences you can observe, with escalation rules the principal and provider have agreed.

Observation	Initial escalation	Work decision and recovery priority
One suspicious device, with scope still unknown	Notify the lead and provider immediately	Isolate the device under the playbook and assess related accounts
Stolen records or suspected access to client information	Activate principal or deputy and privacy lead	Protect affected accounts and establish which records were exposed
Unauthorised changes to returns, bank details or client instructions	Activate principal or deputy and provider	Stop reliance on affected work and reconcile changes against source material
Critical tax software or sign-in service unavailable	Activate deputy if the principal cannot be reached	Use alternate communications and restore verified access before urgent tax work
Several services affected or recovery exceeds available skills	Escalate to specialist support and insurer	Preserve evidence and prioritise services needed for safe recovery

Record staff affected, work paused, deadlines at risk and recovery resources needed. Reassess severity when new facts arrive. Do not copy enterprise percentage or financial thresholds into a small practice’s plan without an agreed reason.

The principal’s absence must not leave containment waiting. Give the deputy written authority and a reliable alternate contact method. Keep physical-safety emergencies in the practice’s emergency arrangements. An immediate threat to life requires emergency services on 000.

Follow the Response Through Recovery

Follow the response from the first report to a documented decision that tax work can safely resume. The lead coordinates business decisions while the IT provider owns technical investigation and recovery.

1. Detect and log. Staff stop using the suspect service, record the signs and contact the lead through the agreed channel. The lead opens the incident record.
2. Triage. The provider identifies affected accounts, devices and services. The lead records client work at risk and escalates beyond the original device when shared sign-in or storage is involved.
3. Activate the team. The lead confirms the deputy, provider and communication owner. Obtain an explicit provider acknowledgement so a sent message is not mistaken for an accepted handoff.
4. Contain safely. Staff follow their authorised device-isolation playbook. The provider suspends compromised accounts or ends sessions where appropriate. Record the action, time and person authorising it.
5. Preserve evidence. The provider captures relevant security, sign-in and application logs before consequential reimaging or restoration. Restrict access to the evidence and record who collects or transfers it.
6. Establish scope and record integrity. Identify affected users and client records. Compare suspicious changes with approved instructions, source documents and earlier reliable records.
7. Remediate. The provider removes the cause, repairs affected systems and restores account security. The lead confirms which unresolved questions require continued work restrictions or reporting.
8. Restore and verify. The provider assesses the restore source and demonstrates clean access. Staff reconcile restored records, including changes made after the backup.
9. Approve resumption and review. Record the principal’s approval or authorised deputy approval, permitted work and monitoring. Assign each corrective action to an owner.

For ATO access or your tax software, pause suspect lodgements and changes until you can trust the affected work. Identify unauthorised client-detail changes, refund instructions and transactions that require reconciliation. Use the ATO’s data breach guidance for tax professionals when taxpayer information or agent access is compromised.

A login that works is only one recovery check. Require evidence that the cause is addressed, systems are clean and permissions are correct. Staff must reconcile records and complete a controlled tax-work task before returning the restored service to ordinary use.

For example, compare a restored working paper with its source documents and confirm its totals using approved staff access. Record the result without sending a live lodgement as an experiment. If the totals differ, hold the affected work and have the provider and responsible practitioner resolve the difference.

Ransomware Containment and Recovery

A ransomware response must assess both encrypted files and possible theft of information. Access restored through decryption does not establish that the attacker has left or that copied client information is safe.

Follow the agreed isolation playbook and call the IT provider through a clean channel. Preserve the alert, ransom message and affected-device details without interacting with the attacker. Keep a record of containment actions and notify the insurer under the policy’s requirements.

ASD’s ransomware recovery steps advise recording attack details, turning off infected devices and protecting connected devices. Have the provider establish the appropriate shutdown and isolation sequence in advance. Avoid delaying containment to collect every artefact.

The provider assesses encryption scope, attacker access and backups before restoring. Recover from an assessed clean source, remediate affected credentials and verify restored records against source material. Keep possible exfiltration under a separate privacy assessment even when every file opens again.

If backups contain malware or their integrity is uncertain, keep them out of the recovery path until the provider resolves that risk. A recovered document can still contain unauthorised changes. Staff must check calculations, payment instructions and client records before using them.

ASD advises against paying a ransom. Payment gives no guarantee of recovery or protection against disclosure. If a payment occurs, the reporting branch described below still applies independently of the recovery result.

Use ASD and NIST Guidance

Use Australian Signals Directorate (ASD) guidance to assign practical response authority, then use NIST to organise the records you maintain. The Australian Cyber Security Centre (ACSC) is part of ASD.

The ASD incident response planning guidance includes roles, activation and readiness material. A small practice can combine coordination roles in its principal and deputy. It still needs a technical provider, a confirmed handoff and a decision record.

NIST SP 800-61 Rev. 3 is Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. The function names help organise your records.

NIST CSF 2.0 function	Practice records to keep
Govern	Approved authority, response roles and reporting ownership
Identify	Service register, dependencies and client-work priorities
Protect	Recovery preparations, offline contacts and backup arrangements
Detect	Initial alerts, staff reports and triage records
Respond	Containment decisions, investigation evidence and communications
Recover	Clean restoration evidence, record reconciliation and resumption approval

Feed lessons from incidents and exercises back into those records. Adapting either framework does not establish legal compliance or certification. Broader preparation belongs in the cyber security guide for accountants.

Australian Reporting and Support Branches

Keep each support request in the incident record. Record recommended reporting and legal notification decisions separately.

• Report suspected cybercrime through ReportCyber. ASD’s ACSC support line is 1300 292 371. A support call does not replace a required regulatory report.
• Contact the Australian Taxation Office (ATO) promptly when taxpayer information or tax access is compromised. Its Client Identity Support Centre is 1800 467 033. Record affected accounts and any protective restrictions before resuming work.
• Activate the privacy branch if personal information could be affected. The Office of the Australian Information Commissioner (OAIC) administers the Notifiable Data Breaches scheme. TFN recipients can be covered for TFN information even where the general small-business exemption applies. Use the breach plan for eligibility assessment and notice decisions.
• A reporting business entity must report a ransomware or cyber extortion payment within 72 hours of payment or awareness of payment on its behalf. The business category includes Australian businesses with previous-financial-year turnover of at least $3 million. Responsible entities for relevant critical infrastructure assets are also covered. Use the official payment-reporting form and record the receipt.
• Review insurer, software-provider and other contractual notice requirements. If the practice is itself a regulated critical-infrastructure entity, assess its separate incident-reporting duties under that regime.

A demand alone is different from a payment-reporting trigger. Record the decision owner early, including where an insurer or other party could make a payment on the practice’s behalf.

Worked Incident Response Plan and Printable Versions

This fictional incident response plan example shows decisions and handoffs in a small Australian practice. It describes invented facts, not an incident at a real practice.

Plan or incident field	Completed fictional example
Scope and dependency	Staff laptops, shared client documents and tax software using the same staff identity service
Authority	Principal-approved device/account containment, with deputy authority during absence
Lead and deputy	Practice manager leads. Senior practitioner is deputy. Principal approves resumption
Technical handoff	Contracted IT provider accepts a telephone handoff and records its incident reference
Alternate channel	Telephone contact from a separate clean device. Restricted offline contact sheet
Trigger and severity	Staff laptop raises a malware alert while a tax session is open. Scope unknown, tax work paused
First action	Staff stops work and isolates the laptop under the approved playbook. Provider ends affected sessions
Evidence record	Alert photograph, device identifier, sign-in logs and tax-software activity logs preserved by provider
Investigation finding	Provider attributes the alert to malicious software and checks other devices, shared access and file changes
Client-record check	Practitioner compares affected working papers and client-detail changes with source records
Recovery priority	Clean staff sign-in first, then verified document access, then tax work
Remediation	Provider preserves evidence, rebuilds the affected device and replaces affected credentials
Restore assessment	Provider checks the selected backup and restored service. Practitioner accounts for work after the backup
Resumption check	A restored working paper agrees with source documents. Approved user access works and monitoring is active
Approval	Principal records the checked services and authorises a limited return to work before ordinary use
Review owner	Practice manager assigns an offline-contact correction to the deputy and records a retest

Compare two possible investigation outcomes. In the first, the available logs show the blocked attempt and establish no unauthorised client-record access or changes. The lead records that finding and its evidence. Any uncertainty about log coverage remains an open assessment item.

In the second, the provider finds an unauthorised sign-in and a client-document download. The lead activates the breach plan, identifies affected records and contacts the ATO where taxpayer information is involved. Clean technical recovery proceeds while the privacy lead assesses reporting and client notices.

For a mailbox compromise with changed payment instructions, follow the business email compromise checks before relying on the instructions. That financial check remains necessary even after access is restored.

Print the completed example beside your blank plan. Keep the example labelled fictional and enter your practice’s own contacts, services and authority in the blank version. Use the same Word-save and print-to-PDF steps for both.

Exercise the Plan and Close Gaps

Exercise the incident response plan with the principal absent and primary email unavailable. Use a fictional service disruption, with no real account suspension, client messages or provider reports.

Allow 30 minutes for decisions, then a debrief. Give participants only the facts they would have at each stage. The exercise facilitator records what participants decide and what evidence they produce.

Elapsed time	Injected fictional fact	Expected decision	Evidence produced
Start	Staff cannot access email or tax software. Principal cannot be reached	Deputy activates, opens the record and switches to the approved alternate channel	Activation entry and staff contact record
After 5 minutes	Provider’s ordinary inbox is unavailable	Use the offline telephone contact and obtain a simulated accepted handoff	Provider contact reference and named technical owner
After 10 minutes	Client work is approaching a deadline, but document integrity is unknown	Pause affected work and rank clean sign-in and verified document access first	Work-hold list and recovery priorities
After 20 minutes	Provider supplies a simulated clean-restoration report	Reconcile a fictional working paper and record deputy resumption authority	Comparison result and limited resumption decision
Debrief	Offline contact sheet has an obsolete after-hours number	Assign replacement and repeat the failed handoff	Corrective owner, completion target and retest result

A missed acknowledgement is a failed handoff even if someone sends the message. A functioning service fails the recovery gate if participants cannot explain how they verified its records. Record those gaps as actions with owners, rather than marking the exercise complete because the team finished talking.

Use the breach plan for a detailed client-exposure exercise. Approve your incident response plan when the deputy can activate it, the provider handoff works and staff can demonstrate the recovery checks.