VU23221 Evaluate and test an incident response plan for an enterprise

The whole unit turns on one idea: an incident response plan is only as good as the last time you tested it. You build a team, you write the plan, then you attack a safe copy of your own environment to find out whether the plan actually works, and you feed what you learn back into the plan. Red teams attack, blue teams detect and defend, purple teams sit between the two and turn the exercise into improvements.

These notes follow the unit's own teaching sequence, from forming a team through to evaluating the plan, then add the parts the accredited material does not cover. The single biggest gap is currency: the unit is built on NIST SP 800-61 Revision 2, published in 2012, and that guide was superseded in April 2025. There is a section below on what changed and why it matters. The other gap is Australian reporting law, which has shifted significantly since the unit was accredited; there is a current-practice section on that too.

A note on the lab tools. Part of this unit runs denial-of-service and phishing simulations against deliberately outdated Windows targets in an isolated sandbox. Running those tools against any system you do not own, or have written permission to test, is a criminal offence under the Commonwealth Criminal Code Act 1995. The point of the exercise is not the tools; it is learning to detect an attack and improve the plan.

Every organisation that takes security seriously needs a way to respond when something goes wrong, and that capability has to exist before the incident, not be improvised during it. The team does not have to be large or full-time; it has to exist, have authority, and know who does what.

Three team models

NIST describes three ways to structure an incident response capability, and the right one depends on the size and shape of the organisation.

Central. A single, centralised team handles incident response for the whole organisation. This suits organisations on one site or with one IT environment.

Distributed. Multiple teams, each responsible for a physical location (a branch office, say), a department, or a part of the IT infrastructure. This suits larger, spread-out organisations.

Coordinated. A central team works alongside distributed teams without holding authority over them. The central team acts as a knowledge centre and helps with complex, critical or organisation-wide incidents.

Within any of these, the people can be employees, partially outsourced, or fully outsourced, and employees can be full-time or part-time.

Deciding how the team is staffed

Four questions shape the decision, and they trade off against each other:

Does response need to be available around the clock, and do responders need to be on-site, or is phone contact enough? Real-time, on-site response is best because it lets you act immediately and limit damage, but it is also the most expensive option.

Should staff be part-time or full-time? Part-time staff can make up a virtual incident response team. When an incident occurs, the IT help desk is often the first point of contact, does the initial investigation, and calls on whoever is available.

How much expertise is needed? Incident response needs broad knowledge of IT systems, protocols and attack techniques, plus knowledge of the organisation's own environment. Outsourced teams usually bring stronger security expertise; internal staff understand the environment better, and know normal from abnormal and which systems are critical.

What will it cost? Specialist responders who are on call around the clock are a major investment, and a Managed Security Service Provider (MSSP) can be costly too, on top of tooling, facilities and secure communications.

The theme running through all four is that incident response has to be management-driven. The team needs authority and a budget, or the plan gets ignored the moment a real incident hits.

Who is on the team

The team has to be a team; no single person or technical area can cover it all. It needs to be small enough to make quick decisions and flexible enough to co-opt specialists as needed. A manager and a deputy anchor an internal team; other members might be drawn from IT support, information security, legal, HR, media or public relations, business continuity, and physical security and facilities. You would not pull in all of them for every incident.

A common way to describe the technical roles, borrowed from how a Security Operations Centre is staffed:

Tier 1 Alert Analyst; first-level detection, triaging alerts the SIEM raises for abnormal data or activity.

Tier 2 Incident Responder; second-level analysis and response to escalated alerts.

Tier 3 SME Threat Hunter; focused on detecting and pre-empting threats rather than waiting for alerts.

Security Engineer; strong software and scripting skills, building and maintaining the tooling.

SOC Manager; oversees the analyst teams.

CISO; overall accountability for hiring, reporting and policy.

CERT, CSIRT and SOC: what the acronyms mean

These get used loosely, so it is worth pinning down. A Security Operations Centre (SOC) consolidates security operations under one umbrella, whether centralised or virtual and distributed. It usually includes incident response, but also monitoring, vulnerability scanning, forensics and other security work.

A CSIRT (Computer Security Incident Response Team) or CERT (Computer Emergency Response Team) focuses specifically on responding to incidents. It can sit inside a SOC, exist on its own, be spun up ad hoc, or run as a permanent operational group. The short version: a SOC is the broad security operation; a CSIRT or CERT is the incident-response part of it.

