Vaxa Cyber Incident Response Plan

Purpose

Vaxa’s Cyber Incident Response Plan (CIRP) provides a structured approach to detecting, responding to, and recovering from cyber incidents.

The goal is to minimise damage, restore normal operations quickly, and prevent future incidents. Cyber-attacks can escalate rapidly, so a clear and coordinated response is critical.

Scope

This plan covers cyber and information security incidents that impact Vaxa’s IT systems, data, or digital assets. These incidents may include:

  • Data breaches (e.g. unauthorised access or data leaks)
  • Unauthorised system access (e.g. compromised accounts, privilege escalation)
  • Malware outbreaks (e.g. ransomware, viruses, spyware)
  • Phishing & social engineering attacks
  • Denial of Service (DoS) attacks

Technically speaking, cybersecurity incidents are a subset of Information Security incidents (for example, the loss of a physical document containing sensitive information would be an Information Security incident, but not a Cybersecurity incident). In practice, we treat these the same way so we can respond quickly and effectively without the overhead of maintaining many separate plans.

What’s not covered in this plan?

General IT issues don’t fall part of this plan unless they’re suspected to be caused by a cyber incident. This therefore excludes things like:

  • Hardware failures
  • Software bugs
  • Software updates
  • General system outages

If you’re experiencing one of these, you should use the usual process to report to the IT team who may enact the Disaster Recovery policy and plans as required.

Roles & Responsibilities

Everyone at Vaxa

All employees play a role in keeping Vaxa’s systems secure. As part of the team, you should:

  • Follow security policies when using company systems and handling data
  • Report any suspicious activity or potential incidents immediately
  • Complete cyber security training to stay aware of risks

Managers

Managers are responsible for ensuring their teams understand and follow security policies. Specifically, managers should:

  • Promote secure system use and data protection
  • Ensure employees know how to report incidents
  • Assist with investigations if required

Cyber Incident Response Team (CIRT)

The CIRT is responsible for managing incidents and coordinating response efforts. Their responsibilities include:

  • Assessing, containing, and investigating incidents
  • Coordinating with third-party IT providers when needed
  • Keeping senior management and stakeholders informed
  • Reviewing security measures to prevent future incidents

The CIRT structure will vary based on incident severity, but typically includes:

  • Response Controller (CTO) – Leads response efforts
  • IT Service Provider – Assists with containment and remediation
  • Legal & Compliance – Ensures regulatory reporting and legal steps are taken
  • Finance & Business Continuity – Assesses business impact

As Vaxa doesn’t engage a permanent IT Service Provider, the CTO will be responsible for coordinating with external IT providers if required.

CTO

Ownership of these plans and their review/update sits with the CTO. They are responsible for ensuring the plans are up to date. Particular importance is placed on the responsibility of keeping contact details up to date.

Cyber Incident Response Stages

1. Preparation

Proactive preparation reduces risk and ensures Vaxa is ready to respond effectively. This includes:

  • Regular security assessments and penetration testing
  • Keeping security policies and recovery plans up to date
  • Monitoring cyber threat intelligence (e.g. reports from the Australian Cyber Security Centre)
  • Employee training to identify and report threats

2. Detection & Reporting

Actual or suspected incidents must be identified quickly to reduce potential damage.

If you suspect a cyber incident:

  • Report it immediately to your manager or IT team
  • Provide as much detail as possible, such as:
    • What happened?
    • What systems/data were affected?
    • When was it detected?
    • Any visible impact?
    • Who else knows about it?
    • What do you think caused it?
    • Did anything unusual happen before the incident?

Failure to report an incident may result in disciplinary action.

Once a report of an incident is received and validated, the CIRT will be activated. The CIRT can place a priority on the incident.

Incident management occurs in our Grafana incident response management system.

3. Containment

Once an incident is confirmed, the CIRT will take action to prevent further damage. This may involve:

  • Isolating affected systems from the network
  • Disabling compromised accounts and resetting credentials
  • Blocking malicious traffic or connections
  • Engaging external IT security specialists if required

As part of containment, forensic evidence should be gathered where appropriate. Our approach generally keeps logs in a place where they can’t be tampered with, but still, care should be taken to ensure that evidence is preserved as much as possible. General guidance for forensic evidence preservation includes:

  • Don’t turn off the system unless absolutely necessary
  • Log all actions taken
  • Don’t access or modify files unless necessary
  • Keep a record of all places where evidence was or could be found.

