ICT Continuity and Cyber Incident Response Plan Template for Australian General Practices

What's in this template?

This template is an ICT continuity, protection and recovery plan with the cyber security incident response plan built into it, plus the four records that evidence it: the backup log, the restore test record, the cyber incident record and the plan test record. It is written against criterion F8.A of the RACGP Standards for general practices (6th edition), published 26 August 2026, and against the 5th edition indicator it expands.

The RACGP's official mapping document classifies F8.A as Expanded from 5th edition indicator C6.4D. That matters for timing: C6.4D's mandatory elements today are a server backup log, up-to-date antivirus and firewalls, a tested business continuity plan for information recovery, and offsite backups. Those are exactly what this document holds, so it is assessable now, not only when the 6th edition takes effect.

The Word document contains eighteen numbered sections and four appendices, in Calibri, with placeholders highlighted and grey italic guidance notes to delete before you publish the plan. A cover block, a "How to use this plan" box and a version table come before section 1.

1. Purpose: quotes F8.A and the C6.4D indicator it expands, sets out why the plan matters, and names its evidence: the backup log, the restore test record and the incident record.
2. Scope: a table of the systems covered that the practice completes, and what is out of scope with the document that owns it.
3. How this plan relates to the security policy, the data breach plan and the continuity plan: the four-way boundary table, the ransomware walk-through, and a note on the My Health Record procedure.
4. Roles, accountability and the contact directory: the ICT security lead, the digital governance lead, the practice principal, the practice manager, the contracted ICT provider and every team member, plus a contact directory table.
5. Critical systems and recovery priorities: each system with the information held, a recovery priority, a maximum tolerable outage the practice sets, the recovery method and the paper workaround reference.
6. Protection, the standing controls this plan relies on: a table mapping each of the RACGP's Table 6 protective components to the control and where it is documented.
7. Backup: what is backed up, frequency, location, vendor-hosted clinical systems, and the backup log itself, including same-day escalation of a failed or missed backup.
8. Restore testing: the interval the practice sets, what a real test is, who runs it, how the result is recorded, and the full-system restore test at a longer interval.
9. Cyber security incident response plan: what counts as an incident, three severity levels, the first hour checklist, the five phases, the ransomware specifics, and evidence preservation.
10. Reporting and notification: a table of who is told, by whom, when and under which document.
11. Informing patients: how the practice tells them, including channels, content, the reception script and a log of notifications sent.
12. ICT recovery and return to normal: restore order, integrity checks, re-entering paper records, credential resets and the principal's declaration that normal operations have resumed.
13. Continuity during an ICT outage: a cross-reference to the Business Continuity Plan under F2.A, with the two plans tested together.
14. Testing this plan: a tabletop exercise at least annually using one of four scenarios, plus the restore tests and how a real incident counts.
15. Training and awareness: induction on the plan, annual cyber safety training, and the training register.
16. Review: annually and after defined triggers, inside the F1.D two-year maximum.
17. Roles and responsibilities: a table.
18. Related documents: the documents this plan points to.

Appendix A, the backup log. A landscape table with columns for date, system, backup type, destination, run by, result, verified by, date verified, notes and follow-up. Three worked rows ship filled in: a successful nightly clinical system backup to cloud, a partial backup where the document store was skipped and re-run, and a failed backup escalated to the provider the same morning. Blank rows follow.

Appendix B, the restore test record. Date, backup tested, what was restored, restored by, time to restore, opened and read, result, issues found, action and owner. One worked row, then blank rows.

Appendix C, the cyber incident record and first hour checklist. The checklist as tick boxes, then the incident record covering detection, systems affected, severity, containment actions with times, provider engagement, insurer notification, evidence preservation, authorities notified, patients informed, recovery completion and closure.

Appendix D, the plan test record. Date, type, scenario, participants, what worked, what failed, actions, owner, due and closed.

Editable placeholder fields

