Incident Response Plan

1. Purpose and scope

This plan governs how NT Development Group Pty Ltd ("NTDG", "we") detects, records, responds to, and reports information security incidents affecting the AccountsAndGo CDR data environment — the manageyourtax-prod Google Cloud project (Cloud Run, Firestore, Cloud Storage; australia-southeast1) and any system, account, or person that can access CDR data or data derived from it. It applies to all personnel and contractors.

2. Definitions

• Security incident: any actual or suspected event that compromises, or could compromise, the confidentiality, integrity, or availability of CDR data, Service Data, personal information, or the CDR data environment.
• Eligible data breach: as defined under Part IIIC of the Privacy Act 1988 — unauthorised access to, disclosure of, or loss of personal information likely to result in serious harm.
• CDR data: as defined in the CDR Rules, including Service Data received from the Principal and data derived from it.

3. Roles and responsibilities

• Incident Response Lead (Compliance): coordinates response, decides severity, owns regulator/Principal notifications, maintains the incident record.
• Technical Lead (engineering on-call): contains and remediates; preserves evidence and logs.
• Directors: notified for High/Critical incidents; approve external notifications and any public statement.
• All personnel must report a suspected incident immediately (see §4).

4. Detection and reporting

Incidents may surface via Google Cloud Logging/alerts, the application audit trail, customer or Principal reports, or staff observation. Any person who suspects an incident must report it immediately to the Incident Response Lead (and, out of hours, the engineering on-call). No suspected incident is to be investigated informally or left unrecorded.

5. Severity classification

• Critical: confirmed or likely unauthorised access to, or loss of, CDR data/personal information; sustained outage of the CDR environment.
• High: credible threat to CDR data; compromise of an admin account or secret; failed control with exposure.
• Medium: contained event with no confirmed data exposure.
• Low: policy or hygiene issue with no exposure.

6. Response stages

1. Identify & record — open an incident record (time, reporter, systems, data types involved). Assign severity.
2. Contain — isolate affected systems/accounts; rotate exposed credentials/secrets (Google Secret Manager); revoke sessions; preserve logs and evidence.
3. Assess — determine scope: which CDR data/personal information, how many consumers, root cause.
4. Notify — execute the §7 obligations.
5. Eradicate & recover — remove the cause; restore from backups; verify integrity before returning to service.
6. Post-incident review — within 10 business days: root-cause analysis, control gaps, remediation actions with owners and dates; reported to senior management/Directors.

7. Notification obligations

• Principal (Activate Wych): notify immediately on becoming aware of any security incident resulting in (or potentially resulting in) a notifiable data breach involving CDR or derived data; and within 48 hours of any breach of the Act, CDR Rules or Privacy Act, or any consumer complaint. The Principal coordinates CDR-specific notifications to the ACCC/OAIC as the accredited data recipient.
• Australian Cyber Security Centre (ACSC): notify as soon as practicable and no later than 30 days after we become aware (Schedule 2 cl 1.7).
• OAIC & affected individuals: where the incident is an eligible data breach, assess and notify under Part IIIC of the Privacy Act, in coordination with the Principal.
• All notification decisions, timings, and content are recorded in the incident record.

8. Continuity and recovery

Recovery relies on Google Cloud multi-zone redundancy and Firestore backups/point-in-time recovery. Restoration is verified for data integrity and per-business isolation before service resumes.

9. Testing and maintenance

This plan is reviewed and tested (tabletop or live exercise) at least annually, and as soon as practicable after a material change to threats or to the boundaries of the CDR data environment. Test outcomes and updates are recorded.

10. Records

All incidents, decisions, and notifications are logged and retained for at least six years, consistent with CDR record-keeping obligations.

Contact