Our External First Response Advisor

Once initial containment is complete, the CIRT must contact our First Response provider:

  • First Response Advisor: Clyde & Co, Norton Rose Fulbright
  • First Response Contact: [1800 290 982](tel:1800 290 982) or [1800 316 349](tel:1800 316 349)

The First Response Advisor:

  • Will point an approved IT Specialist to assist with the incident response if required. They will form part of the CIRT, under the command of the Response Controller.
  • Will advise on initial legal advice including our obligations to regulators and individuals.
  • May appoint a Public Relations Advisor to prevent reputational damage.
    • Staff should be advised to route all inquiries from the public towards this advisor.
  • May appoint a Cyber Extortion Advisor to assist with ransomware or other extortion attempts.
    • In this case, all contact with the attacker should be routed through this advisor first.

The advise of the First Response Advisor should generally be followed as they are experts in the field of cyber incident response, and are familiar with the legal and regulatory environment in which we operate. Our cyber insurance policy recommends that we follow their advice.

4. Investigation & Impact Assessment

The CIRT will perform the initial triage and investigate the source, method, and impact of the attack. This includes:

  • Reviewing logs and system activity
  • Determining how the attack occurred
  • Assessing data loss or system compromise
  • Engaging external security experts if necessary

The incident severity will be determined based on:

  • Threat Level (e.g. untargeted malware vs. targeted attack)
  • System Criticality (e.g. finance system vs. general file storage)
  • Business Impact (e.g. operational disruption, financial loss)
  • Suspected Source (e.g. external attacker vs. internal error)

The severity will guide the response and recovery efforts.

5. Remediation

Once the issue is understood, the next step is to fix vulnerabilities and prevent recurrence. This may involve:

  • Removing malware or compromised accounts
  • Updating security controls and patching vulnerabilities
  • Strengthening access controls (e.g. enforcing multi-factor authentication)
  • Reviewing and adjusting security policies.

We try to develop a range of playbooks that can be used to respond to common incidents. You can find this in the Playbooks & Plans section, and in Grafana.

6. Recovery

Restoring systems and monitoring for lingering threats. Recovery actions include:

  • Restoring affected services & verifying system integrity
  • Ensuring no further unauthorised access
  • Conducting vulnerability scans
  • Monitoring for any recurrence of the attack

Communication & Reporting

Managing stakeholders is an important part of our incident response. This section outlines the communication and reporting requirements for different types of incidents.

Externally

Some incidents require notification to external parties. Our First Response Advisor will usually advise on this as the expert.

Generally, if we have a CRITICAL or HIGH incident, we will need to notify the following parties (each has their own specifics though):

  • Third-party IT/security providers – if additional expertise is needed
  • Australian Cyber Security Centre (ACSC) – must be notified within 12 hours for major incidents
  • Office of the Australian Information Commission (OAIC) – required for serious data breaches affecting personal information
  • Impacted customers/stakeholders – must be informed within 24 hours

Internally

  • Senior Management – must be kept updated on high-severity incidents
  • Relevant Business Units – need to understand potential operational impact
  • IT Teams – coordinate response and prevention measures

Quick Reference Contacts

For urgent support, contact:

If there is a threat to life or risk of harm, call 000.

For suspected incidents, use the internal email notification template to report details to your manager and the CIRT team.

Appendices

Appendix A - Types of Incidents