{{ }}Practice name{{practice_name}}, {{ }}ABN{{abn}}, {{ }}Practice address{{practice_address}}, {{ }}ICT security lead{{ict_security_lead}}, {{ }}Digital governance lead{{digital_governance_lead}}, {{ }}Practice principal name{{practice_principal_name}}, {{ }}Practice manager{{practice_manager}}, {{ }}ICT provider name{{ict_provider_name}}, {{ }}ICT provider phone{{ict_provider_phone}}, {{ }}ICT provider after hours{{ict_provider_after_hours}}, {{ }}Clinical software{{clinical_software}}, {{ }}Clinical software support{{clinical_software_support}}, {{ }}Practice management software{{practice_management_software}}, {{ }}Backup method{{backup_method}}, {{ }}Backup frequency{{backup_frequency}}, {{ }}Backup location{{backup_location}}, {{ }}Backup retention{{backup_retention}}, {{ }}Backup log location{{backup_log_location}}, {{ }}Backup log reviewer{{backup_log_reviewer}}, {{ }}Backup log review frequency{{backup_log_review_frequency}}, {{ }}Restore test frequency{{restore_test_frequency}}, {{ }}Full restore test frequency{{full_restore_test_frequency}}, {{ }}Max tolerable outage{{max_tolerable_outage}}, {{ }}Maintenance window{{maintenance_window}}, {{ }}Cyber insurer{{cyber_insurer}}, {{ }}Cyber insurer policy number{{cyber_insurer_policy_number}}, {{ }}Cyber insurer hotline{{cyber_insurer_hotline}}, {{ }}Indemnity insurer{{indemnity_insurer}}, {{ }}Plan test frequency{{plan_test_frequency}}, {{ }}Approved by{{approved_by}}, {{ }}Effective date{{effective_date}}, {{ }}Next review date{{next_review_date}}.

Four documents, one ransomware event

The test is short: the security policy prevents, this plan protects and recovers the information and responds to the incident, the data breach plan decides and notifies under the Privacy Act, and the continuity plan keeps the doors open.

One ransomware event runs through all four. The security policy's controls are what failed. This plan holds the first-hour actions, the isolation, the ICT provider call and the restore from backup. The data breach plan is opened the moment patient information may have been accessed, and its 30-day assessment clock starts. The business continuity plan's paper-based clinical workaround is what the clinicians work from until this plan's recovery section restores the system.

Where the practice is registered with My Health Record, the My Health Record Data Breach Notification Procedure runs in parallel. And for a physical emergency rather than a systems failure, the Emergency Response Plan sits in front of the continuity plan.

What RACGP criterion F8.A actually requires

The criterion sits in criteria set F8, Information security, in the Foundations of general practice standard. It reads:

F8.A The practice has an information and communication technology (ICT) continuity, protection, and recovery plan.

The practice:

• maintains, documents, and regularly tests an ICT continuity, protection, and recovery plan that includes a cyber security incident response plan
• has a backup log operated by the practice or contracted provider
• maintains up-to-date antivirus protection and hardware/software firewalls
• has secure retention and backup of information in offsite or cloud storage locations and the ability to restore information from chosen backup locations
• has procedures to inform patients of any instance where there has been a data breach affecting their personal information.