Communication and reporting

Element 1 asks you to determine communication strategies and the reporting hierarchy. When you prepare a summary report or a briefing after an incident, several things decide whether it lands:

How long is it, and who is the audience? What technical background do they have, and is the language pitched for them? Are there alarmist phrases, and if so, how are they framed? Does it address the issue clearly? What are the costs and repercussions of the recommendations, and how are those presented? Is the tone unfairly critical of the organisation?

The reporting hierarchy has to name real people and reach the CISO or equivalent. Initial contact is often by phone or face to face; a written report follows, at the right length and in the right language for its readers.

Why the business cares

You cannot get management buy-in without articulating the business implications, which is exactly what performance criterion 1.4 asks for. A cyber-attack can cause financial loss (theft of money or information, disruption to trading), business loss (damage to reputation, and to the partners who rely on you), direct costs (getting affected systems running again), and the time cost of notifying authorities and affected parties.

What is at risk is broader than money: customer records and personal information, email and financial records, business plans, intellectual property, product designs, patent applications, and employee records. Framing the conversation in these terms is what earns the team its authority and budget.

Update, current as at September 2026. The teaching material draws its team models from NIST SP 800-61r2. The successor guide, SP 800-61r3 (April 2025), keeps the same practical advice about forming a capability but folds it into the "Govern" and "Identify" functions of the NIST Cybersecurity Framework 2.0; see the section on the NIST rework below. The substance of who is on the team and how it is staffed has not changed.

This is the heart of the unit. You test a plan by attacking a safe copy of the environment (red), watching whether the defence notices and responds (blue), then bringing both sides together to improve the plan (purple).

The red team

A red team is an internal or external group that takes an adversarial role, analysing and infiltrating an organisation's networks, systems and applications. It exists to answer one question honestly: if a real attacker came at us this way, would we know, and could we stop them?

A few closely related terms get used around red teaming, and they are not the same thing:

Penetration testing is a manual security-testing method that gives a comprehensive picture of how good the security controls are. The goal is to test the vulnerability of networks, assets, hardware, platforms and applications within a defined scope.

Vulnerability assessment is the process of defining, identifying, classifying and prioritising vulnerabilities across systems, applications and network infrastructure. It typically uses automated scanning tools and produces a report. Where a penetration test tries to exploit a weakness to prove it is real, a vulnerability assessment catalogues weaknesses and ranks them.

Red teams typically look for flaws in three categories: technology, people, and physical locations. Realistic examples include infrastructure vulnerabilities that could delay a product or delivery; unhappy or compromised employees escalating their privileges to reach intellectual property or plant a backdoor; social engineering to trick an employee out of their credentials; and unpatched network devices offering a way in.

Attack frameworks

Red teams do not improvise; they work to a framework so the exercise is repeatable and maps to how real adversaries behave.

The MITRE ATT&CK framework classifies real-world attacks by adversary tactics and techniques, and it is the common language of the field. Start at attack.mitre.org.

The Lockheed Martin Cyber Kill Chain breaks an intrusion into stages from reconnaissance through to actions on objectives; it is useful for thinking about where in the chain you could detect or break an attack. See the Cyber Kill Chain page.

The blue team

Blue teams protect the organisation's infrastructure and data. They use a range of tools to detect incidents and then respond to them. An introductory blue-team role is the SOC Analyst. Blue teamers do their job better when they understand the tools their adversaries use, and the aim over time is to shift from a reactive posture to a proactive one.

The skills that make a good blue teamer are as much temperament as technique: an inquisitive, proactive mindset; attention to detail; systematic problem-solving; endless curiosity about anything out of the ordinary; and the determination not to leave something unsolved. A classic interview question is "tell me about a time you broke something, and what you did to fix it."

In a blue team exercise, a red team attacks the organisation's assets while the blue team works to detect, block and mitigate. The blue team's job is to spot the abnormal against a known baseline of normal, isolate affected assets, and respond.

The blue team's toolkit

The tools below are a representative set, not a shopping list; every environment picks its own.

Intrusion detection and prevention. Tools such as SolarWinds Security Event Manager manage access to log files and run correlation rules that surface threat data; some can act to fix threats automatically. Network monitoring itself can be done with free tools such as Nagios Core, Zabbix or Snort.

