Most incident response plans fail the same way. They are thorough, they live in a shared drive, and nobody opens them when something breaks because they are 40 pages long and written for an auditor rather than for the person staring at a wrong bank balance at 9 am.
A plan your team will use is short, specific, and rehearsed. It fits on two pages. It names people, not roles that could mean three different colleagues. And it assumes the person reading it is stressed and short on time, because they will be.
Here is how to build one for your Xero organisations.
Start With the Incidents You Will Actually Face
Do not plan for a Hollywood breach. Plan for the events that happen in real practices.
- A staff member bulk-deletes or overwrites transactions in a client organisation.
- A bad import or a connected app sync corrupts a chunk of data.
- A phishing attack compromises a Xero login and someone acts inside the org.
- A client disputes what the file looked like on a given date and you need to prove it.
- A subscription lapses or access is lost during a billing dispute.
Each of these has the same recovery need: get back to a known-good version of the organisation, quickly, without destroying the current state in the process. That shared need is what your plan is built around.
The Two-Page Structure
Keep it to five sections. Anything longer and it stops being a plan and becomes a document.
1. Who does what. Name a person and a backup person for each job. Who declares an incident. Who runs the restore. Who talks to the client. Who logs the timeline. If your practice is small, one person may hold several of these, and that is fine, as long as it is written down.
2. First fifteen minutes. The immediate steps before anyone touches data. Confirm what happened. Stop the bleeding, which usually means suspending the affected user's access or disconnecting a misbehaving app. Do not delete anything and do not attempt a fix in the live organisation yet. Note the time and what you observed.
3. Recover. The restore procedure, written as steps a colleague could follow without you. This is the heart of the plan, covered below.
4. Communicate. What you tell the client, when, and who signs off on the wording. A holding message early beats a perfect message late. If the incident involves exposure of personal data, note who checks the notification obligations, since those have legal timelines.
5. Review. A short debrief after every incident. What worked, what was slow, what to change. This is how the plan stays alive instead of rotting in a folder.
The Recovery Steps That Belong in Section 3
This is where an independent backup turns a crisis into a procedure. Written for the person who will run it:
- Identify the last good point. Check the audit trail to find when the bad change happened, then choose a backup snapshot from before it. WOW keeps daily snapshots, with retention up to 90 days if you have extended it, so you can look back past an issue that went unnoticed.
- Restore to a new organisation. Run the restore. WOW builds a brand-new Xero organisation and rebuilds the data into it. It does not touch the live org, so this step is safe even while you are still investigating.
- Verify the restored data. Open the new organisation and confirm the records you expected are there and correct. Check balances against a known reference point.
- Reconnect bank feeds. The restored organisation needs its bank feeds reconnected manually, because feed authorisations are tied to a specific org. Assign this explicitly so it does not fall through.
- Decide the cutover. Either move operations to the restored organisation, or pull specific corrected records back into the live one from the restored copy. For a single deleted invoice, you reference it from the restored org and re-enter it rather than restoring the whole org over the top.
- Log everything. Times, decisions, who did what. You will need this for the client, and possibly for a regulator.
Notice that none of these steps risk the live data, because the restore always lands in a separate organisation. That property is what lets a nervous colleague run the procedure without fear of making things worse.
Rehearse It Once, and It Becomes Real
A plan nobody has tested is a theory. Run a test restore on a non-critical organisation, follow your own section 3, and time it. You will find the gaps immediately: a step that assumes knowledge only you have, a login nobody can locate, a bank feed reconnection nobody thought about. Fix those now, on a calm day, not during an actual incident.
The test also gives you an honest recovery time. When a client asks how fast you could recover their file, "we tested it and it took us about two hours" is a very different answer from "we have backups."
Keep It Findable
The best plan is useless if it is buried. Put it somewhere your team already looks. Pin it. Print a copy. Make sure the person most likely to be first on the scene knows exactly where it is. An incident response plan is a fire extinguisher, and a fire extinguisher locked in a cupboard upstairs is not much help.
Build the Plan, Then Prove It
A recovery plan is only as good as the last time you tested it. The test is where "we have backups" becomes "we know exactly what to do."
Connect a Xero organisation to WOW Backup and Restore and run one test restore this week. Use it to write section 3 of your plan from real experience, not guesswork.