The consumer expectation statement for F8 reads: "I expect that my information is securely managed to protect my privacy." The guidance explains that planning for ICT continuity, information protection and recovery allows the practice to respond quickly to disruptions such as cyberattacks, hardware failures, and natural disasters. It also directs practices to know their legal obligations in the event of a cyber security incident and who to contact in an emergency, naming the Australian Signals Directorate (whose ReportCyber service and 1300 CYBER1 hotline sit at the top of the template's contact directory), police (state and federal) and the Department of Home Affairs.

The 5th edition indicator it expands

The 5th edition indicator behind F8.A sits in criterion C6.4 and reads:

C6.4 D Our practice has a business continuity and information recovery plan.

You must: operate a server backup log; maintain up-to-date antivirus protection and hardware/software firewalls; maintain and test a business continuity plan for information recovery; maintain a privacy policy; store backups offsite in a secure location. You could: maintain a policy for the management of patient health information; undertake regular privacy training.

Four of the five "must" items are the same things F8.A's sub-criteria name: the backup log, the antivirus and firewalls, the tested plan for information recovery, and the offsite backups. The 5th edition guidance says that if the practice uses computers to store patient health information, it must have a business continuity plan to protect information in the event of an adverse incident, such as a system crash or power failure, and that the plan needs to include the processes by which all critical information relating to the practice's operations (such as appointments, billing and patient health information) will be frequently backed up; a schedule of regular tests so that backups are being correctly created and can be accessed and read as expected; details of the secure offsite location where the backup information is stored; and standard letters of agreement that external IT providers sign to indicate their commitment.

What the guidance says the plan should contain

The F8 guidance includes Table 6, "What to include in the practice's ICT continuity, protection, and recovery plan". Its components are:

Cyber security incident response plan. How the practice will respond to and manage a data breach, through five stages: Detection and analysis; Containment and eradication; Recovery; Communication to patients/service users; Post-incident analysis.

Daily backup procedures. Daily or more frequent backups of critical operational data, for example appointments, billing and patient health information, ideally automated.

Backup testing schedule. Regular tests to confirm that backups are correctly created, accessible and readable.

Secure offsite/cloud backup. With verified ability to restore data.

Third party provider agreements. Standard letters of agreement signed by ICT providers that clarify their security obligations.

Malicious software protection. Active and updated antivirus and malware protection on all systems.

Email security. Scanning incoming emails and attachments.

Automatic updates. Antivirus signatures and software patches.

Staff training. Cyber safety, malware prevention, incident reporting.

Software updates and maintenance. Preferably run outside practice hours.

Remote access. Documented policies where remote access is allowed.

Table 6 is guidance. In the 6th edition, guidance written as "could" is a suggestion, not a requirement; only the sub-criteria bind. The RACGP's Information security in general practice guide is the reference the guidance points to for remote access. The guidance also says to store health information and other data, including backups, in Australia wherever possible, and that if the practice stores data outside Australia, its privacy policy will include relevant details and the practice informs patients that their health information is stored overseas.

The word "tests" is doing the work

F8.A's first sub-criterion requires the practice to maintain, document and regularly test the plan, and the fourth requires the ability to restore, not merely to copy. F2.A separately requires a tested response plan for disruption to the continuity of services, and its guidance gives "running mock scenarios (for example, ICT outages, pandemics)" and "testing ICT resilience (for example, simulating cyberattacks or access issues)" as examples of testing. The backup log and the restore test record are the evidence a surveyor can read. A "backup completed" message is not a restore test: a real test restores records, opens them and reads them.

Where accreditation actually stands

Practices are still accredited against the 5th edition. The Australian Commission on Safety and Quality in Health Care says accreditation "currently uses the 5th edition" and that transition arrangements under the National General Practice Accreditation Scheme will come "in due course". No date has been published, and we will not guess one. The practical consequence is that this document is assessable today: a surveyor asking for your "server backup log" under C6.4D is asking for Appendix A, and a surveyor asking for your tested plan for information recovery is asking for the plan itself with the restore test record behind it.

How to customise this template

1. Download the Word document and replace the highlighted placeholders, then delete the grey italic guidance notes.
2. Name the ICT security lead, and the digital governance lead if the security lead is an external provider.
3. Complete the systems table in section 2 and the recovery priorities in section 5, with the clinical information system and the appointment book first.
4. Confirm what the backup actually is with the ICT provider or vendor: method, frequency, location, retention, and whether it is in Australia. Get the letter of agreement signed.
5. Start the backup log this week and set the review interval.
6. Schedule the first restore test and record it in Appendix B.
7. Book the tabletop exercise with the Business Continuity Plan and record it in Appendix D.
8. Set the review date.

Related templates and tools

• Computer and Information Security Policy: owns the standing controls this plan relies on, and the named security lead under F8.B.
• Data Breach Response Plan: owns the Privacy Act assessment and notification decision this plan hands over to.
• Business Continuity Plan: owns the clinical paper workaround and the broader disruption response under F2.A.
• Emergency Response Plan: sits in front of the continuity plan for a physical emergency.
• My Health Record Data Breach Notification Procedure: runs in parallel where the practice is registered with My Health Record.
• Privacy Policy: must state where data is stored, including overseas storage.
• Practice Risk Management Policy and Risk Register: receives the lessons from failed tests and real incidents.
• Digital Health Technology Governance Policy: governs which digital health technologies the practice adopts under F10.A; each one becomes a row in this plan's section 2 systems table.
• Data Retention and Destruction Policy: how long records are kept and how they are destroyed; the backup retention set in section 7 must not contradict it.
• Policy and Document Control Procedure: the version control F1.D requires.
• What a notifiable data breach is: the threshold the Data Breach Response Plan applies.
• Ransomware payment reporting: the Cyber Security Act obligation section 9 of this plan flags.
• The Essential Eight: the Australian Signals Directorate's baseline mitigation strategies, for practices that want a benchmark beyond the RACGP's Table 6 controls.
• The 72-hour ransomware reporting deadline: what the clock looks like in practice for healthcare.
• Cybersecurity compliance checklist for GP practices: a wider walk-through of the security obligations.
• 6th edition contents map: where F8 sits in the new Standards.
• Notifiable Data Breach assessment tool: work through the assessment when the data breach plan is opened.
• RACGP Accreditation Readiness Quiz: check where your evidence stands before a survey.
• The RACGP's Information security in general practice guide: the RACGP's own reference on backup roles, remote access and responding to attacks.

Frequently asked questions

Is an ICT continuity and recovery plan required for RACGP accreditation right now?

Yes. Practices are accredited against the 5th edition, and indicator C6.4D already requires a tested business continuity plan for information recovery, a server backup log, up-to-date antivirus and firewalls, and offsite backups. The 6th edition's F8.A expands the same territory. A surveyor asking for your "business continuity and information recovery plan" and your "server backup log" is asking for this document and Appendix A.

What is RACGP criterion F8.A?

It is the 6th edition criterion requiring the practice to maintain, document and regularly test an ICT continuity, protection and recovery plan that includes a cyber security incident response plan, operate a backup log, keep antivirus and firewalls up to date, hold secure offsite or cloud backups with the ability to restore, and have procedures to inform patients of a data breach affecting their personal information.

How is this different from our Computer and Information Security Policy?

The security policy prevents. It owns the standing controls that run every day: access control, passwords, malware protection, device and remote-access rules, and the named security lead. This plan protects and recovers. It holds the backup schedule, the restore tests and the first hours of an incident. One ransomware event runs through both: the policy's controls are what failed, and this plan is what you open next.

How is this different from our Data Breach Response Plan?

The data breach plan decides and notifies under the Privacy Act. Once patient information may have been accessed, it runs the assessment, applies the serious-harm test and makes the notification decisions. This plan runs the technical response: detection, containment, eradication, recovery and restore. Section 11 of this template handles how patients are told once the data breach plan has decided they must be.

What does a backup log actually have to show?

One entry per backup run, with the date, system, backup type, destination, who ran it, the result, who verified it and when, and any follow-up. Automated reports count if they are retained and checked. The log is reviewed at a set interval, and a failed or missed backup is escalated the same day. Appendix A ships with three worked rows showing what a good, a partial and a failed entry look like.

How often do we have to test our backups and this plan?

The Standards say "regularly" without fixing a number, so the practice sets the interval. Quarterly restore testing is common. A real test restores records, opens them and reads them, and the result is recorded with the time to restore. The plan itself is tested through a tabletop exercise at least annually, using one of the four scenarios in section 14, and a full-system restore test runs at a longer interval.

Our clinical software is cloud-hosted. Do we still need this?

Yes. Section 7 covers vendor-hosted clinical systems directly: what the vendor backs up, what the practice still exports, and the letter of agreement. The backup log still runs, and the restore test still has to prove the practice can get its information back. A vendor's uptime promise is not a restore test, and the surveyor will still ask for the evidence.

Do we have to tell patients about a cyber incident?

Yes, where the incident is a data breach affecting their personal information. F8.A's fifth sub-criterion requires procedures for informing patients. Whether a breach is notifiable under the Privacy Act is decided in the Data Breach Response Plan, including the 30-day assessment and notification to the OAIC and affected individuals as soon as practicable. Section 11 of this template is the how: the channels, the content and the reception script.