Incident TypeDescription
Installation or execution of unauthorised or malicious softwareSuspected, attempted or actual installation or execution of unauthorised or malicious software on a Vaxa device. Includes malware detections by anti-malware software (even if mitigated successfully) and detections by application whitelisting solutions.
Network intrusion, enumeration, or another probeSuspected, attempted or actual network intrusion, enumeration, or probe. Includes intrusion alerts generated by network security equipment such as firewalls or IDS/IPS.
Physical loss, theft, or damage of an IT assetSuspected, attempted or actual physical loss, theft or damage of any IT asset containing Vaxa data. Includes the loss or theft of laptops, tablets, smartphones, or removable media (USB sticks, CDs, DVDs, DATs, etc.).
Physical loss, theft, or damage of hardcopy informationSuspected, attempted or actual physical loss, theft, or damage of any Vaxa information in hardcopy.
User impersonationSuspected, attempted or actual instance of user impersonation. Includes password-sharing, attacks on authentication controls, impossible log-on scenarios, etc.
Suspicious privilege amendmentSuspected, attempted or actual instances where a genuine user appears to have been placed in an inappropriate user group or to otherwise have gained excessive privileges.
Suspicious use of legitimate privilegesSuspected, attempted or actual instances where user appears to have abused legitimate access privileges, e.g., by accessing large number of files, e-mailing data to unauthorised recipients, copying data to removable media or unusual network locations, etc.
Eavesdropping on a legitimate comms channelSuspected, attempted or actual instances where Vaxa data appears to have been intercepted by an unauthorised party. Includes instances where sensitive data is transferred to authorised recipients in unencrypted form.
Service spoofingSuspected, attempted or actual instances where a data service belonging to, or used by, Vaxa is spoofed by a third party. Includes fake websites.
DoS or excessive resource consumptionSuspected, attempted or actual instance where an entity places an excessively high demand on an information system or asset. Includes Denial of Service and spam.
PhishingSuspected, attempted or actual instances where:
- Email received that claims to be something, or from someone, that it is not.
- Persons outside receive email which claims to be from Vaxa but is not.
Social EngineeringSuspected, attempted or actual instances where an unauthorised person attempts to gain access to Vaxa data or IT systems by deception or extortion of authorised users (staff, customers or third parties).
Inappropriate use of IT facilities (including inappropriate web browsing)Suspected, attempted or actual instance where user uses system which they have authorised access in an illegal manner, breach policy or contrary to workplace norms. This includes browsing websites that are inappropriate for workplace; sending threatening, obscene or harassing communication; or accessing/storing illegal material.
Other harmful mode not listedAny event that is deemed to be a security event that falls within the remit of the CIRT, but which does not fall into any of the above categories.

Appendix B – Incident Threat Levels

The following is an explicit description of Incident Threat Levels in descending order of criticality (worst at the top):

Incident Threat LevelDescription
Threat Level 1Human-Controlled Root-Level Compromise:
- Unauthorised external personnel (cyber intrusion).
- Partner organisation exceeding authority.
- Internal personnel exceeding authority.
- Close-access breach (physical penetration of a site).
- Rogue wireless access point.
- Router re-direct.
Threat Level 2Human-Controlled User-Level Compromise:
- Unauthorised external personnel (cyber intrusion).
- Partner organisation exceeding authority.
- Internal personnel exceeding authority.
Threat Level 3Automated (malware-controlled) Root-Level Compromise
Threat Level 4Automated (malware-controlled) User-Level Compromise
Threat Level 5Denial of Service
Threat Level 6Focused Scanning or Unmanaged Malware

Appendix C – System or Information Criticality

The criticality of systems and information that is potentially at risk is the second component to guiding the assessment of the severity of an incident. The following is an explicit description of these system or information criticalities in descending order of importance (most important first):

System/Information CriticalityDescription
Criticality Level 1Company-Wide Network Resources (Revenue-Generating Services, Routers, Switches, DNS, Proxies, Firewalls etc.).
Criticality Level 2Highly Critical Information – Confidential Information (Intellectual Property, PII, PHI).
Criticality Level 3High Criticality Systems (Active Directory, Exchange, Web Services etc.).
Criticality Level 4Sensitive Information – Restricted Information (Sensitive Corporate Information, non-PII, Financial Transaction Information etc.).
Criticality Level 5Non-Critical Multi-Use Systems (File Servers, SharePoint etc.).
Criticality Level 6Individual Systems and Non-Sensitive Information.

Appendix D – Incident Severity Matrix

The following table outlines the severity of incidents based on the combination of Incident Threat Level and System or Information Criticality.

System or Information CriticalityThreat Level 1Threat Level 2Threat Level 3Threat Level 4Threat Level 5Threat Level 6
Criticality Level 1CriticalCriticalCriticalHighHighMedium
Criticality Level 2CriticalCriticalHighHighMediumMedium
Criticality Level 3CriticalHighHighMediumMediumMedium
Criticality Level 4HighHighMediumMediumMediumLow
Criticality Level 5HighMediumMediumMediumLowLow
Criticality Level 6MediumMediumMediumLowLowLow