SIEM (Security Information and Event Management). Tools such as Splunk, the Elastic (ELK) Stack and Wazuh collect log data from forwarders or agents into one place. The real power, and the key skill for a responder, is the filtering and correlation rules that pull the meaningful events out of the noise.

Endpoint Protection (EPP). Endpoint software that analyses files for suspicious content and quarantines them; Microsoft Defender is the familiar example.

Endpoint Detection and Response (EDR). An integrated endpoint solution that combines continuous monitoring and data collection with rules-based automated response and analysis. It is used to detect and investigate suspicious activity on hosts, with enough automation to let a team respond quickly; in that sense it behaves like an IDS or IPS for the endpoint.

Extended Detection and Response (XDR). A newer approach that unifies endpoint detection with telemetry from network analysis, email security, identity and access management and other tools, for broader protection. This is an active area with many vendors competing; Palo Alto Cortex XDR and CrowdStrike Falcon are two examples. Coverage is sold by subscription, and more detail costs more.

Packet analysis. Tools such as Wireshark let you examine individual packets, which can help identify an attacker's IP address and understand the traffic between attacker and victim. Wireshark is powerful but detailed; it is used when you need to confirm something specific, and it is not the first tool you reach for.

Logs and log aggregation. A log file is a timestamped record of events, with user and event detail. Knowing the log types helps you know where to look: event logs (logins, failed passwords, application events); server logs (activity for one server over a period); system logs or syslogs (operating-system events; Windows, Linux and macOS all produce them); authorisation and access logs (who or what accessed an application or file); change logs; availability logs (uptime and performance); resource logs; and threat logs (traffic that matched a firewall's security profile). Centralising these into a SIEM is what makes them useful at scale.

The purple team

Purple teams exist to maximise the effectiveness of red and blue together. They integrate the defensive tactics and controls the blue team runs with the threats and vulnerabilities the red team finds, into a single narrative that improves both. The ideal is that purple is not a separate team at all but a permanent working relationship between red and blue; the offensive and defensive specialists work in sync, picking a security area (broken authentication, say) and finding and fixing weaknesses together rather than in sequence.

The payoff is better communication and collaboration (one team, not two divisions negotiating across a gap) and better security overall, because knowledge is shared continuously instead of handed over at the end.

flowchart LR
 R["Red team<br/>attacks a safe copy<br/>and finds weaknesses"] --> P["Purple<br/>evaluate the exercise,<br/>agree improvements"]
 B["Blue team<br/>detects, responds,<br/>and mitigates"] --> P
 P --> IRP["Incident response plan<br/>updated and re-tested"]
 IRP --> R
 IRP --> B

Sandbox testing

New hardware, systems or processes are often tested in a simulated environment before they go near production. An "incident" is initiated deliberately so the team can practise the response and see the result, usually on a test system in a sandbox. Larger teams sometimes hire an external facility to role-play the incident. This is the safe, legal way to run the attacks in this unit: an isolated environment you own, with no path to any live system.

Hacker "hat" colours, and where you fit

The field describes attackers and defenders by the colour of hat they notionally wear. It is a rough taxonomy, but it is useful for placing motive.

White hats are ethical hackers, hired to find vulnerabilities and fix them before they are exploited; certification such as the EC-Council Certified Ethical Hacker (CEH) sits here. Black hats breach systems for their own gain, stealing money, data or access. Grey hats look for vulnerabilities without permission, then report them (sometimes for a fee); this is still illegal because there was no permission, even where no harm was intended. Blue hats are either external professionals invited to test soon-to-be-released products, or revenge seekers targeting one person or company. Green hats are beginners working to build their skills. Red hats act as vigilantes against black hats. Script kiddies are not given a colour; they reuse others' code and tools, often for a DoS or DDoS, out of boredom rather than any real allegiance. Hacktivists attack for political reasons.

For this unit, you are being trained as a white hat. Every technique here is legal only inside a sandbox you own or have written authority to test.

Bug bounty programs

A bug bounty program is an arrangement offered by many organisations that pays and credits individuals for responsibly reporting software bugs and vulnerabilities, so they can be fixed before they are abused. Mozilla, Meta, Google, Microsoft and many others run them; HackerOne is a well-known platform that hosts them. Bug bounties are a legitimate, paid route into security work, and a clean example of white-hat testing done with permission.

The unit runs a set of denial-of-service and phishing simulations against deliberately outdated Windows targets in an isolated sandbox. A word before the tools: these are attack tools. Point them at anything you do not own or have written permission to test and you are committing an offence under the Criminal Code Act 1995 (Cth). The learning objective is not the attack; it is watching whether the blue team detects it, and using the result to improve the plan.

The lab environment is a set of virtual machines on an isolated network (for example Kali as the attacker, with Windows XP, Windows 7, Windows 10 and Metasploitable as targets on a private subnet), so nothing can escape to a live system.

The denial-of-service tools

Python DoS script. A short script (carried over from the earlier pen-testing unit) that runs a SYN flood against a target. In the lab it produces a very short, sharp burst, enough to show a measurable delay in ping response without taking the target down.

Ettercap (or bettercap on newer Kali). Run as sudo ettercap -TQP dos_attack, it can carry out ARP poisoning and SYN flooding against a target. This one is worth understanding from the blue side, because ARP poisoning shows up as the gateway's MAC address changing, which is a high-severity detection.

LOIC (Low Orbit Ion Cannon). An open-source stress-testing and DoS tool that floods a target with TCP, UDP or HTTP requests to exhaust its CPU, memory and bandwidth. It is awkward to run on Linux (it is a .NET application needing mono) and easier on Windows, where antivirus treats it as malware. Background: Imperva on LOIC.

HOIC (High Orbit Ion Cannon). A later, more capable tool written to replace LOIC, generating high volumes of HTTP GET and POST requests, able to hit multiple URLs at once, with booster scripts and proxy support. Also flagged as malware on download. Background: Imperva on HOIC.

UFONet. A Python-based denial-of-service toolkit that runs cleanly on Linux and has a web interface. It simulates a botnet by abusing "open redirect" vulnerabilities on third-party sites to bounce traffic at a target, so the simulated attack can be larger and longer than a single machine could manage. Source and manual: UFONet on GitHub. An open redirect is a web flaw where an application takes a user-supplied URL and redirects to it without validating the destination, so a link that starts on a trusted site quietly sends the victim somewhere hostile.

Running any of these from several virtual machines at once turns a denial-of-service (DoS) into a distributed denial-of-service (DDoS), which is the point of having multiple targets and attackers in the lab.

The phishing and credential-harvesting exercises

Alongside the DoS tools, the unit runs credential-harvesting simulations using Kali's Social-Engineer Toolkit (SET): cloning a login page, standing up a fake page, and sending a spear-phishing email with SET's mass-mailer. Again, this is done only against lab accounts and lab users; credential harvesting against real people is a serious offence.

A note on the tooling's age

Update, current as at September 2026. These tools are dated, and that is worth naming rather than hiding. LOIC and HOIC date from the early 2010s and the Anonymous era; real DDoS today is overwhelmingly launched from rented botnets and booter or stresser services, and is absorbed by cloud-scale mitigation from providers such as Cloudflare, Akamai and AWS Shield rather than by a single firewall. Windows XP, Windows 7 and Windows Server 2012 are all past end of support, which is exactly why they make useful, safe practice targets, and exactly why no organisation should still be running them. The skills that carry forward are not the tools; they are the method: establish a baseline, generate a known attack in a safe environment, watch how the defence responds, and write down what you learned. That method is unchanged whether the attack is a 2012 flooder or a 2026 booter service.

Element 3 is about the plan itself: what it is, what sits above and below it, and how you turn it into something people can actually follow during an incident. A recurring exam-style trap is confusing four terms that sound similar, so it is worth getting them straight.

Capability, policy, plan and procedures

These are four different things, and they nest inside each other from the top down:

Response capability is the organisation's overall ability to respond: the people, tools, authority and structure. It answers "can we do this at all, and is the team full-time, part-time, virtual or hybrid?"

Response policy sets the rules and governance. It defines what counts as a security incident, assigns roles, responsibilities and reporting requirements, and provides the authoritative framework the plan and procedures must follow.

Response plan is the strategic roadmap for the whole program: goals, objectives, metrics for measuring success, and training requirements. NIST is emphatic that a plan is not merely a list of steps; it sits between the policy (governance) and the procedures (technical steps).

Response procedures are the detailed, step-by-step actions for handling incidents, covering every phase and including playbooks for specific incident types such as malware, phishing or DDoS. These are what responders use during a live incident.

If you can articulate the difference between these four, you have most of element 3.

The NIST four-phase lifecycle (as the unit teaches it)

The unit is built on NIST SP 800-61 Revision 2, which describes incident response as a four-phase cycle, not a straight line. The emphasis is that response is cyclical, with continuous learning feeding back into preparation.

flowchart LR
 P["Preparation<br/>assets, baselines,<br/>tooling, playbooks"] --> D["Detection and analysis<br/>precursors and indicators,<br/>compare against baseline"]
 D --> C["Containment,<br/>eradication and recovery<br/>stop it, remove it,<br/>restore service"]
 C --> PI["Post-incident activity<br/>what happened, what to<br/>improve"]
 PI --> P

Preparation. Compile a list of IT assets (networks, servers, endpoints), identify which are critical or hold sensitive data, set up monitoring so you have a baseline of normal activity, decide which events warrant investigation, and write response steps for common incident types.

Detection and analysis. Collect data from systems, security tools, public sources and people, and identify precursors (signs an incident may happen) and indicators (signs an attack has happened or is happening). Analysis means correlating events against the baseline and seeing how they deviate.

Containment, eradication and recovery. Contain to stop the attack before it overwhelms resources; the strategy depends on the potential damage, the need to keep services available, and how long the fix must last. Identify and validate the attacking host's IP so you can block it and understand the adversary. Then eradicate (remove malware, reset breached accounts, identify all affected hosts) and recover (restore systems, return to normal, and make sure the same assets are not hit again).

Post-incident activity. Learn from the incident. Document what happened and when; how well the team performed and whether the processes were sufficient; what information was needed sooner; whether any wrong actions caused damage; what to do differently; and what new precursors, indicators, tools or resources are now needed. Feed all of it back into preparation.

The SANS incident handling model (from the SANS Incident Handler's Handbook) covers the same ground with six steps (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) and maps closely onto the NIST four. Different labels, same lifecycle.

Incident handling forms and logs

You cannot reconstruct an incident from memory, and you may need the record for a forensic analysis or in court, so the plan should define a set of forms to capture information as the incident unfolds. Useful logs include a contact log (points of contact), an evidence log (data collected), a chain-of-custody log (an audit trail as evidence changes hands), a communication log, a sanitation record, a recovery record, an eradication log, and an identification record (the incident type and who found it).

The recording discipline is simple: notes must be factual, concise, precise and evidence-related, and should always capture who, when, what, where and how. That chain-of-custody log is the item students most often forget, and it is the one a lawyer will ask for.

Playbooks

A playbook sets out what to do in each phase of the chosen model for a specific incident type. There are many published playbooks, but they are guides; your playbook has to be tailored to your own security implementation. For a large organisation a playbook might be a flowchart per phase; for a small business with a simple environment it may be a short list of steps. The Incident Response Consortium publishes a useful starting set at incidentresponse.com/playbooks, meant to be adapted rather than adopted whole.

This is the most important currency update in the unit, so it gets its own section. The teaching material, and most of the templates floating around, are built on NIST SP 800-61r2, which was published in 2012. In April 2025 NIST released SP 800-61 Revision 3, which supersedes r2 and reframes incident response quite deliberately.

The change in the title tells the story: r3 is subtitled "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile." Instead of a standalone four-phase lifecycle, incident response is now expressed through the six Functions of the NIST Cybersecurity Framework (CSF) 2.0, so that response is treated as part of managing cyber risk across the organisation, not as a separate technical procedure that starts when an alarm goes off.

The six CSF 2.0 Functions are Govern, Identify, Protect, Detect, Respond and Recover. NIST maps the old lifecycle onto them like this:

SP 800-61r2 phase (2012)	CSF 2.0 Function(s) in SP 800-61r3 (2025)
Preparation	Govern, Identify, Protect
Detection and analysis	Detect
Containment, eradication and recovery	Respond, Recover
Post-incident activity	Improvement, feeding back into Govern and Identify

Two ideas are doing the real work in r3. First, Govern, Identify and Protect are ongoing, not a one-off "preparation" step you complete before an incident; they run continuously underneath everything else. Second, r3 stresses continuous improvement throughout, with lessons shared as soon as they are identified rather than saved up for a single review after recovery. That maps neatly onto what a purple team does in this unit: it turns the exercise into improvements straight away, instead of waiting for a post-mortem.

For this unit, none of this makes the coursework wrong; the four phases are still a fine way to learn the lifecycle, and r3 explicitly carries them across. But if you are describing current best practice, or writing something an employer will read in 2026, cite the CSF 2.0 Functions and SP 800-61r3, and treat "Govern" (the risk-management strategy, roles and policy that sit above the plan) as a first-class part of incident response rather than an afterthought. The r3 document is free from NIST at doi.org/10.6028/NIST.SP.800-61r3.

Element 4 turns planning into practice. "Implementing" the plan here means standing up the operation that runs it day to day, deciding how that operation is resourced, and getting the evidence together when an incident happens.

Three operating models

How you run security operations depends on size and budget, and there are three broad models:

On-site dedicated CSOC. A full in-house Cyber Security Operations Centre; suits well-funded, larger organisations.

Hybrid. A combination of in-house staff and a Managed Security Service Provider (MSSP); suits medium organisations with some internal IT or security capability. For a small business like the case-study company in this unit, hybrid is usually the sensible fit: local staff handle the simple things (password resets, backups) and the provider handles server maintenance and monitoring.

Remote monitoring. Cloud-based monitoring with some enhanced local security features; suits small organisations.

What a Security Operations Centre actually does

A SOC is an organisational structure that continuously monitors and analyses an organisation's security, defends against breaches, and isolates and mitigates risks. It watches servers, endpoints, networks, applications, databases and websites, providing the layer of human analysis needed to spot the irregular activity that signals an incident. Firewalls and intrusion-prevention systems stop basic attacks; people are needed for the serious ones.

The core activities are data collection (what is happening on the network and devices), detection (finding items of interest in that data), triage and investigation (confirming and prioritising), and incident response (responding and minimising impact). On top of that sit specialist capabilities: threat intelligence, forensics, and self-assessment (inventory, configuration monitoring, vulnerability assessment and red teaming).

The SOC's standing responsibilities are worth knowing because they map to the performance criteria: implement and manage the security tools; investigate suspicious activity and contain it; reduce downtime and keep the business running; contribute to security strategy; and support audit and compliance (for regimes such as PCI DSS).

At the centre of the toolset is the SIEM, which aggregates security events and raises alerts for analysts. Next-generation SIEMs add UEBA (User and Entity Behaviour Analytics) and SOAR (Security Orchestration, Automation and Response), which automate routine handling and surface threats that older tools would miss. Splunk, the ELK Stack and Wazuh are common examples.

Collecting incident data

Where you collect evidence from is specific to each environment, but the common sources are Windows event logs, firewall logs, network logs, Wireshark captures and baseline logs. Commercial tools pull these into one repository; examples include SolarWinds Security Event Manager, IBM QRadar, Splunk, ELK and Wazuh, with a growing number of AI-assisted tools emerging.

Two blue-team tools the unit introduces here are worth a note. OpenVAS is an open-source vulnerability-scanning suite (a fork of the Nessus engine from when it went commercial) managed from a web dashboard. Security Onion is a free network-security-monitoring distribution that can stand in for expensive commercial appliances and is straightforward to set up.

A Cyber Security Incident Response Form should capture contact information, general incident information, an incident summary, the mitigation taken, and recommendations. It ties back to the logs above: the form is the narrative, the logs are the evidence behind it.

Not every incident deserves the same response, so before you can respond proportionately you have to classify what you are dealing with. Severity levels answer the practical questions the team needs settled fast: who owns the response, how they communicate, how serious it is, what they are allowed to do to fix it, and how they report on it.

A severe incident is dealt with immediately; a low-level one is handled as resources free up. Several models exist, and they differ mainly in how many tiers they use:

Atlassian uses a three-tier model (P1 to P3). Australian government bodies use a four-tier model (Critical to Low). Splunk uses a five-tier model, SEV1 (Critical) down to SEV5. The CIS model uses six tiers. They are not interchangeable in their labels, but they all rank the same underlying thing: impact against urgency.

Using the Splunk scale as a worked example:

Class	Description	Example
SEV1	A critical incident affecting a large number of users in production	A client-facing service is down for all customers; a security breach; critical infrastructure failure; customer data loss
SEV2	A significant problem affecting a limited number of users in production	A client-facing service is down for a subset of customers; critical functionality affected
SEV3	An incident causing errors, minor problems, or heavy system load	Temporary disruption to a client-facing service; non-critical functionality affected
SEV4	A minor problem that affects the service without serious user impact	Minor errors or inconveniences; temporary disruption to a non-critical system
SEV5	A minor, non-emergency issue	Handled by an engineer during a change window

The level drives the process. A SEV1 pulls in a department head or management, runs on an open call bridge, permits any measure including restarting production processes, and is reported hourly to management. A SEV5 is owned by a single engineer, tracked in the ticketing system, and can only be touched during a change window. Setting the level correctly at the start is what makes the rest of the response proportionate.

For the lab exercises in this unit, classifying the simulated attacks (DoS, DDoS, credential harvesting, phishing) is a good drill in itself: what was affected, was performance degraded, was any data taken, and was any malware left active? Those four questions decide the severity.

Element 5 closes the loop, and it is where the purple team earns its place. The last phase of the NIST lifecycle is post-incident activity, and in a red and blue exercise that is where the results are evaluated, usually facilitated by the purple team. After the reports are written, the discussion turns to how the exercise went and how to do it better.

The review works through a standard set of questions: What happened, and at what times? How well did the team handle it, and were the processes followed and sufficient? What information was needed sooner? Were any wrong actions taken that caused damage or slowed recovery? What could staff do differently next time? Could information have been shared better across teams or organisations? Have we found ways to prevent similar incidents, and new precursors or indicators to watch for? What extra tools or resources are needed?

The output is not a report that gets filed; it is a set of changes. You use the findings to adjust the policy, plan and procedures, and feed the new data into the preparation phase, which starts the cycle again. Concretely, an evaluation of the lab exercises in this unit tends to recommend more specific red-team scenarios (adding a SIEM, an IDS or a firewall to the environment), and cyber-awareness training for staff, especially phishing recognition. Performance criterion 5.3 also asks you to assess how well the team communicated with management, and to change that if needed, which brings the unit back to where it started: incident response only works if management is engaged.

Update, current as at September 2026. This is exactly the point where SP 800-61r3 differs from the r2 material the unit teaches. Rather than treating "lessons learned" as a single review after recovery, r3 asks teams to identify and share improvements continuously, throughout the incident, not only at the end. A purple team that turns each finding into a change as it surfaces is already working the r3 way.

The unit's reporting material is about internal reporting: who to tell inside the organisation, and how. That is necessary, but it is only half the picture in 2026, because Australian law now compels external reporting in several circumstances, and the obligations have changed significantly since the unit was accredited. Any real IRP written for an Australian organisation has to build these in. The figures and timeframes below are current as at September 2026; this is an area that moves, so treat the linked sources as the authority.

The Notifiable Data Breaches scheme

Under Part IIIC of the Privacy Act 1988, an organisation covered by the Act must notify the Office of the Australian Information Commissioner (OAIC) and affected individuals of an "eligible data breach": unauthorised access, disclosure or loss of personal information that is likely to result in serious harm. Where a breach is suspected, the organisation must assess it promptly, and the OAIC expects that assessment within 30 days. Details and the reporting form are at oaic.gov.au. This is the obligation most organisations meet first, because most incidents involve personal information.

The SOCI Act, for critical infrastructure

If the organisation operates an asset covered by the Security of Critical Infrastructure Act 2018, mandatory cyber incident reporting applies, and the timeframes are short. A significant cyber security incident (one having, or likely to have, a serious impact on availability) must be reported to the Australian Signals Directorate, through the Australian Cyber Security Centre, within 12 hours of the entity becoming aware of it. An incident with a relevant (lesser) impact must be reported within 72 hours. Reports go through the ACSC portal or by phoning 1300 CYBER1. The obligations sit with the Cyber and Infrastructure Security Centre; see the CISC SOCI obligations factsheet (April 2025).

The Cyber Security Act 2024 and ransomware payments

This is the newest obligation and the one most likely to catch an organisation out. The Cyber Security Act 2024 introduced a mandatory ransomware payment reporting rule that commenced on 30 May 2025. If an entity carrying on business in Australia with an annual turnover above $3 million (or, regardless of turnover, an entity responsible for a critical infrastructure asset) makes a ransomware or cyber-extortion payment, or a payment is made on its behalf, it must report the payment to the Australian Signals Directorate within 72 hours. Non-compliance carries a civil penalty; the standing figure is 60 penalty units, about $19,800 at the current Commonwealth penalty unit value. A useful plain-English summary is Gadens' note on the new obligations and MinterEllison's technical update (30 January 2025). The reporting obligation applies whether or not the organisation chooses to pay; the government's position remains that paying is discouraged, but if you do pay, you must report.

Where to report, in practice

For most organisations and small businesses, the front door for reporting a cyber incident is the ACSC's ReportCyber service at cyber.gov.au/report, which also routes cybercrime to police. An Australian IRP should name the specific channel and deadline for each obligation the organisation is subject to, so that during an incident nobody is reading legislation against the clock.

flowchart TD
 S[Cyber incident detected and assessed] --> PI{Personal information involved,<br/>likely to cause serious harm?}
 PI -- Yes --> NDB[Notify the OAIC and affected<br/>individuals; assess within 30 days]
 S --> CI{Critical infrastructure asset<br/>under the SOCI Act?}
 CI -- Yes, significant impact --> S12[Report to ASD/ACSC within 12 hours]
 CI -- Yes, relevant impact --> S72[Report to ASD/ACSC within 72 hours]
 S --> RW{Did we make a ransomware or<br/>extortion payment, turnover over $3m<br/>or critical infrastructure?}
 RW -- Yes --> RW72[Report the payment to ASD within 72 hours]

Two Australian anchors the unit already points to

Two ASD resources belong in any Australian IRP and connect this unit to the wider certificate. The Essential Eight is the ASD's baseline set of mitigation strategies (application control, patching, macro settings, application hardening, restricting admin privileges, multi-factor authentication and regular backups), and the Essential Eight Maturity Model is how you rate where you sit; it is covered in the legislation and Windows units and is the standard yardstick an assessor or auditor will reach for. The ASD Information Security Manual (ISM), and its Guidelines for Cyber Security Incidents, is the government's detailed control catalogue. Both are free at cyber.gov.au.

The teaching decks note, more than once, that incident response tooling is "changing rapidly with the advent of a plethora of AI tools." That is worth a short, current note, because it is the direction the whole field is moving.

Update, current as at September 2026. The mainstream SIEM and SOC platforms now ship machine-learning and generative-AI features as standard rather than as add-ons: Microsoft Sentinel, Splunk, CrowdStrike and Palo Alto all market AI assistants that triage alerts, summarise incidents in plain language, and suggest response steps. The genuine gains are in the tedious, high-volume work; correlating thousands of alerts, drafting the first version of an incident summary, and cutting the time an analyst spends on false positives. The honest limits are just as real: these systems hallucinate, they can be misled by adversaries who craft inputs to evade or confuse them, and they do not remove the need for a skilled human to make the call on a serious incident. The blue-team skill that matters most is not disappearing; it is shifting toward supervising the tools, checking their output, and knowing when they are wrong. For an entry level trainee, the practical takeaway is that learning to read logs and understand normal-versus-abnormal is more important than ever, because that is what lets you judge whether the AI's answer is right.

These notes were built from the CDU TAFE VU23221 unit materials in the vault; the Topic 1 to 5 presentations by Stephen Besford (dated January and February 2026, and the Red Teaming Attack Tools deck dated August 2026) and the VU23221 Assessor Guide v7 (August 2026), which supplied the elements, performance criteria and knowledge evidence. The unit scope block draws on the CDU TAFE course document for 22603VIC Certificate IV in Cyber Security (V001, in the vault) and the 22603VIC accreditation unit descriptor. The incident response lifecycle follows NIST SP 800-61r2 (2012), the version the unit teaches, cross-checked against the current NIST SP 800-61r3 (April 2025) for the CSF 2.0 rework, both from nist.gov and read 2 September 2026. Framework references (MITRE ATT&CK, the Lockheed Martin Cyber Kill Chain), the incident response playbooks from the Incident Response Consortium, and the Imperva and UFONet tool references are linked inline. The current Australian reporting obligations draw on the OAIC Notifiable Data Breaches guidance (oaic.gov.au), the Cyber and Infrastructure Security Centre SOCI obligations factsheet (cisc.gov.au, April 2025), and legal summaries of the Cyber Security Act 2024 ransomware payment reporting rule from Gadens and MinterEllison (30 January 2025); the ASD Essential Eight and Information Security Manual are at cyber.gov.au. All web sources were read on 2 September 2026 unless a different date is noted.